Kürzlich gab es viel Aufmerksamkeit für den „Gegen-Exploit“, um Gelder aus MakerDao Vaults über das Oasis Multisig zu transferieren. In der Zwischenzeit haben wir einige Anfragen erhalten, ob BlockSec der „Whitehat“ hinter dieser Operation ist, da wir an dem Gegen-Exploit beteiligt waren, um Platypus am 18. Februar bei der Rettung von 2,4 Millionen zu helfen. Wir möchten klarstellen, dass BlockSec an keiner der Aktionen im Jump-Fall beteiligt ist. Nach einer detaillierten Analyse (Lob an die exzellente Analyse von Dan Smith in BlockWorks) sind wir der Meinung, dass die Art und Weise, wie der Jump „Gegen-Exploit“ durchgeführt wurde, sich grundlegend vom Platypus-Fall unterscheidet.
Aus unserer Analyse ergeben sich jedoch die Schlüsselschritte des Gegen-Exploits:
- Deaktivierung der verzögerten Ausführung. Dies soll vom Eigentümer des Service Registry-Vertrags, dem Oasis Multisig-Wallet, durchgeführt werden.
- Änderung der registrierten Vertragsadresse 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 Close-Befehl auszuführen, dessen tatsächliche Ausführung durch eine neue Operation ersetzt wird, um die Vaults des Exploiters zu verschieben.
Unsere Analyse deutet darauf hin, dass diese Schlüsselschritte NICHT auf den behaupteten Schwachstellen im Admin-Multisig-Zugriff beruhen.
Haftungsausschluss: Dieser Blogbeitrag basiert auf On-Chain-Transaktionen und öffentlichen Informationen. Wenn Sie Fragen oder Kommentare haben, kontaktieren Sie uns bitte unter [email protected].
Der Gesamtprozess
An dieser Operation waren mehrere Adressen beteiligt. Einige davon listen wir im folgenden Google Doc auf.
https://docs.google.com/spreadsheets/d/1k0PEci8wQ16X7JT7KRq9SvhaCA2yerJcqLn6EfAoPZs/edit?usp=sharing
Konkret lautet die grobe Idee hinter dem Jump-Gegen-Exploit wie folgt:
-
Die Maker Vaults des Exploiters können über den Oasis AutomationBot Smart Contract verwaltet werden, da der Exploiter die von Oasis angebotenen Automatisierungsdienste für den Verkauf und Kauf aktiviert hat.
-
Der AutomationBot kann nur von der Adresse mit der Rolle AUTOMATION_EXECUTOR bedient werden. Diese Adresse ist eine Konfiguration im Oasis Service Registry Vertrag, die vom Oasis Multisig-Wallet aktualisiert werden kann. Die Aktualisierung der Konfiguration des Oasis Service Registry Vertrags verfügt jedoch über einen Mechanismus für verzögerte Ausführung, der vom Oasis Multisig-Wallet deaktiviert werden kann.
-
Der eigentliche Vertrag und die vom AutomationBot ausgeführte Funktion sind ebenfalls im Oasis Service Registry konfigurierbar.
Das Oasis Multisig-Wallet deaktiviert also zuerst die verzögerte Ausführung des Oasis Service Registry Vertrags und ändert die Konfiguration im Oasis Service Registry Vertrags, um die Rolle AUTOMATION_EXECUTOR auf sich selbst (Multisig-Wallet) zu setzen. Die Änderung wird sofort wirksam. Dann ruft das Multisig-Wallet den AutomationBot auf, um einen Befehl auszuführen, der die Maker Vaults des Exploiters übernehmen kann (verschieben und übergeben). Da der AutomationBot die Vaults des Exploiters verwalten kann, kann die gesamte Operation erfolgreich sein.
Wir sind der Meinung, dass dieser Prozess sich grundlegend vom Platypus-Fall unterscheidet, wo wir eine Schwachstelle im Vertrag des Angreifers fanden und sie mit Platypus teilten. Dann nutzte Platypus den Vertrag des Angreifers, um die ihm gehörenden Gelder zu verschieben. Im Jump-Fall deaktiviert das Oasis Multisig jedoch den Mechanismus für verzögerte Ausführung, aktualisiert die kritischen Konfigurationen, die das Verhalten des Vertrags vollständig ändern können, und nutzt die Verwaltungsrolle des AutomationBot, um im Namen des Exploiters auf die Maker Vaults zuzugreifen.
Im Folgenden werden wir den gesamten Jump „Gegen-Exploit“ näher 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 Aktion durchführt.
Konkret erstellt der Exploiter Maker Vaults (30100 und 30179) und verwendet ETH als Sicherheit und leiht sich DAI aus der Vault. Der Exploiter nutzte auch die von Oasis angebotenen Automatisierungsdienste für den Verkauf und Kauf, um das Verhältnis der Sicherheit zur Schuld der Maker Vault 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 die vom Exploiter erstellte Maker Vault hat. Danach kann der AutomationBot die Vault manipulieren und die Sicherheit und Schuld der Vault auf eine andere, von Jump kontrollierte Vault übertragen. Dies ist der grundlegende Prozess des „Gegen-Exploits“. Beachten Sie, dass zur Auslösung des AutomationBot die Transaktion von der Adresse aus ausgelöst werden muss, die im ServiceRegistry Vertrag als AUTOMATION_EXECUTOR registriert ist.
Schritt 1: Adresse 04e1 zum Oasis Multisig-Wallet hinzufügen
Die Transaktion fügt die Adresse 04e1 zum Oasis Multisig-Wallet hinzu. Dieses Wallet hat derzeit 12 Adressen, mit vier erforderlichen Bestätigungen von 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 für verzögerte Ausführung für kritische Operationen, z. B. updateNamedService, die im „Gegen-Exploit“ verwendet werden. Normalerweise ist die verzögerte Ausführung ein Sicherheitsmechanismus für Transparenz, sodass die Aktualisierung kritischer Informationen nicht sofort wirksam wird und andere einen zweiten Blick darauf werfen können.
Beachten Sie, dass die Ausführung zum Aufruf von changeRequiredDelay durch die verzögerte Ausführung eingeschränkt ist (da die Änderung von reqDelay noch nicht wirksam ist).
Schritt 3: Durchführung des Gegen-Exploits
Diese Transaktion führt den Gegen-Exploit durch. Tauchen wir ein in die Ausführungsspuren, die von Phalcon, dem von BlockSec entwickelten Transaktionsanalyse-Tool, ausgegeben wurden.
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 zu sehen ist, wird die Verzögerung erneut auf Null gesetzt. Dies dient der Umsetzung der Aktion zur Deaktivierung der verzögerten Ausführung in Schritt 2.
Schritt 3.2: Erstellung von zwei Verträgen und Aktualisierung der Service Registry
Zwei neue Verträge werden 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 in den Oasis Service Registry Vertrag aktualisiert.
Schritt 3.3: Änderung des Automation Executors
Das Oasis Multisig wird im ServiceRegistry Vertrag als AUTOMATION_EXECUTOR registriert. Dies ist notwendig, da nur der registrierte Vertrag mit dieser Rolle den AutomationBot Vertrag aufrufen kann.
Schritt 3.4: Aufforderung des AutomationBot, die Vault des Exploiters zu schließen
Der kritische Prozess beginnt mit der execute-Funktion des AutomationBot. 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 grobe Logik ist, dass der Bot zuerst 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 Zeile 278). Während des Prozesses ist die Vertragsadresse der CloseCommand Vertrag. Danach ist eine Überprüfung von isExecutionCorrect erforderlich.
Das Folgende zeigt die execute-Funktion des CloseCommand Vertrags. Er ruft die tatsächliche Executor-Vertragsadresse aus dem Service-Registry-Vertrag unter Verwendung des KEY MULTIPLY_PROXY_ACTIONS ab. 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 durchzuführen.
Denken Sie daran, dass isExecutionCorrect auf dem 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 des Aufrufs von viewerContract.getVaultInfo(cdpId) ein beliebiger Wert sein, der die Prüfung in Zeile 24 (CloseCommand.sol) besteht.
Nachdem wir den Code durchgearbeitet haben, betrachten wir die Ausführungsspuren. Aus der Spur können wir ersehen, 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) auf 30231 (die neu erstellte) zu verschieben und die neue Vault 30231 dem Oasis Multisig-Wallet zu übergeben. Eine ähnliche Operation wird mit der anderen Vault des Exploiters (30179) durchgeführt.
Schritt 3.5 Wiederherstellung des Zustands
Wiederherstellung des geänderten Eintrags im Service Registry und erneute Aktivierung der verzögerten Ausführung.
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 [TX1 TX2] an 0x15364305a06ba3ac6ba13dfe97ca0bad639adf41 übertragen. Dann kann diese Adresse die Schuld in der Vault begleichen und die Sicherheit abheben (Ethereum). Da die Besicherungsrate hoch ist (ca. 293 % für Vault 30100), kann die Rückzahlung und Abhebung der Sicherheit rund 120.000 Ethereum einbringen, bei Kosten von ca. 76 Millionen Schulden aus Vault 30100. Leser können das Maker-Protokoll-Dokument für weitere Informationen zu diesen Operationen einsehen.
Über BlockSec
BlockSec ist ein führendes Unternehmen für Blockchain-Sicherheit, das 2021 von einer Gruppe weltweit herausragender Sicherheitsexperten gegründet wurde. Das Unternehmen engagiert sich für die Verbesserung der Sicherheit und Benutzerfreundlichkeit der aufkommenden Web3-Welt, um deren Massenadoption zu fördern. Zu diesem Zweck bietet BlockSec Sicherheitsprüfungsdienste für Smart Contracts und EVM-Ketten, die Phalcon-Plattform für die Sicherheitsentwicklung und proaktive Bedrohungsabwehr, die MetaSleuth-Plattform für die Geldverfolgung und 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, zweistellige Millionenbeträge in US-Dollar erhalten.
Offizielle Website: https://blocksec.com/ Offizielles Twitter-Konto: https://twitter.com/BlockSecTeam
