Rund 542.000 $ verloren: MakerDaoBot-Exploit

In der vergangenen Woche (2026/10/05 - 2026/10/11) beobachteten wir 1 Sicherheitsvorfall mit einem geschätzten Gesamtschaden von etwa 542.000 $.

Datum	Vorfall	Art	Geschätzter Schaden
2026/10/06	MakerDaoBot	Fehlende Zugriffskontrolle	~542.000 $

Highlight der Woche: MakerDaoBot

Am 6. Oktober 2026 nutzte ein Angreifer eine fehlende Zugriffskontrolle in MakerDaoBot aus, einem älteren MakerDAO-Liquidationsbot auf Ethereum, und hob 200 ETH im Wert von etwa 542.000 $ ab. Die anfällige Funktion erlaubte es jedem Aufrufer, einen externen Contract anzugeben, ihm die Kontrolle über die Guthaben des Bots zu gewähren und seinen Code auszuführen. Der Angreifer nutzte diesen Weg, um vier alte Sicherheitenauktionen abzuwickeln und die freigegebenen ETH in einer einzigen Transaktion zu übertragen.

Hintergrund

MakerDaoBot nahm über Flipper, den Sicherheitenauktions-Contract des älteren Liquidationssystems, an den früheren ETH-A-Sicherheitenauktionen von MakerDAO teil. Der Bot verwaltete Vat-Berechtigungen, zahlte ETH und DAI ein und aus und bearbeitete Liquidationsaufgaben.

Vat ist das interne Hauptbuch von MakerDAO. Es erfasst die frei verfügbaren Sicherheiten jeder Adresse nach Sicherheitenart in gem[ilk][address] und ihr internes DAI-Guthaben in dai[address]; es gibt keinen separaten Wallet- oder Konto-Contract. Die Vat-Guthaben von MakerDaoBot sind somit die Hauptbucheinträge, die unter der Adresse des Bot-Contracts selbst erfasst sind.

Ein Aufruf von hope(usr) überträgt diese Guthaben nicht. Er setzt can[msg.sender][usr] auf 1, sodass usr die wish()-Berechtigungsprüfung von Vat besteht und über Guthaben verfügen kann, die unter msg.sender erfasst sind. Funktionen wie flux() und move() verwenden diese Prüfung bei der Übertragung interner Sicherheiten oder von DAI.

mapping(address => mapping (address => uint)) public can;
function hope(address usr) external note { can[msg.sender][usr] = 1; }
function nope(address usr) external note { can[msg.sender][usr] = 0; }
function wish(address bit, address usr) internal view returns (bool) {
    return either(bit == usr, can[bit][usr] == 1);
}

mapping (bytes32 => mapping (address => uint)) public gem;  // [wad]
mapping (address => uint256)                   public dai;  // [rad]

function flux(bytes32 ilk, address src, address dst, uint256 wad) external note {
    require(wish(src, msg.sender), "Vat/not-allowed");
    gem[ilk][src] = sub(gem[ilk][src], wad);
    gem[ilk][dst] = add(gem[ilk][dst], wad);
}
function move(address src, address dst, uint256 rad) external note {
    require(wish(src, msg.sender), "Vat/not-allowed");
    dai[src] = sub(dai[src], rad);
    dai[dst] = add(dai[dst], rad);
}

Analyse der Schwachstelle

Die Ursache war eine fehlende Zugriffskontrolle für die Funktion 0x8804d1de() im MakerDaoBot-Contract unter 0x6839...5546. Die Funktion behandelte varg0 als Adresse eines externen Contracts (im Folgenden als Adapter bezeichnet) und rief für diese Adresse drip(), vat() und später join() auf. Nachdem der Bot über vat() die Vat-Adresse ermittelt hatte, prüfte er, ob der Adapter über seine Vat-Guthaben verfügen durfte. Falls nicht, rief er hope(varg0) auf, um die Berechtigung zu erteilen, und anschließend join() auf demselben Adapter.

Andere privilegierte Einstiegspunkte desselben Contracts verwendeten vor der Ausführung ihrer Operationen eine ds-auth-Prüfung. Der folgende Vergleich zeigt zwei geschützte Einstiegspunkte, die einen bytes4-Selektor und msg.sender an die Autorisierungs-Hilfsfunktion übergeben und bei fehlgeschlagener Prüfung mit ds-auth-unauthorized abbrechen. Für die Funktion 0x8804d1de() gab es keine entsprechende Prüfung des Aufrufers.

Die Funktion 0x8804d1de() erlaubte es somit jedem Aufrufer, die Adresse auszuwählen, die eine Vat-Berechtigung erhielt. Der Bot erteilte dieser Adresse über hope() die Berechtigung und rief unmittelbar danach ihre Funktion join() auf. Die Berechtigung blieb während dieses externen Aufrufs aktiv, sodass der Code unter der ausgewählten Adresse über die internen Sicherheiten- und DAI-Guthaben des Bots verfügen konnte.

Analyse des Angriffs

Die folgende Analyse basiert auf der Transaktion 0xbb6940...f3a88c.

Schritt 1: Die EOA des Angreifers rief einen von ihm bereitgestellten Angriffs-Contract auf. Dieser Contract stellte einen bösartigen Adapter bereit und rief dann die Funktion 0x8804d1de() von MakerDaoBot mit der Adapteradresse auf. Der Bot fand in Vats can-Mapping keine bestehende Berechtigung und rief hope() auf, sodass der Adapter über die unter der Adresse des Bots erfassten Guthaben verfügen konnte.

Schritt 2: MakerDaoBot rief die Funktion join() des Adapters auf. Während die Berechtigung aktiv war, rief der bösartige Code deal(uint256 id) auf dem außer Betrieb genommenen ETH-A-Flipper auf und wickelte die Auktionen 1457, 1458, 1459 und 1460 ab. Anschließend nutzte der Adapter seine Vat-Berechtigung, um 200 Einheiten ETH-A-Sicherheiten von MakerDaoBot an sich selbst zu übertragen, tauschte sie über ETH Join gegen 200 WETH ein und übertrug die Token an den Angriffs-Contract.

Schritt 3: Der Angriffs-Contract wandelte 200 WETH in ETH um und schickte 200 ETH an die EOA des Angreifers. Ihr Wert betrug zu diesem Zeitpunkt etwa 542.000 $.

Fazit

Die Ursache war eine fehlende Zugriffskontrolle in MakerDaoBot, kein Fehler im Vat-Berechtigungssystem von MakerDAO. Eine öffentliche Funktion erlaubte es jedem Aufrufer, einen externen Contract auszuwählen, ihm die Kontrolle über die internen Guthaben des Bots zu gewähren und seinen Code auszuführen. Der Angreifer nutzte diesen Weg, um vier ältere Auktionen abzuwickeln und 200 ETH abzuheben.

Jede Funktion, die die Kontrolle über Vermögenswerte delegiert, muss sowohl einschränken, wer den Vorgang auslösen darf, als auch, welche externen Contracts diese Berechtigung erhalten dürfen. Für sensible Integrationsabläufe sollten dieselben Autorisierungskontrollen gelten wie für andere privilegierte Funktionen; zudem sollten sie nur ausdrücklich zugelassene Contracts akzeptieren.

Über BlockSec

BlockSec ist ein Full-Stack-Anbieter für Blockchain-Sicherheit und Krypto-Compliance. Wir entwickeln Produkte und Dienstleistungen, mit denen Kunden während des gesamten Lebenszyklus von Protokollen und Plattformen Code-Audits durchführen (einschließlich Smart Contracts, Blockchains und Wallets), Angriffe in Echtzeit abwehren, Vorfälle analysieren, illegale Geldflüsse nachverfolgen und AML/CFT-Pflichten erfüllen können.

BlockSec hat mehrere wissenschaftliche Arbeiten zur Blockchain-Sicherheit auf renommierten Konferenzen veröffentlicht, mehrere Zero-Day-Angriffe auf DeFi-Anwendungen gemeldet, mehrere Hacks abgewehrt und dadurch mehr als 20 Millionen Dollar gerettet sowie Kryptowährungen im Wert von Milliarden Dollar abgesichert.