Exactly Protocol Periphery-Exploit

Am 18. August 2023 wurde das Optimism-basierte Lending-Protokoll Exactly Protocol um rund 7,3 Millionen $ in ETH exploitet. Der Bug lag im DebtManager-Peripherie-Contract — speziell in der leverage()-Funktion, die sowohl eine Market-Contract-Adresse als auch eine Permit-Signatur als Inputs akzeptierte und keines validierte. 117 Nutzerkonten wurden ihre Einlagen abgezogen. Der TVL des Protokolls fiel von 37 Mio. $ auf 11,74 Mio. $ — ein Rückgang um 70 % — innerhalb von Stunden.

Was geschah

Exactlys Haupt-Lending-Märkte waren rigoros auditiert; die umgebenden Peripherie-Contracts — Utility-Contracts, die Nutzern bei mehrstufigen Operationen wie Leveraged Borrowing halfen — waren ursprünglich nicht im Audit-Scope. Der DebtManager war einer dieser Peripherie-Contracts.

Die leverage()-Funktion auf DebtManager akzeptierte:

• Einen market-Parameter, der angibt, mit welchem Exactly-Markt interagiert werden soll.
• Eine permit-Signatur, die Token-Transfers im Namen des Nutzers autorisiert.

Die Funktion nutzte diese Inputs, um eine Reihe von Operationen auszuführen, die letztlich Wert aus den bestehenden Positionen des Nutzers in legitimen Exactly-Märkten bewegten. Der fatale Fehler: Keiner der Parameter wurde validiert:

• Der market-Parameter wurde unverändert akzeptiert, sodass ein Angreifer die Adresse eines von ihm deployten Fake-Market-Contracts übergeben konnte.
• Das permit wurde durch Standard-ERC-2612-Logik verarbeitet, aber die Funktion verifizierte nicht, dass das Permit für den korrekten Zweck oder vom legitimen Marktteilnehmer signiert worden war.

Der Angreifer:

1. Deployte einen Fake-„Market"-Contract, der das erwartete Interface implementierte, aber intern tat, was der Angreifer wollte.
2. Fälschte ein Permit für die Operation — die Permit-Signatur war technisch gültig für den Funktionsaufruf, aber ihre Semantik entsprach keiner legitimen Exactly-Leverage-Operation.
3. Rief leverage() mit beiden Inputs auf — die Funktion nutzte die Antworten des Fake-Markets, um zu kontrollieren, wie Wert zwischen Exactlys legitimen Contracts bewegt wurde, und routete letztlich Nutzer-Collateral an den Angreifer.

Abgezogen aus 117 Konten für insgesamt rund 7,3 Mio. $.

Folgen

• Exactly pausierte das Protokoll innerhalb von Stunden gemäß seines Notfallverfahren-Runbooks.
• Das Team engagierte ABDK öffentlich erneut, den ursprünglichen Auditor, für eine frische Audit-Runde — diesmal einschließlich Peripherie-Contracts, die vom ursprünglichen Audit-Scope ausgeschlossen worden waren.
• Ein Erstattungsplan wurde gestartet, finanziert aus Protokoll-Umsatz und Team-Reserven.
• Die gestohlenen Gelder wurden über Tornado Cash gewaschen; keine öffentliche Wiederherstellung.

Warum es wichtig ist

Der Exactly-Protocol-Vorfall ist einer der klarsten Fälle dafür, Audit-Scope als eigenständige Sicherheitskontrolle zu betrachten. Die Lending-Märkte waren korrekt auditiert und funktionierten wie vorgesehen. Der Bug lag in den Contracts, die mit den Märkten sprachen — Peripherie-Code, den das Team zur UX-Verbesserung deployt hatte, der aber nicht der gleichen Sicherheits-Rigorosität wie das Kern-Protokoll unterlag.

Die strukturellen Lektionen:

1. Peripherie-Contracts sind Teil der Angriffsfläche des Protokolls, auch wenn sie keine Nutzergelder direkt halten. Wenn ein Peripherie-Contract Nutzergelder via Permits oder Approvals bewegen kann, hat er dieselben Sicherheitsanforderungen wie der Kern.

2. Audit-Scope muss explizit benennen, was nicht abgedeckt ist — und jeder vom Audit ausgeschlossene Contract sollte vom Produktiv-Deployment ausgeschlossen sein, bis er ein eigenes dediziertes Review hat.

3. Permit-Signaturen sind ein mächtiges Primitive, das sorgfältige semantische Validierung erfordert — eine gültige ERC-2612-Permit-Signatur sagt nicht, warum der Signer die Operation autorisiert hat, nur dass er irgendeine Operation signiert hat. Jede Funktion, die Permits konsumiert, muss validieren, dass die Parameter des Permits ihrem beabsichtigten Zweck entsprechen.

Die Reaktion von Exactly Protocol — den ursprünglichen Auditor mit erweitertem Scope erneut zu beauftragen — ist zu einem wiederkehrenden Muster in der Post-Incident-Remediation in DeFi geworden. Die Lektion, bezahlt mit 7,3 Mio. $ der betroffenen Nutzer, ist die richtige, auch wenn die Kosten hoch waren.