Am 25. Januar 2026 erkannten wir eine Reihe von verdächtigen Transaktionen, die auf von SwapNet und Aperture Finance bereitgestellte Opferverträge auf Ethereum, Arbitrum, Base und BSC abzielten, mit Gesamtschäden von über 17 Millionen US-Dollar. Auf hoher Ebene ist die Grundursache beider Vorfälle einfach und wurde bereits in unseren anfänglichen Warnungen [1, 2] dargelegt: Die Opferverträge weisen aufgrund unzureichender Eingabevalidierung eine beliebige Aufruffunktion auf, die es Angreifern ermöglicht, bestehende Token-Genehmigungen zu missbrauchen und transferFrom aufzurufen, um Vermögenswerte abzuzweigen.
Beide Sätze von Opferverträgen sind jedoch Closed-Source und umfassen nach der Dekompilierung Tausende von Codezeilen mit tief verschachtelter und komplexer Verzweigungslogik, was die Analyse erheblich erschwert. Darüber hinaus konzentrierten sich die nachfolgenden Post-Mortems, die von den betroffenen Projekten veröffentlicht wurden [3, 4], hauptsächlich auf Sanierungs- und Wiederherstellungsmaßnahmen 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 verhinderten.
In diesem Bericht liefern wir eine detailliertere technische Analyse auf Basis dekompilierter Bytecodes und On-Chain-Ausführungsspuren. Obwohl das Fehlen von Quellcode die Sichtbarkeit einschränkt, ist die Analyse auf Bytecode-Ebene ausreichend, um die anfällige Logik zu rekonstruieren, und offenbart mehrere interessante Beobachtungen über das Vertragsdesign, die aus den High-Level-Warnungen nicht sofort ersichtlich sind.
Wir beginnen mit einer eingehenden Untersuchung des SwapNet-Vorfalls, gefolgt von einer detaillierten Analyse des Aperture Finance-Vorfalls.
SwapNet-Vorfall
Hintergrund
SwapNet [5] ist ein DEX-Aggregator, der entwickelt wurde, um optimale Swap-Routen zu finden, indem die Liquidität aus mehreren On-Chain-Quellen, einschließlich AMMs und privaten Market Makern, aggregiert wird. 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 vom Benutzer bereitgestellten Eingaben, die es einem Angreifer ermöglicht, transferFrom()-Aufrufe mit beliebigen Parametern auszulösen. Infolgedessen konnten Vermögenswerte, die zuvor für die Opferverträge genehmigt worden waren (z. B. 0x616000e384Ef1C2B52f5f3A88D57a3B64F23757e), an den Angreifer übertragen werden.
Basierend auf dekompiliertem Bytecode scheint die Funktion 0x87395540() keine ordnungsgemäße Validierung kritischer Eingaben aufzuweisen. Durch den Austausch 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), wodurch der Angreifer alle genehmigten Vermögenswerte abziehen kann.
Angriffsfluss
Gegen SwapNet wurden mehrere Angriffe beobachtet. Hier verwenden wir die Base-Transaktion 0xc15df1d131e98d24aa0f107a67e33e66cf2ea27903338cc437a3665b6404dd57 als Beispiel.
Der Angreifer rief einfach die Funktion 0x87395540() des Opfervertrags mit bösartigen Eingaben auf. Dieser Aufruf besteht aus zwei Hauptschritten.
- Eine interne Schlüsselvariable (z. B.
v51) wurde auf USDC gesetzt, wodurch die beabsichtigte Routing-Logik umgangen wurde.
- Ein Low-Level-Aufruf wurde unter Verwendung von vom Angreifer kontrolliertem Calldata ausgeführt, was zur Ausführung von
USDC.transferFrom()und dem Abzug aller genehmigten USDC führte.
Verlustzusammenfassung, Transaktionen und betroffene Verträge
Der SwapNet-Vorfall verursachte schätzungsweise einen Schaden von ca. 13,41 Millionen US-Dollar über mehrere Ketten hinweg. Die folgenden Tabellen fassen die wichtigsten Exploit-Transaktionen und die beteiligten Opfervertragsadressen zusammen.
Aperture Finance-Vorfall
Hintergrund
Aperture Finance [6] ist ein DeFi-Protokoll, das im Namen der Benutzer konzentrierte Liquiditätspositionen verwaltet, wie z. B. Uniswap V3 LPs. Seine Closed-Source-Verträge (z. B. 0xD83d960deBEC397fB149b51F8F37DD3B5CFA8913) ermöglichen es Benutzern, Uniswap V3-Positionen mit nativen Token zu prägen und zu verwalten.
Beabsichtigter Arbeitsablauf zur Prägung von UniswapV3-Positionen
Bei der Prägung von Uniswap V3-Positionen über die Funktion 0x67b34120() folgt der Vertrag einem beabsichtigten dreistufigen Arbeitsablauf:
-
Native Token verpacken.
-
Native Token über die interne Funktion
0x1d33()tauschen. -
UniswapV3-Positionen prägen.
Das Problem tritt in Schritt 2 auf: 0x1d33() führt einen kundenspezifischen Swap über einen Low-Level-Aufruf durch, bei dem kritische Parameter (z. B. das Aufrufziel und die Calldata) benutzergesteuert und unzureichend validiert zu sein scheinen, was unbeabsichtigte externe Aufrufe ermöglicht. Weitere Details finden Sie in den folgenden Abschnitten.
Ursachenanalyse
Ähnlich wie beim SwapNet-Fall 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 bereitgestellten Calldata aus, ohne strenge Einschränkungen für das Aufrufziel oder den Funktionsselektor durchzusetzen.
Wie die folgende Abbildung zeigt, basieren die Calldata, die zum Auslösen des Low-Level-Aufrufs verwendet werden, ausschließlich auf den Eingaben des Angreifers.
Dies ermöglicht es Angreifern, bösartige Calldata zu erstellen, die zu approvedToken.transferFrom(victim, attacker, amount) im Kontext des Opfervertrags führen. Infolgedessen können nicht nur ERC20-Token, sondern auch genehmigte Uniswap V3-Position-NFTs abgezogen werden.
Angriffsfluss
Gegen Aperture Finance wurden mehrere Angriffe beobachtet. In diesem Abschnitt verwenden wir die Ethereum-Transaktion 0x8f28a7f604f1b3890c2275eec54cd7deb40935183a856074c0a06e4b5f72f25a als repräsentatives Beispiel.
-
Der Angreifer erstellte einen Angriffsvertrag
0x5c92884dFE0795db5ee095E68414d6aaBf398130. -
Der Angriffsvertrag rief die Funktion
0x67b34120()mit bösartigen Eingaben und 100 Wei ETH (d. h.msg.value==100) auf.
a) Die nativen ETH 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 aufgerufen, 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 sie erfolgreich ausgeführt, ohne etwas zu erhalten.
- Zuletzt 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ägungs-Transaktionen stellten wir fest, dass sowohl zugelassene Token für denselben Spender (z. B. OKX DEX: TokenApprove) aufgeführt wurden, aber unterschiedliche Router-Adressen (d. h. DexRouter und WBTC) angegeben wurden. Dies deutet darauf hin, dass der Vertrag möglicherweise eine Validierung des Genehmigungsgebers erzwingt, aber versäumt, das tatsächliche Ausführungsziel zu validieren, was eine kritische Lücke hinterlässt, die durch 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
Verlustzusammenfassung, Transaktionen und betroffene Verträge
Der Aperture Finance-Vorfall führte zu einem geschätzten Gesamtschaden von ca. 3,67 Millionen US-Dollar über mehrere Ketten hinweg. Die folgenden Tabellen fassen die wichtigsten Exploit-Transaktionen und die zugehörigen Opfervertragsadressen zusammen.
Fazit
Obwohl die Vorfälle SwapNet und Aperture Finance unterschiedliche Protokolle und Ketten betrafen, ist das zugrunde liegende Problem in beiden Fällen nicht komplex: benutzergesteuerte Low-Level-Aufrufe in Kombination mit unzureichender Eingabevalidierung in Verträgen, die Token-Genehmigungen halten. Diese Vorfälle erinnern uns 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.
Referenz
[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
[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 Durchführung von Code-Audits (einschließlich Smart Contracts, Blockchain und Wallets), der Echtzeit-Abwehr von Angriffen, der Analyse von Vorfällen, der Rückverfolgung illegaler Gelder und der Erfüllung 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 zur Rettung von mehr als 20 Millionen Dollar blockiert und Kryptowährungen im Wert von Milliarden gesichert.
-
Offizielle Website: https://blocksec.com/
-
Offizieller Twitter-Account: https://twitter.com/BlockSecTeam
