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.
-
Angriff-II: 11. Juli 2023, Das Protokoll geht davon aus, dass das Verhältnis zwischen USDC und USDT 1:1 beträgt, was von den Marktschwankungen abweicht und zu einer fehlerhaften Abhebungslogik führt. Der Link zu einer Angriffstransaktion. Es gibt mehrere davon.
-
Angriff-III: 12. Oktober 2023, aufgrund der manipulierten Werte
cashundliability, die den Swap-Preis beeinflussten. [Die erste Angriffstransaktion | Die zweite Angriffstransaktion]
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:
- Einleitung: Die zehn "großartigsten" Sicherheitsvorfälle des Jahres 2023
- #1: Ausbeutung von MEV-Bots durch Ausnutzung von Schwachstellen im Flashbots-Relay
- #2: Der Euler-Finance-Vorfall: Der größte Hack des Jahres 2023
- #3: Der KyberSwap-Vorfall: Meisterhafte Ausnutzung von Rundungsfehlern mit äußerst subtilen Berechnungen
- #4: Der Curve-Vorfall: Compiler-Fehler erzeugt fehlerhaften Bytecode aus unschuldigem Quellcode
- #6: Der Hundred-Finance-Vorfall: Katalysator für die Welle von präzisionsbezogenen Exploits in verwundbaren geforkten Protokollen
- #7: Der ParaSpace-Vorfall: Ein Wettlauf gegen die Zeit, um den bisher kritischsten Angriff der Branche zu vereiteln
- #8: Der SushiSwap-Vorfall: Ein missglückter Rettungsversuch führt zu einer Serie von Nachahmerangriffen
- #9: MEV-Bot 0xd61492: Vom Räuber zur Beute in einem raffinierten Exploit
- #10: Der ThirdWeb-Vorfall: Inkompatibilität zwischen vertrauenswürdigen Modulen legt Schwachstelle offen



