Ethereum-Safe-Wallet verliert durch bösartiges Modul und Uniswap-v4-Hook $7,73 Millionen in rsETH
Wichtige Erkenntnisse
- •Ein Ethereum-Safe-Wallet verlor über zwei von der Sicherheitsüberwachung am 15. September identifizierte Transaktionen rund $7,73 Millionen in rsETH.
- •Der Angreifer nutzte einen öffentlichen Keeper-Multicall, um ein benutzerdefiniertes Uniswap-v4-Liquiditätsmodul des Safe-Wallets aufzurufen und Vermögenswerte in einen Pool mit einem vom Angreifer kontrollierten Hook umzuleiten.
- •Der bösartige Hook wandelte die aEthrsETH-Sicherheit des Wallets, die an Aave geliefertes rsETH repräsentiert, in übertragbares rsETH um, bevor die Mittel extrahiert wurden.
- •Eine als MEV Frontrunner Yoink bezeichnete MEV-Operation setzte die Angriffstransaktion vor und vereinnahmte einen Großteil des extrahierten Werts. Das Safe-Wallet behielt lediglich ein NFT aus einer Liquiditätsposition.
- •Die zentralen Multisig-Verträge und Signaturschlüssel von Safe sowie Aave, Kelp DAO und der rsETH-Tokenvertrag wurden nicht kompromittiert. Der Vorfall ist von dem Kelp-DAO-Exploit über rund $292 Millionen im April und dem SquidRouterModule-Angriff auf 86 Safe-Konten im Mai getrennt.
Ein Ethereum-Nutzer verlor rund $7,73 Millionen in rsETH, nachdem ein Angreifer einen Safe-Modul-Ausführungspfad ausgenutzt hatte, um Vermögenswerte über einen vom Angreifer kontrollierten Uniswap-v4-Liquiditätspool umzuleiten.
Die betroffene Safe-Adresse (0x40e93a52f6af9fcd3b476aedadd7feabd9f7aba8) wurde am frühen 15. September angegriffen. Die Sicherheitsüberwachung identifizierte zwei Transaktionen, die für den Verlust verantwortlich waren. Die verfügbaren Beweise deuten auf das benutzerdefinierte Modul des Wallets und dessen Interaktion mit einem bösartigen Hook hin, nicht auf eine Schwachstelle in den zentralen Smart-Account-Verträgen von Safe.
Benutzerdefiniertes Modul leitete Vermögenswerte in einen bösartigen Pool um
Der Angriff nutzte einen öffentlichen Keeper-Multicall, um ein benutzerdefiniertes Uni-V4-LP-Safe-Modul aufzurufen, das mit dem Konto verbunden war. Die Ausführung leitete Liquidität in einen Uniswap-v4-Pool, der mit einem vom Angreifer kontrollierten Hook erstellt worden war. Dadurch konnte die bösartige Routing-Logik auf die in der Position enthaltenen Vermögenswerte zugreifen.
Der Hook wandelte anschließend die aEthrsETH-Position des Opfers in übertragbares rsETH um. aEthrsETH steht für an Aave geliefertes rsETH. Der Angreifer musste die Position daher zunächst aus ihrer Aave-Receipt-Token-Form herauslösen, bevor das zugrunde liegende rsETH extrahiert werden konnte.
Die Modularchitektur von Safe ermöglicht autorisierten Erweiterungen, Transaktionen unabhängig vom normalen Multisignatur-Ablauf auszuführen. Module können komplexe DeFi-Operationen automatisieren, doch Safe warnt, dass sie sicherheitskritisch sind, da ein aktiviertes bösartiges oder verwundbares Modul beliebige Transaktionen von einem Konto ausführen kann. Die Dokumentation von Safe zu Modulen ist hier verfügbar.
Da der öffentliche Keeper-Multicall das benutzerdefinierte Modul des Kontos aufrufen konnte, erstreckte sich die relevante Sicherheitsgrenze über den Signaturablauf von Safe hinaus auf die Autorisierung und Transaktionslogik des Moduls. Bei vergleichbaren DeFi-fähigen Konten würde eine Prüfung des Safe-Vertrags allein die aktive Ausführungsoberfläche des Kontos daher nicht vollständig abbilden.
Der Angriff kompromittierte weder die zentralen Multisig-Verträge von Safe noch die Signaturschlüssel oder Ethereum selbst. Der identifizierte Fehlerpfad betraf das benutzerdefinierte Modul des Kontos und einen vom Angreifer kontrollierten Uniswap-v4-Hook. Eine ähnliche Abgrenzung zeigte sich im Mai, als ein Exploit des SquidRouterModule 86 Safe-Konten auf Ethereum und Base leerte, während die zugrunde liegenden Safe-Verträge außerhalb des identifizierten Fehlerpfads blieben.
MEV-Bot vereinnahmte die Extraktion
Die Angriffstransaktion wurde innerhalb des Blocks von einer mit der Adresse verbundenen MEV-Operation abgefangen, die Etherscan als MEV Frontrunner Yoink bezeichnet.
Der Bot setzte die ursprüngliche Extraktion vor und vereinnahmte den profitablen Transaktionspfad, bevor der Angreifer ihn wie eingereicht abschließen konnte. Das Opfer verlor das rsETH dennoch, weil die zugrunde liegende bösartige Ausführung erfolgreich war. Die Reihenfolge der Transaktionen bestimmte jedoch, welche externe Adresse letztlich einen Großteil des extrahierten Werts erhielt.
Das Safe-Wallet behielt lediglich ein NFT aus dem Liquiditätspool, das die Liquiditätsposition repräsentierte, statt der rsETH-besicherten Position, die es vor den Transaktionen gehalten hatte.
rsETH gerät erneut in den Fokus der Sicherheitsbranche
rsETH ist der Liquid-Restaking-Token von Kelp DAO und bleibt in die Kreditvergabe- und Liquiditätsmärkte von Ethereum integriert. Seine Nutzung innerhalb von Aave erzeugte die aEthrsETH-Sicherheit, die an dem Wallet-Abfluss beteiligt war.
Auch der Kelp-Token war Anfang dieses Jahres von einer erheblichen Sicherheitsstörung betroffen. Ein Kelp-DAO-Exploit im April setzte rund $292 Millionen in rsETH aus einer Cross-Chain-Infrastruktur frei und führte zu erheblichen nachgelagerten Risiken an den DeFi-Kreditmärkten.
Der Verlust vom 15. September ist ein separater Vorfall. Die aktuellen Beweise konzentrieren sich auf die Modulausführung des einzelnen Safe-Kontos, den vom Angreifer kontrollierten Uniswap-v4-Hook und die daraus resultierende Umwandlung der Aave-besicherten rsETH-Position des Wallets. Eine umfassendere Kompromittierung von Safe, Aave, Kelp DAO oder dem rsETH-Tokenvertrag wurde nicht festgestellt.
Quelle: Crypto Adventure.
