In letzter Zeit gab es viel Aufmerksamkeit für den „Counter-Exploit“, bei dem Gelder aus einem MakerDao-Vault unter Verwendung des Oasis-Multisig verschoben wurden. In der Zwischenzeit haben wir einige Anfragen erhalten, ob BlockSec der „Whitehat“ hinter dieser Operation sei, da wir am 18. Februar am Counter-Exploit zur Rettung von 2,4 Mio. für Platypus beteiligt waren. Wir möchten klarstellen, dass BlockSec an keiner der Aktionen im Fall Jump beteiligt ist. Nach einer detaillierten Analyse (ein Dank an die exzellente Analyse, die von Dan Smith auf BlockWorks veröffentlicht wurde), sind wir der Meinung, dass die bei dem Jump-„Counter-Exploit“ angewandte Methode sich grundlegend vom Platypus-Fall unterscheidet.
Darüber hinaus ist der Counter-Exploit laut der Stellungnahme von Oasis aufgrund einer Schwachstelle im Administrator-Multisig-Zugriff möglich
Basierend auf unserer Analyse sind jedoch die entscheidenden Schritte des Counter-Exploits:
- Die Deaktivierung der verzögerten Ausführung (delayed execution). Dies ist darauf ausgelegt, vom Eigentümer des Service-Registry-Vertrags durchgeführt zu werden, was dem Oasis-Multisig-Wallet entspricht.
- Die Änderung der registrierten Vertragsadresse für kritische Rollen, einschließlich AUTOMATION_EXECUTOR für den AutomationBot-Vertrag und MCD_VIEW sowie MULTIPLY_PROXY_ACTIONS für den CloseCommand-Vertrag. Dies ermöglicht es dem Oasis-Multisig-Wallet, den AutomationBot direkt aufzurufen, um den Befehl zum Schließen auszuführen, wobei die eigentlich ausgeführte Operation durch eine neue ersetzt wird, um die Vaults des Angreifers zu verschieben.
Unsere Analyse legt nahe, dass diese entscheidenden Schritte NICHT auf die behaupteten Schwachstellen im Administrator-Multisig-Zugriff zurückzuführen sind.
Haftungsausschluss: Dieser Blogbeitrag basiert auf On-Chain-Transaktionen und öffentlichen Informationen. Falls Sie Fragen oder Anmerkungen haben, können Sie uns gerne unter [email protected] kontaktieren.
Der Gesamtprozess
Während dieser Operation waren einige Adressen beteiligt. Wir führen einige davon im folgenden Google Doc auf.
https://docs.google.com/spreadsheets/d/1k0PEci8wQ16X7JT7KRq9SvhaCA2yerJcqLn6EfAoPZs/edit?usp=sharing
Die übergeordnete Idee für den Jump-Counter-Exploit ist spezifisch wie folgt:
-
Die Maker-Vaults des Angreifers können durch den Oasis AutomationBot-Smart-Contract verwaltet werden, da der Angreifer die von Oasis angebotenen Auto-Verkaufs- und Kaufdienste aktiviert hat.
-
Der AutomationBot kann nur von der Adresse mit der Rolle AUTOMATION_EXECUTOR betrieben werden. Diese Adresse ist eine Konfiguration im Oasis-Service-Registry-Vertrag, die durch das Oasis-Multisig-Wallet aktualisiert werden kann. Die Aktualisierung der Konfiguration des Oasis-Service-Registry-Vertrags verfügt jedoch über einen Mechanismus zur verzögerten Ausführung, der vom Oasis-Multisig-Wallet deaktiviert werden kann.
-
Der tatsächliche Vertrag und die Funktion, die vom AutomationBot ausgeführt werden, sind ebenfalls im Oasis-Service-Registry konfigurierbar.
Das Oasis-Multisig-Wallet deaktiviert also zunächst die verzögerte Ausführung des Oasis-Service-Registry-Vertrags und ändert die Konfiguration im Oasis-Service-Registry-Vertrag dahingehend, dass die Rolle AUTOMATION_EXECUTOR auf sich selbst (das Multisig-Wallet) gesetzt wird. Die Änderung ist sofort wirksam. Dann ruft das Multisig-Wallet den AutomationBot auf, um einen Befehl auszuführen, der die Maker-Vaults des Angreifers übernehmen kann (Verschieben und Übertragen). Da der AutomationBot die Vaults des Angreifers verwalten kann, kann die gesamte Operation erfolgreich sein.
Wir halten diesen Prozess für grundlegend verschieden vom Platypus-Fall, bei dem wir eine Schwachstelle im Vertrag des Angreifers fanden und diese mit Platypus teilten. Platypus nutzte dann den Vertrag des Angreifers aus, um die Gelder, die zu ihnen selbst gehörten, zu verschieben. Im Fall Jump hingegen deaktiviert das Oasis-Multisig den Mechanismus der verzögerten Ausführung, aktualisiert kritische Konfigurationen, die das Verhalten des Vertrags vollständig ändern können, und nutzt die Verwaltungsrolle des AutomationBot, um im Namen des Angreifers die Maker-Vaults zu bedienen.
Im Folgenden werden wir den gesamten Jump-„Counter-Exploit“ darlegen.
Die detaillierten Schritte
Die Operation umfasst mehrere Protokolle und Parteien, einschließlich Jump, Oasis, Wormhole-Angreifer und Maker. Beachten Sie, dass Maker während der Operation keinerlei Maßnahmen ergreift.
Konkret erstellt der Angreifer Maker-Vaults (30100 und 30179), verwendet ETH als Sicherheit und leiht DAI aus dem Vault. Der Angreifer nutzte außerdem die von Oasis angebotenen Auto-Verkaufs- und Kaufdienste, um das Besicherungsverhältnis (Collateralization Ratio) des Maker-Vaults zu verwalten.
Um den Oasis-Automatisierungsdienst nutzen zu können, muss ein Smart Contract namens AutomationBot, der von Oasis angeboten wird, zur Verwaltungsliste des Vaults hinzugefügt werden. Das bedeutet, dass der AutomationBot Kontrolle über den vom Angreifer erstellten Maker-Vault hat. Danach kann der AutomationBot den Vault manipulieren und die Sicherheiten sowie die Schulden des Vaults auf einen anderen übertragen, der von Jump kontrolliert wird. Dies ist der grundlegende Ablauf des „Counter-Exploits“. Beachten Sie, dass die Transaktion zur Aktivierung des AutomationBot von der Adresse aus aufgerufen werden muss, die als AUTOMATION_EXECUTOR im ServiceRegistry-Vertrag registriert ist.
Schritt 1: Hinzufügen der Adresse 04e1 zum Oasis-Multisig-Wallet
Die Transaktion fügt die Adresse 04e1 zum Oasis-Multisig-Wallet hinzu. Dieses Wallet hat derzeit 12 Adressen mit Bestätigungen von vier Unterzeichnern.
Schritt 2: Deaktivierung der verzögerten Ausführung der Oasis-Service-Registry
Diese Transaktion deaktiviert die verzögerte Ausführung der Oasis-Service-Registry durch Aufruf von changeRequiredDela(0). Beachten Sie, dass die Oasis-Service-Registry ein Smart Contract ist, der kritische Konfigurationsinformationen speichert, die vom AutomationBot verwendet werden. Normalerweise verfügt die Konfigurationsänderung für kritische Operationen, z. B. updateNamedService, über einen Mechanismus zur verzögerten Ausführung, der beim „Counter-Exploit“ verwendet wird. Üblicherweise ist die verzögerte Ausführung ein Sicherheitsmechanismus für Transparenz, sodass die Aktualisierung kritischer Informationen nicht sofort wirksam wird und andere die Möglichkeit haben, diese zu überprüfen.
Beachten Sie, dass die Ausführung zum Aufruf von changeRequiredDelay durch die verzögerte Ausführung eingeschränkt ist (da die Änderung an reqDelay noch nicht wirksam geworden ist).
Schritt 3: Durchführung des Counter-Exploits
Diese Transaktion führt den Counter-Exploit durch. Werfen wir einen Blick auf die Ausführungsspur (Execution Trace), die von Phalcon ausgegeben wurde, dem von BlockSec entwickelten Tool zur Transaktionsanalyse.
Beachten Sie, dass diese Transaktion von der Adresse 04e1 initialisiert und über das Oasis-Multisig-Wallet ausgeführt wird, was bedeutet, dass die Operation von mindestens vier Unterzeichnern signiert wurde.
Schritt 3.1: Deaktivierung der verzögerten Ausführung
Wie im Trace zu sehen, wird die Verzögerung erneut auf null gesetzt. Dies dient dazu, die Aktion der Deaktivierung der verzögerten Ausführung aus Schritt 2 anzuwenden.
Schritt 3.2: Erstellung von zwei Verträgen und Aktualisierung der Service-Registry
Es werden zwei neue Verträge erstellt, die als MCD_VIEW- und MULTIPLY_PROXY_ACTIONS-Verträge dienen werden.
- MCD_VIEW: 0xceca8d8410797bc6c575fd8ba957708d1e85ed36
- MULTIPLY_PROXY_ACTIONS: 0xcaef24016d0fba2c1a9427371e0d79c5781b6ea8
Anschließend werden diese beiden Verträge im Oasis-Service-Registry-Vertrag aktualisiert.
Schritt 3.3: Änderung des Automation Executor
Das Oasis-Multisig ist im ServiceRegistry-Vertrag als AUTOMATION_EXECUTOR registriert. Dies ist notwendig, da nur der mit dieser Rolle registrierte Vertrag den AutomationBot-Vertrag aufrufen kann.
Schritt 3.4: Den AutomationBot anweisen, den Vault des Angreifers zu schließen
Der kritische Prozess beginnt mit der Funktion execute des AutomationBot. Die detailliert ausgeführten Funktionen werden durch die Argumente übergeben.
Um den gesamten Prozess zu verstehen, schauen wir uns zunächst diese Funktion an.
Die übergeordnete Logik ist, dass der Bot zunächst DAI aus dem Vault abhebt (Zeile 268) und dann den vertraglich vereinbarten Befehlsvertrag aufruft, um ihn auf dem Vault auszuführen (angegeben durch cdpId) (Zeile 274 bis Zeile 278). Während des Prozesses ist die Befehlsadresse der CloseCommand-Vertrag. Danach ist eine Überprüfung durch isExecutionCorrect erforderlich.
Das Folgende zeigt die Funktion execute des CloseCommand-Vertrags. Sie erhält die tatsächliche Executor-Vertragsadresse aus dem Service-Registry-Vertrag unter Verwendung des Keys MULTIPLY_PROXY_ACTIONS. Beachten Sie, dass die Vertragsadresse, die MULTIPLY_PROXY_ACTIONS entspricht, auf eine neue aktualisiert wurde. Daher ist die tatsächliche Ausführung des CloseCommand steuerbar, um beliebige Operationen im neuen Vertrag auszuführen.
Denken Sie daran, dass isExecutionCorrect auf dem CloseCommand aufgerufen wird, um zu überprüfen, ob die Ausführung erfolgreich war (Zeile 278 in AutomationBot.sol). Da die View-Adresse aktualisiert wurde, könnte der Rückgabewert des Checks viewerContract.getVaultInfo(cdpId) ein beliebiger Wert sein, der die Überprüfung in Zeile 24 (CloseCommand.sol) bestehen kann.
Nachdem wir den Code durchgegangen sind, werfen wir einen Blick auf die Ausführungsspur. Aus der Spur sehen wir, dass der AutomationBot den CloseCommand-Vertrag aufruft. Der CloseCommand-Vertrag kann den ersetzten MULTIPLY_PROXY_ACTIONS-Vertrag aufrufen, um einen neuen Vault (30231) zu öffnen, den Vault 30100 (den des Angreifers) auf 30231 (den neu erstellten) zu verschieben und den neuen Vault 30231 an das Oasis-Multisig-Wallet zu übertragen. Eine ähnliche Operation wird beim anderen Vault des Angreifers (30179) durchgeführt.
Schritt 3.5: Wiederherstellung des Zustands
Stellen Sie den geänderten Eintrag in der Service-Registry wieder her und aktivieren Sie die verzögerte Ausführung erneut.
Schritt 3.6: Übertragung der Vaults an Adresse 1536
Nun werden die neuen Vaults (30231 und 30232) vom Oasis-Multisig-Wallet kontrolliert. Dann werden die Vaults in diesen Transaktionen an 0x15364305a06ba3ac6ba13dfe97ca0bad639adf41 übertragen [TX1 TX2]. Diese Adresse kann dann die Schulden im Vault begleichen und die Sicherheiten (Ethereum) abheben. Da die Besicherungsrate hoch ist (ca. 293% für Vault 30100), können durch Rückzahlung und Abhebung der Sicherheiten etwa 120.000 Ethereum zurückgewonnen werden, bei Kosten von etwa 76 Mio. Schulden aus Vault 30100. Leser können sich für weitere Informationen zu diesen Operationen an die Maker-Protokoll-Dokumentation wenden.
Über BlockSec
BlockSec ist ein bahnbrechendes Blockchain-Sicherheitsunternehmen, das 2021 von einer Gruppe weltweit ausgezeichneter Sicherheitsexperten gegründet wurde. Das Unternehmen engagiert sich für die Verbesserung der Sicherheit und Benutzerfreundlichkeit für die aufstrebende Web3-Welt, um deren breite Akzeptanz zu fördern. Zu diesem Zweck bietet BlockSec Sicherheitsaudits für Smart Contracts und EVM-Chains Sicherheits-Audits an, die Phalcon-Plattform für Sicherheitsentwicklung und das proaktive Blockieren von Bedrohungen, die MetaSleuth-Plattform für die Verfolgung und Untersuchung von Geldern sowie die MetaSuites-Erweiterung für Web3-Entwickler, um effizient in der Kryptowelt zu navigieren.
Bis heute hat das Unternehmen über 300 geschätzte Kunden wie MetaMask, die Uniswap Foundation, Compound, Forta und PancakeSwap bedient und in zwei Finanzierungsrunden Dutzende Millionen US-Dollar von herausragenden Investoren erhalten, darunter Matrix Partners, Vitalbridge Capital und Fenbushi Capital.
Offizielle Website: https://blocksec.com/
Offizieller Twitter-Account: https://twitter.com/BlockSecTeam
