Transit Swap Approval-Drain

Am 2. Oktober 2022 wurde der Cross-Chain-DEX-Aggregator Transit Swap für rund 21 Millionen Dollar durch eine fehlende Parametervalidierung in seiner claimTokens-Funktion exploitet. Der Angreifer entzog Nutzer, die unbegrenzte Token-Approvals an Transits Berechtigungsverwaltungsvertrag erteilt hatten. Nach On-Chain-Verhandlung wurden 70 % der Mittel zurückgegeben, was das Ereignis als (sehr teure) Whitehat-Operation klassifizierte.

Was geschah

Um Transit Swap zu nutzen, erteilten Nutzer Token-Approvals an den Berechtigungsverwaltungsvertrag des Protokolls, sodass dieser Tokens im Namen des Nutzers während Swaps ausgeben konnte. Die claimTokens-Funktion des Vertrags war für den tatsächlichen transferFrom-Aufruf gegen das genehmigte Guthaben des Nutzers verantwortlich.

Die Schwachstelle: claimTokens akzeptierte die Token-Vertragsadresse als vom Nutzer gelieferten Parameter und validierte ihn nicht gegen eine Allowlist oder erwartete Quelle. Die Funktion rief gerne transferFrom auf jeder vom Aufrufer angegebenen Token-Adresse auf, gegen jeden Nutzer, der Transit zur Ausgabe dieses Tokens genehmigt hatte.

Der Angriff:

1. Der Angreifer zählte Wallets auf, die unbegrenzte Approvals an den Transit-Swap-Vertrag hielten.
2. Für jedes Opfer rief er claimTokens mit der Adresse des Opfers als Quelle und der Adresse des Angreifers als Ziel auf.
3. Der Vertrag führte den Transfer aus, da die Validierung fehlte.
4. Entzog ~21 Mio. $ über mehrere Tokens (USDT, USDC, BUSD, ETH, BNB usw.).

Nachwirkungen

• Transit Swap pausierte den betroffenen Vertrag und kontaktierte den Angreifer über On-Chain-Nachrichten.
• Nach mehreren Tagen Verhandlung gab der Angreifer rund 70 % der gestohlenen Mittel an eine Wiederherstellungsadresse zurück.
• Das Team verteilte die zurückgewonnenen Mittel pro-rata an betroffene Nutzer.
• Transit erlitt Monate später unter anderen Bedingungen einen zweiten kleineren Exploit.

Warum es zählt

Transit Swap ist Teil einer langen Linie von DEX-Aggregator-Approval-Drain-Bugs — Protokolle, die Nutzer-Approvals halten, müssen rigoros jeden Parameter validieren, der bestimmt, wie diese Approvals ausgegeben werden. Das Muster wiederholt sich bei:

• Furucombo (2021) — delegatecall zu vom Angreifer kontrolliertem Ziel.
• Sushi RouteProcessor2 (2023) — fehlende Access-Prüfung innerhalb des Swaps.
• LI.FI (2024) — Facet-Validierung fehlend in einer frischen Bereitstellung.
• Transit Swap (2022) — claimTokens akzeptiert vom Angreifer gewählte Quelle.

In jedem Fall arbeiten die Verträge des Protokolls technisch wie konzipiert; der Bug ist, dass Nutzer Approvals erteilten in der Erwartung, dass das Protokoll einschränken würde, wie diese Approvals ausgeübt werden, und die Einschränkungslogik des Protokolls eine Lücke hatte. Die defensive Antwort — begrenzte Approvals, EIP-2612 Permits und per-Transaktions-Signatur-Gating — wird Standard, aber hinkt der Rate hinterher, mit der approval-basierte Aggregatoren neuen Code ausliefern.