Zurück zum Blog

#5: Platypus Finance: Drei Angriffe dank Glück überstanden

Code Auditing
15. Februar 2024
5 Min. Lesezeit

Zusammenfassung

Platypus Finance ist ein AMM-Protokoll auf der Avalanche-Blockchain. Es wurde bereits dreimal angegriffen, wie folgt:

  • Am 17. Februar 2023 erlebte es einen Hack aufgrund einer fehlerhaften Solvenzprüfung, der zu einem Gesamtverlust von etwa 9,05 Mio. USD führte. Davon wurden 2,4 Mio. USD mit Hilfe von BlockSec gerettet. Etwa 380.000 Token steckten im Aave-Vertrag fest und wurden anschließend zurückgegeben.
  • Am 12. Juli 2023 wurde es gehackt, wobei rund 50.000 USD verloren gingen, weil die Preislücke zwischen Stablecoins ignoriert wurde.
  • Am 12. Oktober 2023 erlitt es Angriffe durch Preismanipulation, bei denen rund 2,2 Mio. USD verloren gingen. Nach Verhandlungen mit dem Angreifer wurden 90 % der gestohlenen Gelder zurückgegeben.

Das Projekt hat großes Glück, all diese Angriffe überstanden zu haben. Unsere Analyse dieser drei Exploits zeigt, dass die logischen Schwachstellen hätten vermieden werden können, wenn ein sorgfältiges Audit oder aktivere Sicherheitsmaßnahmen eingesetzt worden wären.

Angriff Eins

Um diesen Sicherheitsvorfall zu verstehen, muss man den Arbeitsablauf mehrerer Smart Contracts verstehen. Der grobe Ablauf ist wie folgt:

  • Ein Nutzer kann einen Token in einen Pool einzahlen, um LP zu werden, und erhält dafür einen LP-Token.
  • Der LP-Token kann in MasterPlatypus gestaked werden, um Belohnungen zu erhalten. Während dieses Prozesses wird der LP-Token an den MasterPlatypus-Vertrag übertragen.
  • Der LP-Token kann als Sicherheit verwendet werden, um andere Vermögenswerte zu leihen und so die Kapitaleffizienz zu verbessern.

Die folgende Abbildung zeigt die Interaktionen.

Schwachstellenanalyse

Die Schwachstelle befindet sich in einer Funktion namens emergencyWithdraw innerhalb des MasterPlatypus-Vertrags. In Notfällen sollte diese Funktion verwendet werden, um die gestakten LP-Token im MasterPlatypus-Vertrag abzuheben. In dieser Funktion prüft der Vertrag, ob der Nutzer Solvent (solvent) ist, um die Abhebung zu erlauben. Die Logik prüft, ob der Nutzer irgendwelche faulen Schulden hat (d. h. ob die Sicherheiten zur Begleichung der Schulden ausreichen). Falls nicht, kann der Nutzer die gestakten LP-Token abheben.

Diese Logik ist jedoch fehlerhaft. Dass der Nutzer Solvent ist, bedeutet nur, dass die Sicherheiten des Nutzers seine Schulden decken können. Es wird jedoch NICHT geprüft, ob der Nutzer auch nach dem notfallmäßigen Abheben der gestakten Token weiterhin solvent bleibt. Ein Angreifer kann diese Schwachstelle ausnutzen, um Vermögenswerte zu leihen und anschließend ebenfalls die gestakten LP-Token notfallmäßig abzuheben (ohne die Schulden zurückzuzahlen). Siehe die detaillierte Analyse im Immunefi-Blog.

Angriffsanalyse

Wir verwenden eine Angriffstransaktion als Beispiel, um den gesamten Angriffsprozess zu zeigen.

Schritt 1: 44 Millionen USDC als Flashloan von AAVE leihen

Schritt 2: 44 Millionen USDC in den Pool einzahlen, um LP-USDC zu erhalten

Schritt 3: LP-USDC in MasterPlatypus einzahlen

Schritt 4: LP-USDC als Sicherheit verwenden, um USP zu leihen

Schritt 5: Die Funktion emergencyWithdraw ausführen, um den Angriff zu starten

Der Angreifer erhält die LP-USDC, ohne die USP-Schulden zurückzuzahlen.

Schritt 6: LP-USDC aus dem Pool abheben, um USDC zu erhalten

Schritt 7: USP für Gewinne verkaufen

Die Gewinne verbleiben jedoch im Angriffsvertrag. Tatsächlich kann der Angreifer eine neue Empfangsadresse für den Swap einrichten, um die Gewinne zu erhalten.

Rettungsaktion von BlockSec

Wir stellten fest, dass der Angreifer die Gewinne im Angriffsvertrag beließ. Außerdem gibt es im Angriffsvertrag keine Logik, um die Vermögenswerte abzuheben. Wir fanden jedoch eine Schwachstelle im Angriffsvertrag, die genutzt werden konnte, um zurückzuhacken und einen Teil der Vermögenswerte im Vertrag abzuheben.

Konkret gibt es eine Zugriffskontrolle der Flashloan-Callback-Funktion, was bedeutet, dass jeder diese Callback-Funktion aufrufen kann. Dies ist auch die Ursache dafür, dass viele MEV-Bots angegriffen werden.

Außerdem genehmigt der Angriffsvertrag innerhalb der Callback-Funktion den USDC-Token für den Platypus-Finance-Pool-Vertrag. Und dieser Pool-Vertrag ist upgradefähig!

Durch die Kombination der beiden vorangegangenen Punkte können wir die USDC im Angriffsvertrag retten, indem wir:

  • Den Platypus-Finance-Pool-Vertrag aktualisieren, um eine Logik zum Abheben der USDC im Vertrag einzubinden
  • Den Callback des Angriffsvertrags aufrufen, um die USDC für den Pool-Vertrag zu genehmigen
  • Der Pool-Vertrag kann jede Funktion (die vom Angriffsvertrag ausgeführt wird) ersetzen, um die USDC vom Angriffsvertrag zu übertragen (da der Angriffsvertrag die USDC für den Pool-Vertrag genehmigt hat).

Hier ist die Transaktion zur Rettung von 2,4 Millionen USDC.

Die beiden anderen Angriffe

Weitere Details zu den anderen beiden Angriffen finden Sie unter den folgenden Links.

Zusammenfassung

Die drei Angriffe nutzten unterschiedliche Schwachstellen im Protokoll aus. Obwohl das Protokoll bereits von anderen Anbietern geprüft wurde, fand der Angreifer dennoch die Sicherheitslücke und konnte das Protokoll erfolgreich ausnutzen. Glücklicherweise konnten einige Vermögenswerte gerettet werden, aber wir können nicht immer auf Glück zählen. Weitere Sicherheitsmaßnahmen, einschließlich Angriffsüberwachung und automatischer Reaktion, sollten eingeführt werden, um das Protokoll und die Vermögenswerte der Nutzer zu schützen.

Lesen Sie weitere Artikel dieser Serie:

Für die neuesten Informationen anmelden
Verluste von rund 5,57 Millionen USD: Exploits bei X100 Freezer und NEM | BlockSec-Wochenrückblick
Security Insights

Verluste von rund 5,57 Millionen USD: Exploits bei X100 Freezer und NEM | BlockSec-Wochenrückblick

Dieser Wochenbericht behandelt zwei Sicherheitsvorfälle auf Ethereum und BNB Chain im Zeitraum 19.10.2026–25.10.2026. Er untersucht eine durch einen Flash Loan finanzierte Übernahme der Governance von X100 Freezer sowie einen Fehler bei der Steuerabrechnung, der einen Liquiditätspool eines NEM-Tokens auf BNB Chain betrifft. Die geschätzten Verluste im Rahmen des Berichts belaufen sich insgesamt auf etwa 5,57 Millionen USD: rund 4,75 Millionen USD aus der exemplarischen X100-Transaktion und rund 820 Tausend USD aus dem Vorfall beim NEM-Pool. Gesondert gemeldete spätere Entnahmen aus X100 sind in der Gesamtsumme nicht enthalten.

Verluste von rund 3,87 Millionen USD: Hacks bei Autheo Network und UNCX | BlockSec Weekly
Security Insights

Verluste von rund 3,87 Millionen USD: Hacks bei Autheo Network und UNCX | BlockSec Weekly

Dieser Wochenbericht behandelt 3 Sicherheitsvorfälle im Zeitraum 12.10.2026–18.10.2026 mit einem geschätzten Gesamtschaden von etwa 3,87 Millionen USD. Bei Autheo Network wurde ein privater Schlüssel kompromittiert; der Schaden betrug rund 1,76 Millionen USD. Qubic Wallet verlor aufgrund einer schwachen Seed-Generierung rund 1,30 Millionen USD. Bei den Smart Token Vesting V2-Verträgen von UNCX Network führte ein Buchführungsfehler auf Ethereum, BNB Chain, Base und Robinhood Chain zu einem Schaden von rund 807 Tausend USD. Die hervorgehobene Analyse zu UNCX erklärt, wie eine fehlerhafte Berechnung der Gesamtanteile Vesting-Tranchen zusammenführte, die mit unterschiedlichen Token-zu-Anteil-Verhältnissen erstellt worden waren, und dadurch überhöhte Entnahmen aus gemeinsamen Pools ermöglichte.

Rund 542.000 $ verloren: MakerDaoBot-Exploit | BlockSec Wochenrückblick
Security Insights

Rund 542.000 $ verloren: MakerDaoBot-Exploit | BlockSec Wochenrückblick

Ethereum, 5.–11.10.2026: 1 Vorfall, ca. 542.000 $ Verlust. Über eine ungeschützte MakerDaoBot-Funktion erhielt ein bösartiger Adapter Zugriff auf Bot-Guthaben, wickelte 4 ETH-A-Auktionen ab und tauschte 200 ETH-A in WETH; 200 ETH gingen an den Angreifer.

Der beste Sicherheitsauditor für Web3

Lassen Sie Design, Code und Geschäftslogik vor dem Launch prüfen. Nach den höchsten Sicherheitsstandards der Branche.

BlockSec-Audit