Zuletzt gab es viel Aufmerksamkeit für den „Gegenangriff“, um Gelder aus MakerDao Vaults über das Oasis Multisig zu verschieben. In der Zwischenzeit haben wir einige Anfragen erhalten, ob BlockSec der „Whitehat“ hinter dieser Operation ist, da wir an dem Gegenangriff beteiligt waren, um Platypus am 18. Februar 2,4 Millionen US-Dollar zu retten. Wir möchten klarstellen, dass BlockSec nicht an irgendeiner der Aktionen im Jump-Fall beteiligt ist. Nach einer detaillierten Analyse (Lob an die exzellente Analyse, die in BlockWorks von Dan Smith veröffentlicht wurde) denken wir, dass die Art und Weise, wie der „Gegenangriff“ von Jump involviert ist, grundlegend anders ist als im Fall Platypus.
Nach unserer Analyse sind jedoch die entscheidenden Schritte des Gegenangriffs:
- Deaktivierung der verzögerten Ausführung. Dies ist Aufgabe des Eigentümers des Service Registry-Vertrags, der das Oasis Multisig-Wallet ist.
- Änderung der registrierten Vertragsadressen für kritische Rollen, einschließlich AUTOMATION_EXECUTOR für den AutomationBot-Vertrag und MCD_VIEW, MULTIPLY_PROXY_ACTIONS für den CloseCommand-Vertrag. Dies ermöglicht es dem Oasis Multisig-Wallet, den AutomationBot direkt aufzurufen, um den Schließbefehl auszuführen, dessen tatsächliche ausgeführte Operation durch eine neue ersetzt wird, um die Vaults des Exploiters zu verschieben.
Unsere Analyse legt nahe, dass diese entscheidenden Schritte NICHT auf den behaupteten Schwachstellen im Admin-Multisig-Zugang beruhen.
Haftungsausschluss: Dieser Blogbeitrag basiert auf On-Chain-Transaktionen und öffentlichen Informationen. Wenn Sie Fragen oder Kommentare haben, können Sie sich gerne an uns wenden: contact@blocksec.com.
Der Gesamtprozess
Mehrere Adressen waren während dieser Operation beteiligt. Wir listen einige davon in folgendem Google Doc auf.
https://docs.google.com/spreadsheets/d/1k0PEci8wQ16X7JT7KRq9SvhaCA2yerJcqLn6EfAoPZs/edit?usp=sharing
Speziell ist die übergeordnete Idee für den Jump-Gegenangriff wie folgt.
-
Die Maker Vaults des Exploiters können vom Oasis AutomationBot Smart Contract verwaltet werden, da der Exploiter die von Oasis angebotenen Automatisierungsfunktionen zum Verkaufen und Kaufen 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 Contract, die vom Oasis Multisig-Wallet aktualisiert werden kann. Die Aktualisierung der Konfiguration des Oasis Service Registry Contracts verfügt jedoch über einen Mechanismus zur verzögerten Ausführung, der vom Oasis Multisig-Wallet deaktiviert werden kann.
-
Der tatsächlich ausgeführte Vertrag und die Funktion des AutomationBots sind ebenfalls im Oasis Service Registry konfigurierbar.
Das Oasis Multisig-Wallet deaktiviert also zunächst die verzögerte Ausführung des Oasis Service Registry Contracts und ändert die Konfiguration im Oasis Service Registry Contract, um die Rolle AUTOMATION_EXECUTOR auf sich selbst (Multisig-Wallet) zu setzen. Die Änderung tritt sofort in Kraft. Anschließend ruft das Multisig-Wallet den AutomationBot auf, um einen Befehl auszuführen, der die Maker Vaults des Exploiters übernehmen kann (verschieben und geben). Da der AutomationBot die Vaults des Exploiters verwalten kann, kann die gesamte Operation erfolgreich sein.
Wir glauben, dass dieser Prozess grundlegend anders ist als im Fall Platypus, wo wir eine Schwachstelle im Vertrag des Angreifers fanden und diese mit Platypus teilten. Dann nutzte Platypus den Vertrag des Angreifers aus, um die ihm gehörenden Gelder zu verschieben. Im Jump-Fall deaktiviert das Oasis Multisig jedoch den Mechanismus der verzögerten Ausführung, aktualisiert die kritischen Konfigurationen, die das Verhalten des Vertrags vollständig ändern können, und nutzt die Verwaltungsrolle des AutomationBots, um auf die Maker Vaults im Namen des Exploiters zuzugreifen.
Im Folgenden werden wir den gesamten Jump-„Gegenangriff“ detailliert erläutern.
Die detaillierten Schritte
Die Operation umfasst mehrere Protokolle und Parteien, darunter Jump, Oasis, Wormhole Exploiter und Maker. Beachten Sie, dass Maker während der Operation keine Maßnahmen ergriffen hat.
Speziell erstellt der Exploiter Maker Vaults (30100 und 30179) und verwendet ETH als Sicherheit, und borgt sich DAI aus der Vault. Der Exploiter nutzte auch die von Oasis angebotenen Automatisierungsfunktionen zum Verkaufen und Kaufen, um das Verhältnis der Besicherung des Maker Vaults zu verwalten.
Um den Oasis-Automatisierungsdienst nutzen zu können, muss ein von Oasis angebotener Smart Contract namens AutomationBot zur Verwaltungsliste der Vault hinzugefügt werden. Das bedeutet, dass der AutomationBot die Kontrolle über den vom Exploiter erstellten Maker Vault hat. Danach kann der AutomationBot die Vault manipulieren und die Sicherheit und Schulden der Vault in eine andere übertragen, die von Jump kontrolliert wird. Dies ist der grundlegende Prozess des „Gegenangriffs“. Beachten Sie, dass zur Ausführung des AutomationBots die Transaktion von der Adresse initiiert 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 des Oasis Service Registry
Diese Transaktion deaktiviert die verzögerte Ausführung des Oasis Service Registry durch Aufruf von changeRequiredDela(0). Beachten Sie, dass das Oasis Service Registry ein Smart Contract ist, der kritische Konfigurationsinformationen speichert, die vom AutomationBot verwendet werden. Typischerweise hat die Konfigurationsänderung einen Mechanismus zur verzögerten Ausführung für kritische Operationen, z. B. updateNamedService, die im „Gegenangriff“ verwendet werden. Normalerweise ist die verzögerte Ausführung ein Sicherheitsmechanismus zur Transparenz, damit die Aktualisierung kritischer Informationen nicht sofort wirksam wird und andere einen genaueren Blick darauf werfen können.
Beachten Sie, dass die Ausführung von changeRequiredDelay aufgrund der verzögerten Ausführung (da die Änderung von reqDelay noch nicht wirksam ist) eingeschränkt ist.
Schritt 3: Durchführung des Gegenangriffs
Diese Transaktion führt den Gegenangriff durch. Tauchen wir ein in die Ausführungsspur, die von Phalcon, dem von BlockSec entwickelten Transaktionsanalysetool, ausgegeben wird.
Beachten Sie, dass diese Transaktion von der Adresse 04e1 initiiert und über das Oasis Multisig-Wallet ausgeführt wird, was bedeutet, dass die Operation von mindestens vier Unterzeichnern bestätigt wurde.
Schritt 3.1 Deaktivierung der verzögerten Ausführung
Wie in der Spur gezeigt, wird die Verzögerung erneut auf Null gesetzt. Dies dient der Anwendung der Aktion zur Deaktivierung der verzögerten Ausführung in Schritt 2.
Schritt 3.2: Erstellung von zwei Verträgen und Aktualisierung des Service Registry
Zwei neue Verträge werden erstellt, die als MCD_VIEW und MULTIPLY_PROXY_ACTIONS Verträge verwendet werden.
- MCD_VIEW: 0xceca8d8410797bc6c575fd8ba957708d1e85ed36
- MULTIPLY_PROXY_ACTIONS: 0xcaef24016d0fba2c1a9427371e0d79c5781b6ea8
Anschließend werden diese beiden Verträge im Oasis Service Registry aktualisiert.
Schritt 3.3: Änderung des Automation Executor
Das Oasis Multisig wird als AUTOMATION_EXECUTOR im ServiceRegistry-Vertrag registriert. Dies ist notwendig, da nur der mit dieser Rolle registrierte Vertrag den AutomationBot-Vertrag aufrufen kann.
Schritt 3.4: Aufforderung an den AutomationBot, die Vault des Exploiters zu schließen
Der kritische Prozess beginnt mit der execute-Funktion des AutomationBots. Die detaillierten ausgeführten Funktionen werden über die Argumente übergeben.
Um den gesamten Prozess zu verstehen, werfen wir zunächst einen Blick auf diese Funktion.
Die übergeordnete Logik besteht darin, dass der Bot zunächst DAI aus der Vault zieht (Zeile 268) und dann den konkretisierten Befehlsvertrag aufruft, um ihn auf der Vault (angegeben durch cdpId) auszuführen (Zeile 274 bis 278). Während des Prozesses ist die Adressse des Befehls der CloseCommand-Vertrag. Danach ist eine Prüfung von isExecutionCorrect erforderlich.
Das Folgende zeigt die execute-Funktion des CloseCommand-Vertrags. Er holt die tatsächliche Executor-Vertragsadresse aus dem Service Registry Contract unter Verwendung des KEY MULTIPLY_PROXY_ACTIONS. Beachten Sie, dass die Vertragsadresse, die MULTIPLY_PROXY_ACTIONS entspricht, durch eine neue ersetzt wurde. Als solches ist die tatsächliche Ausführung des CloseCommand steuerbar, um beliebige Operationen im neuen Vertrag durchzuführen.
Denken Sie daran, dass isExecutionCorrect im CloseCommand aufgerufen wird, um zu prüfen, ob die Ausführung erfolgreich war (Zeile 278 in AutomationBot.sol). Da die View-Adresse aktualisiert wurde, kann der Rückgabewert von viewerContract.getVaultInfo(cdpId) ein beliebiger Wert sein, der die Prüfung in Zeile 24 (CloseCommand.sol) besteht.
Nachdem wir den Code durchlaufen haben, betrachten wir die Ausführungsspur. Aus der Spur können wir entnehmen, dass der automationBot den CloseCommand-Vertrag aufruft. Der CloseCommand-Vertrag kann den ersetzten MULTIPLY_PROXY_ACTIONS-Vertrag aufrufen, um eine neue Vault (30231) zu eröffnen, die Vault 30100 (die des Exploiters) in 30231 (die neu erstellte) zu verschieben und die neue Vault 30231 dem Oasis Multisig-Wallet zu geben. Ein ähnlicher Vorgang wird mit der anderen Vault des Exploiters (30179) durchgeführt.
Schritt 3.5 Wiederherstellung des Zustands
Stellen Sie den geänderten Eintrag im Service Registry wieder her und aktivieren Sie die verzögerte Ausführung wieder.
Schritt 3.6 Übergabe der Vaults an die Adresse 1536
Nun werden die neuen Vaults (30231 und 30232) vom Oasis Multisig-Wallet kontrolliert. Dann werden die Vaults in diesen Transaktionen [TX1 TX2] an 0x15364305a06ba3ac6ba13dfe97ca0bad639adf41 übergeben. Anschließend kann diese Adresse die Schulden in der Vault begleichen und die Sicherheit (Ethereum) abheben. Da die Besicherungsrate hoch ist (ungefähr 293 % für Vault 30100), kann die Rückzahlung und Abhebung der Sicherheit rund 120.000 Ethereum bei Kosten von etwa 76 Millionen Schulden aus Vault 30100 zurückbringen. Leser können sich für weitere Informationen zu diesen Operationen im Maker Protocol Dokument informieren.
Über BlockSec
BlockSec ist ein wegweisendes Blockchain-Sicherheitsunternehmen, das 2021 von einer Gruppe weltweit führender Sicherheitsexperten gegründet wurde. Das Unternehmen engagiert sich für die Verbesserung der Sicherheit und Benutzerfreundlichkeit der aufstrebenden Web3-Welt, um deren Massenadoption zu fördern. Zu diesem Zweck bietet BlockSec Sicherheitsaudits für Smart Contracts und EVM-Chains, die Phalcon-Plattform für die Sicherheitsentwicklung und die proaktive Blockierung von Bedrohungen, die MetaSleuth-Plattform für die Nachverfolgung von Geldern und die Untersuchung sowie die MetaSuites-Erweiterung für Web3-Entwickler, um effizient in der Krypto-Welt zu surfen.
Bis heute hat das Unternehmen über 300 angesehene Kunden wie MetaMask, Uniswap Foundation, Compound, Forta und PancakeSwap betreut und in zwei Finanzierungsrunden von namhaften Investoren, darunter Matrix Partners, Vitalbridge Capital und Fenbushi Capital, Dutzende Millionen US-Dollar erhalten.
Offizielle Website: https://blocksec.com/ Offizieller Twitter-Account: https://twitter.com/BlockSecTeam
