In letzter Zeit 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 2,4 Millionen zu retten. Wir möchten klarstellen, dass BlockSec an keiner der Aktionen im Jump-Fall beteiligt ist. Nach einer detaillierten Analyse (Lob an die hervorragende Analyse von Dan Smith, veröffentlicht in BlockWorks) glauben wir, dass die Art und Weise, wie der Jump-„Gegen-Exploit“ durchgeführt wurde, sich grundlegend vom Fall Platypus unterscheidet.
Darüber hinaus ist laut der Aussage von Oasis der Gegen-Exploit aufgrund einer Schwachstelle im Admin-Multisig-Zugriff möglich
Unsere Analyse legt jedoch nahe, dass die wichtigsten Schritte des Gegen-Exploits Folgende sind:
- 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 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 Close-Befehl auszuführen, dessen tatsächliche ausgeführte Operation durch eine neue ersetzt wird, um die Vaults des Exploiter zu verschieben.
Unsere Analyse deutet darauf hin, dass diese wichtigen Schritte NICHT auf den angeblichen Schwachstellen im Admin-Multisig-Zugriff beruhen.
Haftungsausschluss: Dieser Blogbeitrag basiert auf On-Chain-Transaktionen und öffentlich zugänglichen Informationen. Wenn Sie Fragen oder Kommentare haben, kontaktieren Sie uns gerne 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
Speziell ist die übergeordnete Idee für den Jump-Gegen-Exploit wie folgt:
-
Die Maker-Vaults des Exploiter können durch den 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 vom Oasis Multisig Wallet aktualisiert werden kann. Die Aktualisierung der Konfiguration des Oasis Service Registry Vertrags hat jedoch einen Mechanismus für verzögerte Ausführung, der vom Oasis Multisig Wallet deaktiviert werden kann.
-
Der eigentliche Vertrag und die Funktion, die vom AutomationBot ausgeführt werden, sind ebenfalls im Oasis Service Registry konfigurierbar.
So deaktiviert das Oasis Multisig Wallet zunächst 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 tritt sofort in Kraft. Dann ruft das Multisig Wallet den AutomationBot auf, um einen Befehl auszuführen, der die Maker-Vaults des Exploiter übernehmen kann (verschieben und übertragen). Da der AutomationBot die Vaults des Exploiter verwalten kann, kann die gesamte Operation erfolgreich sein.
Wir sind der Meinung, dass dieser Prozess grundlegend anders ist als der Fall Platypus, bei dem wir eine Schwachstelle im Angreifervertrag gefunden und diese mit Platypus geteilt haben. Platypus hat dann den Angreifervertrag ausgenutzt, 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 grundlegend ändern können, und nutzt die Verwaltungsrolle des AutomationBot aus, um auf die Maker-Vaults im Namen des Exploiter 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 Aktionen durchgeführt hat.
Speziell 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 Beleihungsverhältnis 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 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 initiiert 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 Bestätigungen von Unterzeichnern.
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 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, damit 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 durch die verzögerte Ausführung eingeschränkt ist (da die Änderung an reqDelay noch nicht wirksam geworden 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 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 in der Spur gezeigt, wird die Verzögerung erneut auf Null gesetzt. Dies dient zur Anwendung der Aktion der Deaktivierung der verzögerten Ausführung in Schritt 2.
Schritt 3.2: Erstellung von zwei Verträgen und Aktualisierung des Service Registrys
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
Diese beiden Verträge werden dann in den Oasis Service Registry Vertrag aktualisiert.
Schritt 3.3: Änderung des Automation Executors
Das 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: Anweisung an den AutomationBot, die Vault des Exploiter 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 ist, dass der Bot zuerst DAI aus der Vault zieht (Zeile 268) und dann den konkretisierten Befehlsvertrag aufruft, um ihn auf der Vault auszuführen (angegeben durch cdpId) (Zeilen 274 bis 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 unter Verwendung des SCHLÜSSELS MULTIPLY_PROXY_ACTIONS ab. Beachten Sie, dass die Vertragsadresse, die MULTIPLY_PROXY_ACTIONS entspricht, durch eine neue ersetzt wurde. Somit ist die tatsächliche Ausführung von CloseCommand steuerbar, um beliebige Operationen im neuen Vertrag durchzuführen.
Denken Sie daran, dass isExecutionCorrect auf 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 check viewerContract.getVaultInfo(cdpId) ein beliebiger Wert sein, der die Prüfung in Zeile 24 (CloseCommand.sol) besteht.
Nachdem wir den Code durchlaufen haben, schauen wir uns die Ausführungsspuren an. Aus der Spur können wir sehen, 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 Exploiter) auf 30231 (die neu erstellte) zu verschieben und die neue Vault 30231 dem Oasis Multisig Wallet zu geben. Eine ähnliche Operation wird für die andere Vault des Exploiter (30179) durchgeführt.
Schritt 3.5 Wiederherstellung des Zustands
Wiederherstellung des geänderten Eintrags im Service Registry und erneutes Aktivieren 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 gesteuert. Dann werden die Vaults in diesen Transaktionen an 0x15364305a06ba3ac6ba13dfe97ca0bad639adf41 übergeben [TX1 TX2]. Dann kann diese Adresse die Schulden in der Vault begleichen und die Sicherheiten (Ethereum) abheben. Da die Beleiligungsrate hoch ist (ca. 293% für Vault 30100), können durch Rückzahlung und Abhebung der Sicherheiten etwa 120.000 Ethereum zurückgewonnen werden, wobei die Kosten für die Begleichung von etwa 76 Millionen Schulden aus Vault 30100 anfallen. Leser können das Maker-Protokolldokument für weitere Informationen zu diesen Operationen konsultieren.
Über BlockSec
BlockSec ist ein wegweisendes Blockchain-Sicherheitsunternehmen, das 2021 von einer Gruppe weltweit renommierter Sicherheitsexperten gegründet wurde. Das Unternehmen engagiert sich für die Verbesserung der Sicherheit und Benutzerfreundlichkeit der aufstrebenden Web3-Welt, um deren Massenakzeptanz zu fördern. Zu diesem Zweck bietet BlockSec Dienstleistungen für die Sicherheitsprüfung von Smart Contracts und EVM-Ketten, die Phalcon-Plattform für die Entwicklung sicherer Systeme und die proaktive Abwehr von Bedrohungen, die MetaSleuth-Plattform für die Nachverfolgung und Untersuchung von Geldern sowie die MetaSuites-Erweiterung für Web3-Entwickler, die sich effizient in der Kryptowelt bewegen.
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/
Offizielles Twitter-Konto: https://twitter.com/BlockSecTeam
