Kürzlich gab es viel Aufmerksamkeit für den „Gegen-Exploit“, um Gelder von MakerDao Vaults über Oasis Multisig zu verschieben. 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 nicht an den Aktionen im Jump-Fall beteiligt ist. Nach einer detaillierten Analyse (Lob an die ausgezeichnete Analyse, die von Dan Smith in BlockWorks veröffentlicht wurde) denken wir, dass die Art und Weise, wie der Jump „Gegen-Exploit“ funktioniert, grundlegend anders ist als der Fall Platypus.
Laut unserer Analyse sind die wichtigsten Schritte des Gegen-Exploits jedoch:
- Deaktivieren der verzögerten Ausführung. Dies soll vom Eigentümer des Service Registry-Vertrags, der Oasis Multisig-Wallet, durchgeführt werden.
- Ändern 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 der 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 deutet darauf hin, dass diese wichtigsten Schritte NICHT auf den angeblichen Schwachstellen im Admin-Multisig-Zugang beruhen.
Haftungsausschluss: Dieser Blogbeitrag basiert auf On-Chain-Transaktionen und öffentlichen Informationen. Wenn Sie Fragen oder Kommentare haben, kontaktieren Sie uns gerne unter [email protected].
Der Gesamtprozess
An dieser Operation waren mehrere Adressen beteiligt. Wir listen einige davon in folgendem Google Doc auf.
https://docs.google.com/spreadsheets/d/1k0PEci8wQ16X7JT7KRq9SvhaCA2yerJcqLn6EfAoPZs/edit?usp=sharing
Insbesondere ist die übergeordnete Idee für den Jump-Gegen-Exploit wie folgt.
-
Die Maker Vaults des Exploiters können vom Oasis AutomationBot-Smart-Contract verwaltet werden, da der Exploiter die von Oasis angebotenen Automatisierungsdienste zum Verkaufen und Kaufen 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 von der 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 von der 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.
Daher deaktiviert die Oasis Multisig-Wallet zuerst die verzögerte Ausführung des Oasis Service Registry-Vertrags und ändert die Konfiguration im Oasis Service Registry-Vertrag, um die Rolle AUTOMATION_EXECUTOR auf sich selbst (Multisig-Wallet) zu setzen. Die Änderung wird sofort wirksam. Dann ruft die 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 der Platypus-Fall, wo wir eine Schwachstelle im Angreifervertrag fanden und diese mit Platypus teilten. Dann nutzte Platypus den Angreifervertrag, um die Gelder zu verschieben, die ihnen gehörten. Im Jump-Fall deaktiviert die 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 AutomationBot, um auf den Maker's Vaults im Namen des Exploiters zuzugreifen.
Im Folgenden werden wir den gesamten Jump-„Gegen-Exploit“ 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.
Genauer gesagt, 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 zum Verkaufen und Kaufen, um das Verhältnis der Besicherung der Maker Vault zu verwalten.
Um den Oasis-Automatisierungsdienst zu nutzen, muss ein Smart Contract namens AutomationBot von Oasis zur Managementliste 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 Sicherheiten und Schulden der Vault auf eine andere übertragen, die von Jump kontrolliert wird. Dies ist der grundlegende Prozess des „Gegen-Exploits“. Beachten Sie, dass zur Ausführung des AutomationBot die Transaktion von der Adresse aufgerufen werden muss, die im ServiceRegistry-Vertrag als AUTOMATION_EXECUTOR registriert ist.
Schritt 1: Adresse 04e1 zur Oasis Multisig-Wallet hinzufügen
Die Transaktion fügt die Adresse 04e1 zur Oasis Multisig-Wallet hinzu. Diese Wallet enthält derzeit 12 Adressen mit vier erforderlichen Signaturen.
Schritt 2: Verzögerte Ausführung des Oasis Service Registry deaktivieren
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 verfügt die Konfigurationsänderung über 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 von changeRequiredDelay aufgrund der verzögerten Ausführung (da die Änderung an reqDelay noch nicht wirksam war) eingeschränkt ist.
Schritt 3: Durchführung des Gegen-Exploits
Diese Transaktion führt den Gegen-Exploit durch. Tauchen wir in die Ausführungsspur ein, die von Phalcon, dem von BlockSec entwickelten Transaktionsanalyse-Tool, ausgegeben wurde.
Beachten Sie, dass diese Transaktion von der Adresse 04e1 initialisiert und über die 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 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 der 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
Dann werden diese beiden Verträge in den Oasis Service Registry-Vertrag aktualisiert.
Schritt 3.3: Änderung des Automation Executors
Die Oasis Multisig wird als AUTOMATION_EXECUTOR im ServiceRegistry-Vertrag registriert. Dies ist notwendig, da nur der registrierte Vertrag mit dieser Rolle den AutomationBot-Vertrag aufrufen kann.
Schritt 3.4: Den AutomationBot anweisen, die Vaults 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 übergeordnete Logik besteht darin, dass der Bot zuerst DAI aus der Vault zieht (Zeile 268) und dann den konkreten Befehlsvertrag aufruft, um ihn auf der 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 von isExecutionCorrect erforderlich.
Das Folgende zeigt die execute-Funktion des CloseCommand-Vertrags. Er ruft die tatsächliche Executor-Vertragsadresse aus dem Service-Registry-Vertrag ab, indem er den Schlüssel MULTIPLY_PROXY_ACTIONS verwendet. 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 auf dem CloseCommand aufgerufen wird, um zu prüfen, ob die Ausführung erfolgreich war (Zeile 278 in AutomationBot.sol). Da die Ansichtsadresse aktualisiert wurde, kann der Rückgabewert der Prüfung 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ührungsspur. 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 öffnen, die Vault 30100 (die des Exploiters) in 30231 (die neu erstellte) zu verschieben und die neue Vault 30231 an die Oasis Multisig-Wallet zu geben. Eine ähnliche Operation 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 erneut.
Schritt 3.6 Übertragung der Vaults an Adresse 1536
Nun werden die neuen Vaults (30231 und 30232) von der Oasis Multisig-Wallet kontrolliert. Dann werden die Vaults in diesen Transaktionen [TX1 TX2] an 0x15364305a06ba3ac6ba13dfe97ca0bad639adf41 übergeben. Dann kann diese Adresse die Schulden in der Vault begleichen und die Sicherheiten (Ethereum) abheben. Da die Besicherungsrate hoch ist (ungefähr 293% für Vault 30100), können durch Rückzahlung und Abhebung der Sicherheiten rund 120.000 Ethereum zurückerhalten werden, bei Kosten von rund 76 Millionen Schulden aus Vault 30100. Leser können das Maker Protocol-Dokument für weitere Informationen zu diesen Operationen konsultieren.
Über BlockSec
BlockSec ist ein wegweisendes Blockchain-Sicherheitsunternehmen, das 2021 von einer Gruppe weltweit anerkannter Sicherheitsexperten gegründet wurde. Das Unternehmen hat sich zum Ziel gesetzt, die Sicherheit und Benutzerfreundlichkeit der aufkommenden Web3-Welt zu verbessern, um deren Massenadaption zu ermöglichen. Zu diesem Zweck bietet BlockSec Sicherheitsaudits für Smart Contracts und EVM-Chains an, die Phalcon-Plattform für die sichere Entwicklung und proaktive Bedrohungsabwehr, die MetaSleuth-Plattform für die Nachverfolgung und Untersuchung von Geldern sowie die MetaSuites-Erweiterung für Web3-Entwickler, um effizient in der Kryptowelt zu surfen.
Bis heute hat das Unternehmen über 300 angesehene Kunden wie MetaMask, Uniswap Foundation, Compound, Forta und PancakeSwap bedient und in zwei Finanzierungsrunden von namhaften Investoren wie Matrix Partners, Vitalbridge Capital und Fenbushi Capital zweistellige Millionenbeträge erhalten.
Offizielle Website: https://blocksec.com/
Offizieller Twitter-Account: https://twitter.com/BlockSecTeam
