17-Mio-Dollar Closed-Source Smart Contract Exploit: Arbitrary-Call-Schwachstelle in SwapNet und Aperture Finance

Am 25. Januar 2026 haben wir eine Reihe verdächtiger Transaktionen entdeckt, die auf Opferverträge abzielten, die von SwapNet und Aperture Finance auf Ethereum, Arbitrum, Base und BSC eingesetzt wurden, mit Gesamtschäden von über 17 Millionen US-Dollar. Auf hoher Ebene ist die Ursache beider Vorfälle unkompliziert und wurde bereits in unseren ersten Warnungen [1, 2] dargelegt: Die Opferverträge weisen eine beliebige Aufruffunktion aufgrund unzureichender Eingabevalidierung auf, die es Angreifern ermöglicht, bestehende Token-Genehmigungen zu missbrauchen und transferFrom aufzurufen, um Vermögenswerte abzuziehen.

Beide Sätze von Opferverträgen sind jedoch Closed-Source und nach der Dekompilierung expandieren sie zu Tausenden von Codezeilen mit tief verschachtelter und komplexer Verzweigungslogik, was die Analyse erheblich erschwert. Darüber hinaus konzentrierten sich die nachfolgenden Post-Mortems der betroffenen Projekte [3, 4] hauptsächlich auf Abhilfemaßnahmen und Wiederherstellung, mit begrenzter Diskussion der zugrunde liegenden technischen Details. Infolgedessen bleiben mehrere wichtige Fragen unbeantwortet, darunter, wie die anfälligen Aufrufpfade konstruiert wurden und warum bestehende Prüfungen die Ausnutzung nicht verhindert haben.

In diesem Bericht liefern wir eine detailliertere technische Analyse basierend auf dekompilierter Bytecode- und On-Chain-Ausführungsspuren. Obwohl der Mangel an Quellcode die Sichtbarkeit einschränkt, ist die Analyse auf Bytecode-Ebene ausreichend, um die anfällige Logik zu rekonstruieren und offenbart mehrere interessante Beobachtungen zum Vertragsdesign, die aus den High-Level-Warnungen nicht sofort ersichtlich sind.

Wir beginnen mit einem tiefen Einblick in den SwapNet-Vorfall, gefolgt von einer detaillierten Analyse des Aperture Finance-Vorfalls.

SwapNet-Vorfall

Hintergrund

SwapNet [5] ist ein DEX-Aggregator, der darauf ausgelegt ist, optimale Swap-Routen durch Aggregation von Liquidität aus mehreren On-Chain-Quellen, einschließlich AMMs und privater Market Maker, zu finden. Das Protokoll ermöglicht es Benutzern auch, benutzerdefinierte Router oder Pools bei der Ausführung von Swaps anzugeben, was zusätzliche Flexibilität bietet.

Ursachenanalyse

Dieser Vorfall beruht auf unzureichender Validierung von benutzergenerierten Eingaben, die es einem Angreifer ermöglicht, transferFrom()-Aufrufe mit beliebigen Parametern auszulösen. Infolgedessen konnten Vermögenswerte, die zuvor den Opferverträgen (z. B. 0x616000e384Ef1C2B52f5f3A88D57a3B64F23757e) genehmigt wurden, an den Angreifer übertragen werden.

Basierend auf dekompilierter Bytecode scheint die Funktion 0x87395540() eine ordnungsgemäße Validierung kritischer Eingaben zu vermissen. Durch den Ersatz der erwarteten Router- oder Pooladresse durch eine Token-Adresse (z. B. USDC) behandelt der Vertrag den Token fälschlicherweise als gültiges Ausführungsziel. Dies führt zur Ausführung eines Low-Level-Aufrufs mit vom Angreifer kontrollierten Calldata.

Folglich führt der Opfervertrag Aufrufe der Form aus: approvedAsset.transferFrom(victim, attacker, amount), was es dem Angreifer ermöglicht, alle genehmigten Vermögenswerte abzuschöpfen.

Angriffslauf

Mehrere Angriffe wurden gegen SwapNet beobachtet. Hier verwenden wir die Base-Transaktion 0xc15df1d131e98d24aa0f107a67e33e66cf2ea27903338cc437a3665b6404dd57 als Beispiel.

Der Angreifer rief einfach die Funktion 0x87395540() des Opfervertrags mit bösartigen Eingaben auf. Diese Eingabe besteht aus zwei Hauptschritten.

1. Eine wichtige interne Variable (z. B. v51) wurde auf USDC gesetzt, wodurch die beabsichtigte Routing-Logik umgangen wurde.

2. Ein Low-Level-Aufruf wurde unter Verwendung von vom Angreifer kontrollierten Calldata ausgeführt, was zur Ausführung von USDC.transferFrom() und dem Abzug aller genehmigten USDC führte.

Verlustübersicht, Transaktionen und betroffene Verträge

Der SwapNet-Vorfall verursachte einen geschätzten Verlust von ca. 13,41 Mio. USD auf mehreren Chains. Die folgenden Tabellen fassen die wichtigsten Exploit-Transaktionen und die beteiligten Opfervertragadressen zusammen.

Aperture Finance-Vorfall

Hintergrund

Aperture Finance [6] ist ein DeFi-Protokoll, das im Auftrag von Nutzern konzentrierte Liquiditätspositionen, wie z. B. Uniswap V3 LPs, verwaltet. Seine Closed-Source-Verträge (z. B. 0xD83d960deBEC397fB149b51F8F37DD3B5CFA8913) ermöglichen es Nutzern, Uniswap V3-Positionen mit nativen Token zu prägen und zu verwalten.

Beabsichtigter Workflow zum Prägen von UniswapV3-Positionen

Beim Prägen von Uniswap V3-Positionen über die Funktion 0x67b34120() folgt der Vertrag einem beabsichtigten dreistufigen Workflow:

1. Native Token verpacken

2. Native Token über die interne Funktion 0x1d33() tauschen

3. UniswapV3-Positionen prägen

Das Problem tritt in Schritt 2 auf: 0x1d33() führt einen angepassten Tausch über einen Low-Level-Aufruf durch, bei dem kritische Parameter (z. B. das Aufrufziel und die Calldata) benutzerkontrolliert und unzureichend validiert zu sein scheinen, was unbeabsichtigte externe Aufrufe ermöglicht. Weitere Details finden Sie in den folgenden Abschnitten.

Ursachenanalyse

Ähnlich wie im Fall SwapNet ist der Aperture Finance-Vorfall auf unzureichende Eingabevalidierung bei Low-Level-Aufrufen zurückzuführen. Wenn 0x67b34120() aufgerufen wird, führt die interne Funktion 0x1d33() einen Low-Level-Aufruf unter Verwendung von vom Benutzer bereitgestellter Calldata aus, ohne strenge Einschränkungen für das Aufrufziel oder den Funktionsselektor durchzusetzen.

Wie in der folgenden Abbildung gezeigt, basiert die Calldata, die zum Auslösen des Low-Level-Aufrufs verwendet wird, ausschließlich auf den Eingaben des Angreifers.

Dies ermöglicht es Angreifern, bösartige Calldata zu erstellen, die zu Folgendem führt: approvedToken.transferFrom(victim, attacker, amount) im Kontext des Opfervertrags ausgeführt. Infolgedessen können nicht nur ERC20-Token, sondern auch genehmigte Uniswap V3 Position NFTs abgezogen werden.

Angriffslauf

Mehrere Angriffe wurden gegen Aperture Finance beobachtet. In diesem Abschnitt verwenden wir die Ethereum-Transaktion 0x8f28a7f604f1b3890c2275eec54cd7deb40935183a856074c0a06e4b5f72f25a als repräsentatives Beispiel.

1. Der Angreifer erstellte einen Angriffskontrakt 0x5c92884dFE0795db5ee095E68414d6aaBf398130.

2. Der Angriffskontrakt rief die Funktion 0x67b34120() mit bösartigen Eingaben und 100 wei ETHs auf (d. h. msg.value == 100).

   a) Die nativen ETHs wurden über die Funktion WETH.deposit() in WETHs verpackt.

b) Die interne Funktion `0x1d33()` wurde aufgerufen, um einen Low-Level-Aufruf durchzuführen. In diesem Schritt wird ein Aufruf von `WBTC.transferFrom(victim, attacker, amount)` im Kontext des Opfervertrags ausgeführt, wodurch der Angreifer genehmigte Token abziehen kann. Es ist erwähnenswert, dass am Ende der Funktion `0x1d33()` eine Bilanzprüfung bestanden wurde. Insbesondere verglich die Funktion `0x1d33()` die Bilanzänderungen mit einem vom Angreifer spezifizierten Swap-Ausgabewert (d. h. `varg2.word2`). Infolgedessen wurden erfolgreich ausgeführt, ohne etwas zu erhalten.    

3. Schließlich wurde die Funktion `NonfungiblePositionManager.mint()` aufgerufen, um eine Position für den Angreifer unter Verwendung von 100 wei `WETH` zu prägen. 

Interessante Erkenntnisse

Durch den Vergleich von normalen und abnormalen Prägetransaktionen stellten wir fest, dass beide genehmigte Token an denselben Spender (z. B. OKX DEX: TokenApprove) sendeten, aber unterschiedliche Router-Adressen (d. h. DexRouter und WBTC) angaben. Dies deutet darauf hin, dass der Vertrag möglicherweise die Validierung des Genehmigungsnehmers erzwingt, während er versäumt, das tatsächliche Ausführungsziel zu validieren, was eine kritische Lücke hinterlässt, die über beliebige Aufrufe ausgenutzt werden kann.

Normale Transaktion: https://app.blocksec.com/phalcon/explorer/tx/eth/0xc823b703c716fa9078e1d71714b734557bd540ddd1e41590dd73da7c5aba0200

Abnormale Transaktion: https://app.blocksec.com/phalcon/explorer/tx/eth/0x8f28a7f604f1b3890c2275eec54cd7deb40935183a856074c0a06e4b5f72f25a

Verlustübersicht, Transaktionen und betroffene Verträge

Der Aperture Finance-Vorfall führte zu einem geschätzten Gesamtverlust von ca. 3,67 Mio. USD auf mehreren Chains. Die folgenden Tabellen fassen die wichtigsten Exploit-Transaktionen und die zugehörigen Opfervertragadressen zusammen.

Schlussfolgerung

Obwohl die SwapNet- und Aperture Finance-Vorfälle verschiedene Protokolle und Chains betrafen, ist das zugrunde liegende Problem in beiden Fällen nicht komplex: benutzerkontrollierte Low-Level-Aufrufe in Kombination mit unzureichender Eingabevalidierung in Verträgen, die Token-Genehmigungen halten. Diese Vorfälle dienen als Erinnerung daran, dass Flexibilität im Vertragsdesign sorgfältig mit strengen Aufrufbedingungen abgewogen werden muss, insbesondere in Closed-Source-Systemen, in denen die externe Überprüfung begrenzt ist.

Referenzen

[1] https://x.com/Phalcon_xyz/status/2015614087443697738

[2] https://x.com/Phalcon_xyz/status/2015624519898234997

[3] https://meta.matcha.xyz/SwapNet-Incident-Post-Mortem

[4] https://x.com/ApertureFinance/status/2015938720453820752

[5] https://x.com/0xswapnet

[6] https://x.com/ApertureFinance

Ü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 Verfolgung illegaler Gelder und der Einhaltung von AML/CFT-Verpflichtungen über den gesamten Lebenszyklus von Protokollen und Plattformen hinweg unterstützen.

BlockSec hat mehrere 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

• 🔗 BlockSec Audit-Service : Anfrage einreichen

• 🔗 Phalcon Sicherheits-APP: Demo buchen

• 🔗 Phalcon Compliance