Am 5. März 2025 erlitt ein externer Resolver-Vertrag, der in das Fusion V1-Protokoll von 1inch integriert war, einen koordinierten Exploit, der zu Gesamtverlusten von über 5 Millionen US-Dollar führte. Die Grundursache war eine unsichere Rekonstruktion von Calldata im Abwicklungsfluss, bei der eine vom Angreifer gesteuerte Interaktionslänge einen Pointer Underflow während der Suffix-Zusammenfügung auslöste, was die Einschleusung gefälschter Abwicklungsdaten ermöglichte. Der Exploit wurde zusätzlich durch eine fehlplatzierte Vertrauensgrenze ermöglicht: Resolver-Verträge vertrauten implizit allen Calldata, die vom Abwicklungsvertrag weitergeleitet wurden, basierend ausschließlich auf msg.sender, wodurch vom Angreifer gesteuerte Daten trotz bestandener Zugriffskontrollen die Berechtigungen auf Abwicklungsebene erhielten.
Dieser Vorfall sticht als einer der raffiniertesten DeFi-Exploits des Jahres 2025 hervor, nicht wegen eines neuartigen finanziellen Primitivs, sondern wegen der Ausnutzung von Annahmen über niedrigerlevelige ABI- und Speicherlayouts, die die Grenze zwischen Schwachstellen in Smart Contracts und klassischen Techniken zur Ausnutzung von Binärcode verwischen.
Hintergrund
1inch's Fusion V1-Protokoll
1inch ist ein dezentraler Börsenaggregator (DEX), der Liquidität aus mehreren DEXs bezieht, um Benutzern eine optimierte Swap-Ausführung zu bieten. Aufbauend auf der Limit-Order-Infrastruktur des Aggregators führt 1inch Fusion ein niederländisches Auktionsmodell zur Order-Abstimmung ein, das es Benutzern ermöglicht, flexible Ausführungsparameter wie Preisspannen und Swap-Zeitfenster festzulegen.
Im Fusion-Modell werden Benutzerorders nicht direkt vom Protokoll selbst ausgeführt. Stattdessen werden sie von spezialisierten Akteuren, den sogenannten Resolvern, ausgeführt. Resolver können als privilegierte, whitelisted Teilnehmer betrachtet werden: Um sich zu qualifizieren, müssen sie Tokens staken, um ausreichend Unicorn Power zu erhalten, was als wirtschaftlicher Gatekeeping-Mechanismus dient.
Betrieblich betreiben Resolver ihre eigene Off-Chain-Infrastruktur, die mit den Backend-APIs von 1inch interagiert, um Benutzerorders zu entdecken und zu entscheiden, ob und wann sie ausgeführt werden sollen. Sobald ein Resolver entscheidet, eine Order auszuführen, reicht er eine On-Chain-Transaktion über ein dediziertes Konto an den Settlement-Vertrag ein, der den eigentlichen Swap durchführt. (Obwohl Fusion eine wettbewerbsorientierte niederländische Auktion unter Resolvern beinhaltet, ist dieser Mechanismus für das Verständnis des Angriffs nicht wesentlich und wird daher hier weggelassen; der Einfachheit halber gehen wir davon aus, dass der Resolver die Bedingungen der Benutzerorder direkt erfüllen kann.)
Bei der Ausführung eines Swaps kann ein Resolver entweder Liquidität aus externen Märkten beziehen, um eine bessere Ausführung als die Mindestanforderungen des Benutzers zu erzielen, oder den Handel direkt mit eigenen Vermögenswerten abwickeln. Jeder dabei generierte Mehrwert fließt dem Resolver als Gewinn zu. Der in diesem Blog besprochene Angriff zielt auf einen solchen Resolver-Vertrag ab. Speziell ein Vertrag, der für Market-Making auf der Kette verwendet wurde, Vermögenswerte hielt und Genehmigungen an den Settlement-Vertrag erteilt hatte, was letztendlich zum Verlust dieser Vermögenswerte führte.
Orderverarbeitung und Erfüllung
Die Orderausführung in 1inch Fusion wird vom Settlement-Vertrag koordiniert und folgt einem rekursiven Abwicklungsmodell, das von Interaktionsdaten angetrieben wird, anstatt einem linearen Ausführungsfluss.
Der Prozess beginnt, wenn ein Resolver die Funktion settleOrders() aufruft und Calldata übergibt, das die erste Order zusammen mit einer Interaktionsnutzlast kodiert. Anstatt zu versuchen, alle Orders auf einmal abzuwickeln, verarbeitet Settlement sie inkrementell durch wiederholte Aufrufe der internen Funktion _settleOrder().
Für jede Order erstellt die Funktion _settleOrder() eine Kopie der Aufrufe an das Limit Order Protocol (AggregationRouterV5.fillOrderTo()) im Speicher. Während dieser Rekonstruktion fügt Settlement zusätzlichen Resolver-bezogenen Kontext in Form eines dynamischen Suffixes an die Interaktionsdaten an. Dieses Suffix enthält Metadaten zur Ausführung wie die Resolver-Identität und angefallene Gebühren und wird vom Limit Order Protocol als undurchsichtig behandelt. Es wird unverändert weitergeleitet und später von Settlement selbst während des Interaktions-Callbacks dekodiert.
Nachdem die Order gefüllt wurde, kehrt die Kontrolle über die Funktion fillOrderInteraction() zu Settlement zurück. Basierend auf den Interaktionsdaten setzt Settlement die Abwicklung fort, indem es die Funktion _settleOrder() rekursiv mit der verbleibenden Interaktionsnutzlast aufruft, oder wechselt in eine Finalisierungsphase. In der Endphase leitet Settlement die Kontrolle an den Resolver-Vertrag weiter, indem es dessen Funktion resolveOrders() aufruft und den gesammelten Ausführungskontext übergibt.
Dieses Design ermöglicht die sequentielle Abwicklung mehrerer Orders innerhalb einer einzigen Transaktion, während Resolver-spezifische Logik verzögert wird, bis alle Protokoll-Level-Ausführungsschritte abgeschlossen sind.
Schwachstellenanalyse
Die Schwachstelle ergibt sich aus der unsicheren Logik zur Rekonstruktion von Calldata in der internen Funktion _settleOrder(), insbesondere während der Platzierung des dynamischen Suffixes, das an die Interaktionsdaten angehängt wird.
Resolver-Verträge werden durch explizite Zugriffskontrollen geschützt: Sie erfordern, dass Aufrufe vom Settlement-Vertrag stammen und dass die während der Auflösung übergebene Resolver-Adresse mit dem Resolver-Vertrag selbst übereinstimmt. Diese Prüfungen gehen davon aus, dass die über den Abwicklungsprozess übertragene Resolver-Identität korrekt konstruiert ist und intakt bleibt. Diese Annahme hängt von der Korrektheit der Kodierung und des Anhängens von Resolver-bezogenen Daten während der Calldata-Rekonstruktion ab.
Während der Abwicklung rekonstruiert _settleOrder() Calldata im Speicher und hängt ein dynamisches Suffix an, das Resolver-spezifischen Ausführungskontext enthält. Dieses Suffix enthält nicht nur die Resolver-Adresse, sondern auch Order-bezogene Informationen, auf die sich der Resolver verlässt, um die Abwicklung als legitim zu interpretieren. Das Suffix wird an einer Speicherstelle geschrieben, die als ptr + interactionOffset + interactionLength berechnet wird, wobei interactionLength direkt aus Calldata als vollständiger 32-Byte-Wert gelesen wird.
Da diese Offset-Berechnung ohne Grenzenprüfung erfolgt, kann ein Angreifer interactionLength steuern, um einen arithmetischen Überlauf auszulösen und zu manipulieren, wo das Suffix im Speicher geschrieben wird. Dadurch kann der Angreifer das beabsichtigte Suffix durch ein gefälschtes ersetzen und eine beliebige Resolver-Adresse zusammen mit vom Angreifer gesteuerten Order-Daten übermitteln.
Infolgedessen kann der Abwicklungsfluss beim späteren Dekodieren des Suffixes die Ausführung als von einem legitimen Resolver stammend und gültige Order-Daten enthaltend interpretieren, obwohl keine dieser Annahmen zutrifft. Der Angreifer kann effektiv seine eigene Version des Order-Suffixes einschleusen, während er vorgibt, der Resolver zu sein, um ein paar Wei gegen Millionen zu tauschen.
Angriffsanalyse
Nehmen wir die Transaktion ++0x74bc++ als Beispiel. Der Angriff beginnt mit der Erstellung von fünf gültigen Orders, die einen vernachlässigbaren Token-Betrag (ein paar Wei) gegen einen überproportional hohen Ausgabebetrag tauschen. Diese Orders sind syntaktisch gültig und bestehen die Protokoll-Level-Prüfungen.
Der Angreifer polstert dann die Order-Calldata mit einem großen Bereich von Null-Bytes auf. Diese Polsterung dient als kontrollierter Speicherbereich, der später aufgrund der falschen Platzierung des Suffixes überschrieben wird.
Entscheidend ist, dass der Angreifer einen ungültigen interactionLength-Wert für die letzte Order angibt. Der Wert ist als 0xffff…fe00 gewählt, was -512 entspricht, wenn er als vorzeichenbehaftete Ganzzahl interpretiert wird. Da interactionLength als vorzeichenlose 256-Bit-Ganzzahl behandelt und direkt in der Zeigerarithmetik verwendet wird, führt dies zu einem arithmetischen Überlauf bei der Berechnung des Schreiboffsets des Suffixes.
Die unten stehende bösartige Interaktionsstruktur wird als Suffix behandelt:
Zusammenfassung
Dieser Vorfall zielte auf einen externen Resolver-Vertrag ab, der in das veraltete Fusion V1-Protokoll von 1inch integriert war, und führte zu erheblichen Verlusten, was mehrere wichtige Lektionen hervorhebt.
- Unsichere Datenannahmen: Systeme, die sich auf dynamisch konstruierte Eingabedaten verlassen, dürfen keine Längen-, Offset- oder Strukturintegrität annehmen, wenn ein Teil davon vom Benutzer beeinflusst wird.
- Implizite Vertrauenskette: Sicherheitsprüfungen können untergraben werden, wenn Verträge sich darauf verlassen, dass vorgelagerte Komponenten kritische Kontexte erhalten, anstatt sie an jeder Grenze zu validieren.
- Altlasten-Angriffsfläche: Die Unterstützung veralteter Komponenten erhöht die Angriffsfläche und macht Protokolle anfälliger für neuartige Ausnutzungstechniken.
- Domänenübergreifende Ausnutzungsmuster: Schwachstellen, die in der traditionellen Software üblich sind, können auf der Kette wieder auftreten, wenn Logik auf niedriger Ebene für Speicher oder Datenlayouts beteiligt ist.
Referenz
-
https://blog.decurity.io/yul-calldata-corruption-1inch-postmortem-a7ea7a53bfd9
-
https://paragraph.com/@cookies-research/1inch-fusion-cost-efficient-mev-resistant-swaps
-
https://blog-zh.1inch.com/fusion-swap-resolving-onchain-component/#steps-5-6
Über BlockSec
BlockSec ist ein Full-Stack-Anbieter für Blockchain-Sicherheit und Krypto-Compliance. Wir entwickeln Produkte und Dienstleistungen, die Kunden bei der Code-Prüfung (einschließlich Smart Contracts, Blockchain und Wallets), der Echtzeit-Abwehr von Angriffen, der Analyse von Vorfällen, der Rückverfolgung illegaler Gelder und der Einhaltung von AML/CFT-Verpflichtungen über den gesamten Lebenszyklus von Protokollen und Plattformen hinweg unterstützen.
BlockSec hat zahlreiche Blockchain-Sicherheitsarbeiten auf renommierten Konferenzen veröffentlicht, mehrere Zero-Day-Angriffe auf DeFi-Anwendungen gemeldet, mehrere Hacks blockiert, um mehr als 20 Millionen Dollar zu retten, und Milliarden von Kryptowährungen gesichert.
-
Offizielle Website: https://blocksec.com/
-
Offizielles Twitter-Konto: https://twitter.com/BlockSecTeam
