Egy MEV bot szerezte meg az ETH-tárcából kivont 7,7 millió dollárt
Az automatizált program a tárcatámadás elkövetőjét megelőzve szerezte meg az rsETH-t. A Kelp protokoll 24 órára befagyasztotta a fogadó tárcacímet.
- A támadó sikertelenül próbálta megszerezni az rsETH-t egy Ethereumon működő Safe tárca egyedi modulján keresztül.
- A Yoink MEV bot front-runninggal megelőzte az eredeti elkövetőt, így elsőként szerezte meg az rsETH-t.
- A Kelp 24 órás korlátozása átmenetileg megakadályozza az rsETH továbbítását a fogadó címről.
- A Kelp közölte, hogy saját szerződései érintetlenek, szolgáltatásai pedig tovább működnek.
Az Ethereum-tárcatámadás feltehetően a Safe egyedi modulján keresztül indult
Az Ethereum-tárcatámadás egy ismeretlen felhasználó Safe-tárcájához kapcsolt egyedi modul működését használta ki. A Blockaid blokklánc-biztonsági cég első riasztása 7,73 millió dollárra tette az érintett rsETH értékét.
A támadó egy nyilvános keeper multicall funkcióval a Uniswap v4 egyedi likviditási modulját egy saját maga által létrehozott, hookkal ellátott poolba irányította. Ott az aEthrsETH tokent rsETH-re bontotta vissza.
Hogyan szerezte meg a Yoink MEV bot a támadó elől az rsETH-t?
A Yoink nevű MEV bot figyelte a blokkláncon megjelenő, nyereséggel kecsegtető tranzakciókat, és front-runninggal az eredeti elkövető elé került. Az automatizált program így mintegy 7,7 millió dollárnyi rsETH felett szerzett ellenőrzést, mielőtt a támadó hozzáférhetett volna a tokenekhez.
Az Etherscan tranzakciós adatai alapján a Yoink ugyanebben a műveletben mintegy 18,93 ETH-t, körülbelül 46 000 dollár értékben utalt egy blokképítőként megjelölt címre.
A Kelp 24 órára leállította az rsETH mozgatását a fogadó címen
A Kelp 24 órára szüneteltette az rsETH mozgatását azon a címen, amelyre a Yoink továbbította a tokeneket. A korlátozás miatt a fogadó tárcából átmenetileg nem lehet továbbküldeni az érintett összeget.
A protokoll ezt kizárólag az adott tárcára vonatkozó elővigyázatossági intézkedésnek nevezte. A lépés nem az rsETH egészére vagy a Kelp teljes rendszerére vonatkozó leállítás.
Nexo
Kamat a meglévő kriptóra
Falka bónusz
Akár 2 500 $jutalom, a portfóliód 0,25%-a
Részletek
Bitget
Forint a ZEN.COM-on át
Falka bónusz
Aktuális promócióka Bitget bónuszközpontjában
Részletek
A Kelp saját szerződéseit nem érintette a támadás, a működés folytatódik
A Kelp közölte, hogy a támadás nem érintette a saját okos szerződéseit, az rsETH fedezete pedig továbbra is teljes. A tokenkibocsátás, a kiutalások és a külső integrációk a vizsgálat alatt is a megszokott módon működnek.
A protokoll biztonsági szakértőkkel vizsgálja az esetet. Az eddig azonosított támadási útvonal az áldozat Safe-tárcájához kapcsolt egyedi modulhoz vezetett, nem a Kelp infrastruktúrájához.
Hogyan értelmezzük ezt a hírt?
Az eset elsősorban a Safe-tárcákhoz kapcsolt egyedi modulok kockázatára figyelmeztet, nem a Kelp protokolljának hibájára. A Kelp gyorsan, egyetlen fogadó címet érintve korlátozta az rsETH mozgatását, ami időt ad a vizsgálatra, és az sem mellékes, hogy a saját szerződései, valamint a token fedezete sértetlen maradt.
A következő hetekben az lesz a döntő jel, hogy a vizsgálat pontosan körülhatárolja-e a kihasználható egyedi modul működését, és kiderül-e, mi történik a Yoink által megszerzett tokenekkel. A Safe-felhasználóknak ebből az következik, hogy a tárcához adott modulokat ugyanazzal az óvatossággal kell kezelniük, mint magát a tárcát: egy plusz jogosultság biztonsági belépési pont is lehet.
Mit érdemes még tudni?
A Safe egy többaláírásos Ethereum-tárca, amelyhez modulokkal további funkciók és jogosultságok adhatók. Egy hibásan kialakított vagy túl széles jogkörű modul azonban megkerülheti a tárca megszokott védelmi folyamatait.
A keeper olyan külső szereplő vagy automatizált program, amely egy DeFi-protokoll karbantartási műveleteit hajtja végre. A multicall több okos szerződéses hívást csomagol egyetlen tranzakcióba, így ezek együtt futnak le a blokkláncon.
A hook egy egyedi okos szerződés, amelyet az Uniswap v4 likviditási pooljai bizonyos műveletek előtt vagy után hívhatnak meg. Ezzel egyedi szabályok építhetők a pool működésébe, de a rosszul megírt vagy rosszindulatú hook további kockázatot is vihet a folyamatba.
Front-runningról akkor beszélünk, amikor valaki észlel egy függőben lévő tranzakciót, majd saját tranzakcióját úgy küldi be, hogy azt előbb hajtsák végre. MEV botok gyakran automatizáltan keresik az ilyen nyereséges tranzakciós helyzeteket.