Wöchentliche Web3-Sicherheitsvorfälle | 25. Jan. – 1. Feb. 2026

Im vergangenen Zeitraum (25. Januar – 1. Februar 2026) hat BlockSec sechs Angriffsvorfälle erkannt und analysiert, mit geschätzten Gesamtschäden von rund 18,05 Mio. USD. Die folgende Tabelle fasst diese Vorfälle zusammen, und detaillierte Analysen für jeden Fall werden in den folgenden Unterabschnitten aufgeführt.

1. SwapNet-Vorfall

Kurze Zusammenfassung

Am 25. Januar 2026 wurde das SwapNet-Protokoll auf Base, BSC und Arbitrum ausgenutzt, was zu Verlusten von rund 13,41 Millionen USD führte. Der Vorfall ergab sich aus der unzureichenden Validierung von Benutzereingaben, die es einem Angreifer ermöglichte, Aufrufe zu erstellen, die transferFrom() mit vom Angreifer kontrollierten Parametern aufriefen. Durch den Missbrauch bestehender Token-Genehmigungen führte der Angreifer effektiv Überweisungen in Form von token.transferFrom(victim, attacker, amount) aus, wodurch er die genehmigten Vermögenswerte der Opfer abziehen konnte.

Hintergrund

Das SwapNet-Protokoll ist ein DEX-Aggregator, der darauf ausgelegt ist, optimale Swap-Routen zu finden, indem er Liquidität aus mehreren On-Chain-Quellen aggregiert, darunter AMMs und private Market Maker. Das Protokoll erlaubt es Benutzern auch, beim Ausführen von Swaps benutzerdefinierte Router oder Pools anzugeben, was zusätzliche Flexibilität bietet.

Schwachstellenanalyse

Dieser Vorfall ergibt sich aus der unzureichenden Validierung von Benutzereingaben, die es einem Angreifer ermöglicht, transferFrom()-Aufrufe mit beliebigen Parametern auszulösen. Infolgedessen konnten Vermögenswerte, die zuvor den Opferverträgen genehmigt worden waren (z. B. 0x616000e384Ef1C2B52f5f3A88D57a3B64F23757e), auf 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 Tokenadresse (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. Infolgedessen führt der Opfervertrag Aufrufe der Form aus: approvedAsset.transferFrom(victim, attacker, amount), wodurch der Angreifer alle genehmigten Vermögenswerte abziehen kann.

Angriffs-Analyse

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. Dieser Aufruf besteht aus zwei Hauptschritten.

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

2. Ein Low-Level-Aufruf wurde mit vom Angreifer kontrollierten Calldata ausgeführt, was zur Invokation von USDC.transferFrom() führte und alle genehmigten USDC abgezogen wurden.

Fazit

Der Vorfall wird durch unzureichende Validierung von Benutzereingaben verursacht. Das Hinzufügen ordnungsgemäßer Eingabeprüfungen zur Funktion würde helfen, dieses Problem zu mildern.

2. Aperture Finance-Vorfall

Kurze Zusammenfassung

Am 25. Januar 2026 wurde das Aperture-Protokoll auf Ethereum, Base und Arbitrum ausgenutzt, was zu Verlusten von rund 3,67 Millionen USD führte. Die Hauptursache war die unzureichende Validierung von Benutzereingaben, die es einem Angreifer ermöglichte, transferFrom()-Aufrufe mit beliebigen Parametern über die interne Funktion 0x1d33() auszulösen. Infolgedessen konnte der Angreifer Aufrufe wie approvedToken.transferFrom(victim, attacker, amount) ausführen, wodurch er alle genehmigten Vermögenswerte abziehen konnte.

Hintergrund

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

Beabsichtigter Arbeitsablauf für die Prägung von Uniswap V3-Positionen

Bei der Prägung von Uniswap V3-Positionen über die Funktion 0x67b34120() folgt der Vertrag einem beabsichtigten dreistufigen Arbeitsablauf:

1. Native Tokens wrappen

2. Gewrappte Tokens über die interne Funktion 0x1d33() tauschen

3. UniswapV3-Positionen prägen

Das Problem tritt in Schritt 2 auf: Die interne Funktion 0x1d33() führt einen angepassten Tausch über einen Low-Level-Aufruf aus, 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 sind in den folgenden Abschnitten aufgeführt.

Schwachstellenanalyse

Der Vorfall wird durch unzureichende Eingabevalidierung bei Low-Level-Aufrufen verursacht. Wenn die Funktion 0x67b34120() aufgerufen wird, führt die interne Funktion 0x1d33() einen Low-Level-Aufruf mit vom Benutzer bereitgestellter Calldata aus, ohne strenge Beschränkungen für das Aufrufziel oder den Funktionsselektor durchzusetzen.

Wie in der folgenden Abbildung gezeigt, basieren die Calldata, die zum Auslösen des Low-Level-Aufrufs verwendet werden, vollständig auf den Eingaben des Angreifers.

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

Angriffs-Analyse

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 Angriffsvertrag 0x5c92884dFE0795db5ee095E68414d6aaBf398130.

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

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

• 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 Tokens abziehen kann. Es ist erwähnenswert, dass am Ende der Funktion 0x1d33() eine Bilanzprüfung bestanden wurde. Insbesondere verglich die Funktion 0x1d33() die Saldoänderungen mit einem vom Angreifer spezifizierten Swap-Ausgabewert (d. h. varg2.word2). Infolgedessen wurden erfolgreich ausgeführt, indem nichts empfangen wurde.

• c. 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 normaler und abnormaler Prägetransaktionen stellten wir fest, dass beide Transaktionen Tokens an denselben Spender (z. B. OKX DEX: TokenApprove) genehmigten, aber unterschiedliche Router-Adressen (d. h. DexRouter und WBTC) angaben. Dies deutet darauf hin, dass der Vertrag möglicherweise eine Validierung des Approval-Spenders durchsetzt, aber versäumt, das tatsächliche Ausführungsziel zu validieren, was eine kritische Lücke hinterlässt, die über willkürliche Aufrufe ausgenutzt werden kann.

Normale Transaktion: tx link1

Abnormale Transaktion: tx link2

Fazit

Der Vorfall wird durch unzureichende Validierung von Benutzereingaben verursacht. Das Hinzufügen ordnungsgemäßer Eingabevalidierungen würde helfen, dieses Problem zu mildern.

3. PGNLZ-Vorfall

Kurze Zusammenfassung

Am 27. Januar 2026 wurde der PancakeSwap V2 USDT–PGNLZ-Pool auf BNB Smart Chain ausgenutzt, was zu Verlusten von rund 100.000 USD führte. Die Hauptursache war ein fehlerhafter Burn-Mechanismus im PGNLZ-Token, der es dem Angreifer ermöglichte, PGNLZ direkt aus dem Pool-Guthaben zu verbrennen. Dies reduzierte künstlich die PGNLZ-Reserven des Pools, schuf eine starke Ungleichgewicht der Reserven und verzerrte den On-Chain-Preis. Der Angreifer nutzte dann den manipulierten Preis, um Swaps auszuführen, die USDT aus dem Pool zogen.

Hintergrund

Der PGNLZ-Token führt einen Burn-Mechanismus ein, der auf einen PancakeSwap V2-Pool abzielt. Der Burn-Mechanismus kann unter bestimmten Bedingungen ausgelöst werden. Insbesondere prüft der Token für jeden Kauf im Pool, ob das USDT-Guthaben des Pools einen vordefinierten Schwellenwert erreicht hat. Sobald der Schwellenwert erreicht ist, verbrennt er eine bestimmte Menge PGNLZ aus dem Pool und setzt tradingEnabled = true, wodurch reguläre Benutzer danach mit dem Pool interagieren können. Wenn der Handelsmodus aktiviert ist und ein Benutzer PGNLZ im Pool verkauft, verbrennt der Token zuerst eine Menge von PGNLZ, die vom Pool gehalten wird, basierend auf dem PGNLZ-Verkaufsbetrag des vorherigen Benutzers.

Schwachstellenanalyse

Das Kernproblem war der fehlerhafte Burn-Mechanismus des Tokens PGNLZ, der anfällig für einen Preismanipulationsangriff ist. Insbesondere darf ein Angreifer die Handelsmodusbeschränkung umgehen, um die Poolreserven zu manipulieren (d. h. PGNLZ zu kaufen), indem er den Empfänger als isExcludedFromFee-Adresse (d. h. 0xdEaD) festlegt. Dann nutzt der Angreifer den Burn-Mechanismus (d. h. über die Funktion _executeBurnFromLP()), um PGNLZ direkt aus dem Pool zu verbrennen und die Poolreserven weiter zu manipulieren. Infolgedessen kann der Angreifer Gewinne erzielen, indem er einen umgekehrten Swap (d. h. PGNLZ verkaufen) im manipulierten Pool durchführt.

Angriffs-Analyse

Die folgende Analyse basiert auf der Transaktion: 0xc7270212846136f3d103d1802a30cdaa6f8f280c4bce02240e99806101e08121

1. Der Angreifer lieh sich über einen Flash-Loan in Moolah 1.059e18 BTCB und lieh sich durch die Bereitstellung von 1.059e18 BTCB in Venus 30.000.000e18 USDT.

2. Der Angreifer tauschte 23.337.952e18 USDT gegen 978.266e18 PGNLZ im PancakeSwap V2-Pool, als der Handelsmodus deaktiviert war. Der Angreifer ermöglichte den Tausch, indem er den Empfänger auf 0xdEaD setzte, was die entsprechenden Validierungen umging.

3. Der Angreifer tauschte zuvor besessene 17e18 PGNLZ gegen USDT im PancakeSwap V2-Pool. Während dieses Tauschs wurde die Funktion _executeBurnFromLP() ausgelöst, wodurch 4.240e18 PGNLZ aus dem Pool verbrannt wurden (d. h. basierend auf dem vorherigen PGNLZ-Verkaufsbetrag). Dieser Verbrennungsprozess hinterließ die Poolreserve mit nur 0.00000001e18 PGNLZ, was die PGNLZ-Reserve des Pools weiter manipulierte. Mit der erschöpften PGNLZ-Reserve konnte der Angreifer 23.438.853e18 USDT aus dem Pool mit nur 17e18 PGNLZ abziehen.

4. Der Angreifer zahlte die Position in Venus zurück und erzielte letztendlich einen Gewinn von 100.901e18 USDT.

Fazit

Die Hauptursache dieses Vorfalls liegt im fehlerhaften Burn-Mechanismus von PGNLZ, der es Angreifern ermöglichte, USDT aus dem Pool abzuziehen, indem sie einen Preismanipulationsangriff durchführten. Infolgedessen verursachte der Vorfall Gesamtschäden von rund 100.000 USD. Um solche Probleme zu mildern, muss das Projekt ordnungsgemäße Zugriffskontrollen im System implementieren und umfassende Tests seines Burn-Mechanismus durchführen, um potenzielle Preismanipulationsangriffe zu vermeiden.

4. XPlayer-Vorfall

Kurze Zusammenfassung

Am 28. Januar 2026 wurde der PancakeSwap V2 XPL/USDT-Pool auf BNB Smart Chain ausgenutzt, was zu Verlusten von rund 717.000 USD führte. Der Vorfall wurde durch einen fehlerhaften Burn-Mechanismus im XPL-Token verursacht, der es einem Angreifer ermöglichte, XPL direkt aus dem Pool-Guthaben zu verbrennen. Durch die künstliche Reduzierung der XPL-Reserven des Pools schuf der Angreifer eine starke Ungleichgewicht der Reserven und verzerrte den Swap-Preis. Anschließend nutzte er die manipulierte Preisgestaltung aus, um USDT aus dem Pool zu ziehen.

Hintergrund

Der Token XPL führt einen Burn-Mechanismus ein, der XPL-Tokens aus dem entsprechenden Pool verbrennt und dann die Funktion sync() aufruft, um die Poolreserven zu aktualisieren. Insbesondere im Vertrag NodeDistributePlus kann die Funktion DynamicBurnPool() aufgerufen werden, um eine tägliche Burn-Aufgabe innerhalb eines Ausführungsfensters durchzuführen. Der zu verbrennende Betrag darf die verbleibende tägliche Burn-Obergrenze nicht überschreiten.

Schwachstellenanalyse

Die Hauptursache dieses Vorfalls liegt im fehlerhaften Burn-Mechanismus des Vertrags XPL. Insbesondere erlaubt die Funktion DynamicBurnPool() im Vertrag XPL bestimmten privilegierten Adressen, XPL direkt aus dem Liquiditätspaar zu verbrennen.

Eine dieser privilegierten Adressen ist der Vertrag NodeDistributePlus (d. h. nodeShareAddress), der einen täglichen Burn-Zeitplan implementiert. Nachdem ein privilegierter Account das tägliche Burn-Ziel festgelegt hat, kann jeder Aufrufer NodeDistributePlus.DynamicBurnPool() innerhalb eines 2-Tages-Fensters aufrufen, bis die tägliche Burn-Obergrenze erreicht ist.

Infolgedessen ermöglicht dieses Design jedem, XPL aus dem entsprechenden Pool zu verbrennen und eine Reservenaktualisierung zu erzwingen. Ein Angreifer kann dieses Design nutzen, um die Poolreserven zu manipulieren und einen umgekehrten Swap auszuführen, um USDT im Pool abzuziehen.

Angriffs-Analyse

Die folgende Analyse basiert auf der Transaktion: 0x9779341b2b80ba679c83423c93ecfc2ebcec82f9f94c02624f83d8a647ee2e49

1. Der Angreifer lieh sich über Flash-Loans rund 239.523.169e18 USDT.

2. Der Angreifer tauschte 100e18 USDT gegen 69e18 XPL. Dieser Schritt synchronisierte die Poolreserven mit den aktuellen Guthaben.

3. Der Angreifer tauschte 217.118.801e18 USDT gegen rund 691.022e18 XPL. Dieser Schritt wurde sorgfältig bemessen, um den Poolzustand für die anschließende Reservenmanipulation einzurichten.

4. Der Angreifer rief die Funktion DynamicBurnPool() auf, um 3.078e18 XPL aus dem Pool zu verbrennen. Dieser Verbrennungsprozess manipulierte die XPL-Reserve des Pools weiter auf einen extrem kleinen Wert (d. h. 1 Wei).

5. Der Angreifer tauschte 69e18 XPL gegen 218.083.490e18 USDT mit den manipulierten Reserven.

6. Der Angreifer zahlte den Flash-Loan zurück und erzielte einen Gewinn von 718.844e18 USDT.

Fazit

Dieses Vorfall wird durch einen fehlerhaften Burn-Mechanismus verursacht, der es jedem erlaubt, XPL direkt aus dem Pool zu verbrennen, um seine Reserven zu manipulieren. Infolgedessen ermöglicht dieses fehlerhafte Design Angreifern, einen Preismanipulationsangriff durchzuführen, um wertvolle Vermögenswerte im Pool abzuziehen. Um ähnliche Probleme zu mildern, sollten Projekte das willkürliche Verbrennen von Vermögenswerten aus dem Pool verhindern.

5. Holdstation-Vorfall

Kurze Zusammenfassung

Am 28. Januar 2026 meldete Holdstation eine Kompromittierung, die eine Übernahme eines von den Projektkontrollierten Wallets beinhaltete, mit geschätzten Gesamtschäden von rund 100.000 USD. Der Angreifer zog mehrere Vermögenswerte im Wert von rund 66.000 USD ab, darunter WLD, USD1, BNB und BERA, auf World Chain, BSC, Berachain und zkSync, konsolidierte dann die Erlöse auf Ethereum zu etwa 22,41 ETH, bevor sie bei etwa 0,755 BTC nach Bitcoin überbrückt wurden. Der Vorfall wurde auf die Kompromittierung des Geräts eines Teammitglieds zurückgeführt, angeblich durch eine bösartige IDE oder Browser-Erweiterung, die die Übernahme des Wallets ermöglichte.

Schwachstellenanalyse

Der Einbruch stammte von einer bösartigen Programmier- oder Browsererweiterung, die von einem Kernentwickler installiert wurde und einen operativen Fehler auf menschlicher Ebene darstellt. Insbesondere installierte der Entwickler eine bösartige und unzuverlässige IDE/Browsererweiterung, was zu einer Kompromittierung des Kontos und finanziellen Verlusten führte.

Angriffs-Analyse

Die zugehörigen Adressen und Bridging-Transaktionen sind unten aufgeführt:

Angreiferadressen

• 0x54e127b8dbf3bebf64bb1d62a195a6f60113130d
• 0x9d3a398cc667b97841a2a92ba808ee8dd368a1f2
• bc1qykmc6mllm3s4zpldww764v6vcgtqwshyw02k9c

Opferadressen

• (World Chain) 0xa92e09e0a52b7EdEaD75d3125e21bDFB9752C69e
• (World Chain) 0xD768da05e0E6771Ea81b441026CE9355421eF7c9
• (World Chain) 0xA581ED1dEB42E8496E5275468C79D250b91d6a75
• (World Chain) 0x9BD647B2C8Fed689ADd2e7AA8b428d3eD12f75cb
• (BSC) 0x2Edf158DDCe35733d6f7D9D7227610ca0531f0AD
• (BSC) 0xA581ED1dEB42E8496E5275468C79D250b91d6a75
• (Bera Chain) 0xA581ED1dEB42E8496E5275468C79D250b91d6a75
• (Bera Chain) 0x628cEf732301aDF6d62bB2bcDFeBB291750C4D9a
• (zkSync) 0xA581ED1dEB42E8496E5275468C79D250b91d6a75
• (zkSync) 0x8C826F795466E39acbfF1BB4eEeB759609377ba1
• (zkSync) 0x4Cf7baB01b8D3572b3dC08642ebbE2AD1aCF3B99
• (zkSync) 0x2Edf158DDCe35733d6f7D9D7227610ca0531f0AD
• (zkSync) 0x2D2D047c50d7828Aedb6A151bA1717766606Bf33

Bridging-Transaktionen

• World Chain → Ethereum

  • Betrag: 114.308 WLD → 15,317 ETH
  • Sender: 0x54e127b8dbf3bebf64bb1d62a195a6f60113130d
  • Empfänger: 0x54e127b8DBF3BEBf64bB1d62A195A6f60113130d https://relay.link/transaction/0x3c9ca5e83151a4ee146a3a5bb0eacc5614ca7b746b39672b36ac665c5f1ac216

• BSC → Ethereum

  • Betrag: 10,09 BNB → 2,992 ETH
  • Sender: 0x54e127b8dbf3bebf64bb1d62a195a6f60113130d
  • Empfänger: 0x54e127b8DBF3BEBf64bB1d62A195A6f60113130d https://relay.link/transaction/0x60534c760f5233b02630e7ebda98511807421d6a475f0de12e502b2c1c85f67a

• BSC → Ethereum

  • Betrag: 6.101,6 USD1 → 2,027 ETH
  • Sender: 0x54e127b8dbf3bebf64bb1d62a195a6f60113130d
  • Empfänger: 0x54e127b8DBF3BEBf64bB1d62A195A6f60113130d https://relay.link/transaction/0xdddc9df8398727e7ccab44a9d904cfb60bac55ed8cc5c79fdbfc0523e3d84440

• Berachain → Ethereum

  • Betrag: 7.185 BERA → 1,45 ETH
  • Sender: 0x54e127b8dbf3bebf64bb1d62a195a6f60113130d
  • Empfänger: 0x54e127b8dbf3bebf64bb1d62a195a6f60113130d https://www.gas.zip/scan/tx/0x80aea4b294aef92a5eb45d257a5b1f1125d2d74c8373d0b5ba9fc9b069522bdd

• Ethereum → Ethereum

  • Betrag: 22,41 ETH → 22,41 ETH
  • Sender: 0x54e127b8dbf3bebf64bb1d62a195a6f60113130d
  • Empfänger: 0x9D3A398cC667B97841a2A92ba808ee8dD368a1f2 https://app.blocksec.com/phalcon/explorer/tx/eth/0xf4ddf8f50a09e845f273e0a6368cece215f565233f5034a4a6c63ca038959c3c https://app.blocksec.com/phalcon/explorer/tx/eth/0x5d45d28236a0d76a69dd27e78b05f6baf6378e674734a136b6141dbf80687480

• Ethereum → Bitcoin

  • Betrag: 22,41 ETH → 0,755 BTC
  • Sender: 0x9d3a398cc667b97841a2a92ba808ee8dd368a1f2
  • Empfänger: bc1qykmc6mllm3s4zpldww764v6vcgtqwshyw02k9c https://relay.link/transaction/0xafd628dd1e0d508c40d3e3c2895f39902d14d42f9760b25beacdcc25c3419143

Fazit

Die Hauptursache dieses Vorfalls ist eine Schlüsselkompromittierung. Admin-Schlüssel, insbesondere solche, die mit Schlüsselrollen (z. B. Owner) in Kernverträgen verbunden sind, sollten sorgfältig verwaltet werden. Es wird empfohlen, Multisig-Wallets zu verwenden, um Single Points of Failure zu vermeiden und die systemische Robustheit zu verbessern.

6. Revert Finance-Vorfall

Kurze Zusammenfassung

Am 30. Januar 2026 wurde Revert Finance auf Base ausgenutzt, was zu Verlusten von rund 50.000 USD führte. Die Hauptursache war ein Fehler in der Geschäftslogik des GaugeManager-Vertrags, der es einem Angreifer ermöglichte, Sicherheiten abzuziehen, ohne die entsprechenden Schulden zurückzuzahlen. Durch den Missbrauch von executeV3UtilsWithOptionalCompound() umging der Angreifer den beabsichtigten Schuldenrückzahlungsfluss und zog Gelder ab.

Hintergrund

Revert Finance ist eine umfassende Tool-Plattform, die für Automated Market Maker (AMM) Liquiditätsanbieter (LPs) entwickelt wurde. Sie bietet hauptsächlich Analyse-, Management-, Automatisierungs- und Kreditfunktionen, um LPs bei der Verbesserung der Kapitaleffizienz und Risikokontrolle zu unterstützen.

Im Protokoll können Benutzer ihre Uniswap v3-Positionen als Sicherheit hinterlegen, um Vermögenswerte aus den Kreditpools von Revert Finance zu leihen. Darüber hinaus erlaubt das Protokoll Benutzern, ihre als Sicherheit dienenden Positionen zu staken, um über die Funktion stakePosition() zusätzliche Belohnungen zu verdienen.

Schwachstellenanalyse

Die Hauptursache des Vorfalls war das Fehlen einer Solvenzprüfung beim Entstakeen von Positionen, die als Sicherheit dienen. Insbesondere erlaubt die Funktion executeV3UtilsWithOptionalCompound() Benutzern, eine Position zu entstakeen, indem sie eine entsprechende Anweisung angeben (d. h. whatToDo= 1). Diese Funktion verfügt jedoch beim Entstakeen von besicherten Positionen über keine Solvenzprüfung. Infolgedessen kann ein Angreifer eine besicherte Position einlösen, ohne die ausstehenden Schulden zurückzuzahlen.

Angriffs-Analyse

Die folgende Analyse basiert auf der Transaktion: 0x10429eaeb479f9149854e4aeb978a35ac02d9688f6e22371712b3878c63a64ab

1. Der Angreifer lieh sich 10e8 cbBTC und 10.000.000e6 USDC über einen Flash-Loan, um eine Position (d. h. NFT) zu prägen.

2. Der Angreifer verpfändete die NFT als Sicherheit und lieh sich 49.000e6 USDC.

3. Der Angreifer stakte die besicherte NFT über die Funktion stakePosition().

4. Der Angreifer unstakte sofort die besicherte NFT über die Funktion executeV3UtilsWithOptionalCompound(). Insbesondere wurde die besicherte Position verbrannt und die entsprechenden zugrunde liegenden Vermögenswerte wurden vom Angreifer eingesammelt. Aufgrund des Fehlens von Solvenzprüfungen im Unstaking-Prozess wurde die besicherte Position verbrannt, ohne ihre entsprechenden Schulden zu begleichen.

5. Der Angreifer zahlte den Flash-Loan zurück und erzielte einen Gewinn von 49.000e6 USDC.

Fazit

Die Hauptursache des Vorfalls ist das Fehlen einer Solvenzprüfung beim Entstakeen von besicherten Positionen. Dieser Vorfall unterstreicht die Bedeutung von Solvenzprüfungen in kreditähnlichen Protokollen. Die Implementierung robuster Solvenzmaßnahmen für jede Nutzung der Position ist unerlässlich, um Stabilität und Zuverlässigkeit zu gewährleisten.

Referenzen

[1] SwapNet & Aperture https://blocksec.com/blog/17m-closed-source-smart-contract-exploit-arbitrary-call-swapnet-aperture

[2] PGNLZ: https://x.com/Phalcon_xyz/status/2016154398817505595

[3] XPlayer: X Player Official https://x.com/XPlayer_Media/status/2016700861578403910

[4] XPlayer: X Blocksec Phalcon https://x.com/Phalcon_xyz/status/2016521384609067103

[5] Holdstation: https://x.com/Phalcon_xyz/status/2016823122373296583

[6] Revert Finance: https://paragraph.com/@revertfinance/post%E2%80%91mortem-aerodrome-lend-vault-incident-on-base?referrer=0x8cadb20A4811f363Dadb863A190708bEd26245F8