Angriff auf das DeFi-Protokoll Abracadabra
Das DeFi-Protokoll Abracadabra hat 1,8 Millionen Dollar verloren, nachdem ein Angreifer einen einfachen Logikfehler in seiner Batch-Funktion ausnutzte. Analysten von Hacken berichten, dass der Angreifer die Gelder bereits über Tornado Cash gewaschen hat.
Details des Angriffs
Anfang Oktober verlor Abracadabra, ein DeFi-Kreditprotokoll, das es Nutzern ermöglicht, seinen Stablecoin MIM unter Verwendung von hinterlegten Token als Sicherheiten zu leihen, erneut etwa 1,8 Millionen Dollar. Der Angriff wurde durch einen Logikfehler in der Batch-Funktion des Protokolls ermöglicht, der es dem Angreifer erlaubte, ohne Sicherheiten zu leihen. Dies geschah ähnlich wie bei einem geforkten Projekt, das nur Tage zuvor betroffen war, so die Analysten der Blockchain-Sicherheitsfirma Hacken in einer Forschungsnotiz, die mit crypto.news geteilt wurde.
Funktionsweise von Abracadabra
Abracadabra wurde ins Leben gerufen, um Nutzern die Möglichkeit zu geben, zinstragende Token als Sicherheiten zu nutzen und einen an den US-Dollar gebundenen Token namens Magic Internet Money (MIM) zu leihen. Das System basiert auf zwei Komponenten: Cauldrons, die die Kreditregeln verwalten, und DegenBox, dem gemeinsamen Tresor, der tatsächlich die Token hält. Kurz gesagt: Nutzer hinterlegen Sicherheiten in einem Cauldron, während die DegenBox das Geld im Hintergrund verwaltet.
Der Logikfehler im Detail
Die kurze Zusammenfassung dessen, was schiefgelaufen ist: Ein Sicherheitsflag, das eine endgültige Überprüfung erzwingen sollte, ob ein Kreditnehmer tatsächlich Sicherheiten hat, wurde innerhalb einer einzigen Transaktion deaktiviert. Wie im Bericht von Hacken dargelegt,
„nutzte der Angreifer einen Logikfehler in der Cook-Funktion von Abracadabra aus, bei dem er MIM-Token leihen konnte und dann sofort das Validierungsflag zurücksetzte, das überprüfen sollte, ob er genügend Sicherheiten hatte.“
Dadurch war es möglich, einen einmaligen, unbesicherten Kredit über mehrere Cauldrons hinweg zu erhalten.
Ablauf des Angriffs
So funktionierte der Ablauf in einfachen Worten: Abracadabra verwendet eine gebündelte Funktion namens Cook, die es Nutzern ermöglicht, mehrere Aktionen in einer Transaktion durchzuführen. Zum Beispiel können sie Sicherheiten hinterlegen und im selben Schritt leihen. Eine dieser Aktionen, der „Leihen“-Schritt, setzt ein Flag namens needsSolvencyCheck auf true, was bedeutet: „Überprüfen Sie am Ende dieser Transaktion, ob der Kreditnehmer solvent ist.“ Eine andere Aktion, die innerhalb desselben Batches ausgeführt werden kann, ruft _additionalCookAction(…) auf. Wie Hacken anmerkt, wurde diese Funktion als „virtuell“ deklariert und nie implementiert, sodass sie standardmäßig ein leeres Objekt zurückgab, bei dem alles auf false gesetzt war, einschließlich des needsSolvencyCheck-Flags.
Infolgedessen rief der Angreifer die Leihaktion auf, dann die Standardaktion, die das Flag zurücksetzte, und am Ende überprüfte das Protokoll nie die Solvenz. Die Analysten berichten, dass der Angreifer sechs Cauldrons gleichzeitig angriff und etwa 1,79 Millionen MIM entnahm, die er gegen ETH tauschte. Der Angreifer nutzte die Schwachstelle aus und durchlief systematisch sechs verschiedene Cauldrons, wobei er jeden einzelnen „unter Verwendung derselben Technik mit einem speziellen Cook-Funktionsaufruf“ entleerte, erklärten die Analysten.
Nach dem Angriff
Nach dem Tausch leitete der Angreifer die Gelder über Tornado Cash, ein Krypto-Mischprotokoll, hauptsächlich 10 ETH pro Transaktion, und sendete sie allmählich über den folgenden Tag. Dies ist nicht das erste Mal, dass der Code von Abracadabra’s CauldronV4 in Schwierigkeiten verwickelt war. In diesem Jahr gab es bereits andere Vorfälle, die verschiedene Randfälle in derselben Familie von Verträgen ausnutzten.
Reaktionen auf den Vorfall
Besonders interessant ist, wie schnell die geforkte Bereitstellung reagierte. Laut dem Bericht pausierte ein Fork namens Synnax oder entblannte seinen CauldronV4-Master in seiner eigenen DegenBox Tage vor dem Abracadabra-Abfluss, sodass das Fork-Team im Grunde die Notbremse zog, nachdem es dasselbe schwache Muster entdeckte. Dies deutet darauf hin, dass das Risiko für Teams, die den Code beobachteten, sichtbar war, auch wenn es nicht behoben wurde.
