#5: Platypus Finance: Überlebt drei Angriffe mit einer glücklichen Fügung

Zusammenfassung

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

• Am 17. Februar 2023 kam es zu einem Hack aufgrund einer fehlerhaften Solvenzprüfung, was zu einem Gesamtverlust von etwa 9,05 Mio. US-Dollar führte. Davon wurden mit Hilfe von BlockSec 2,4 Mio. US-Dollar gerettet. Ungefähr 380.000 Token waren im Aave-Vertrag gefangen und wurden anschließend zurückgegeben.
• Am 12. Juli 2023 wurde es gehackt, wobei aufgrund der Nichtbeachtung der Preisdifferenz zwischen Stablecoins rund 50.000 US-Dollar verloren gingen.
• Am 12. Oktober 2023 litt es unter Preismanipulationsangriffen, wobei rund 2,2 Mio. US-Dollar verloren gingen. Nach Verhandlungen mit dem Exploiter wurden 90 % der gestohlenen Gelder zurückgegeben.

Das Projekt hat Glück, all diese Angriffe überlebt zu haben. Unsere Analyse dieser drei Exploits zeigt, dass die logischen Schwächen durch eine sorgfältige Prüfung oder aktivere Sicherheitsmaßnahmen vermieden werden könnten.

Angriff Eins

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

• Ein Benutzer kann einen Token in einen Pool einzahlen, um ein LP zu werden und einen LP-Token zu erhalten.
• Der LP-Token kann in MasterPlatypus gestaket werden, um Belohnungen zu erhalten. Der LP-Token wird dabei an den MasterPlatypus-Vertrag übertragen.
• Der LP-Token kann als Sicherheit verwendet werden, um andere Vermögenswerte zu leihen und die Effizienz der Vermögenswerte zu verbessern.

Die folgende Abbildung zeigt die Interaktionen.

Schwachstellenanalyse

Die Schwachstelle liegt 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 Benutzer solvent ist, um die Auszahlung zu ermöglichen. Die Logik prüft, ob Benutzer Schulden haben (d. h., ob die Sicherheit zur Begleichung der Schulden verwendet werden kann). Wenn nicht, können die Benutzer die gestakten LP-Token abheben.

Diese Logik ist jedoch fehlerhaft. Dass ein Benutzer solvent ist, bedeutet nur, dass die Sicherheit des Benutzers seine Schulden decken kann. Es wird jedoch NICHT geprüft, ob der Benutzer nach der Notfallabhebung der gestakten Token weiterhin solvent bleibt. Ein Angreifer kann diese Schwäche ausnutzen, indem er Vermögenswerte leiht und dann auch die gestakten LP-Token notfallmäßig abhebt (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 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: Ausführen der emergencyWithdraw-Funktion, um den Angriff zu starten

Der Angreifer erhält den LP-USDC, ohne die USP-Schulden zu bezahlen.

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

Schritt 7: USP verkaufen für Gewinn

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

BlockSecs Rettung

Wir stellten fest, dass der Angreifer die Gewinne im Angriffsvertrag hinterlassen hatte. Außerdem gibt es keine Logik im Angriffsvertrag, um die Vermögenswerte abzuheben. Wir fanden jedoch eine Schwachstelle im Angriffsvertrag, die ausgenutzt werden konnte, um einen Teil der Vermögenswerte aus dem Vertrag zurückzugewinnen.

Insbesondere gibt es eine Zugriffskontrolle für die Flashloan-Callback-Funktion, was bedeutet, dass jeder diese Callback-Funktion aufrufen kann. Dies ist auch die Hauptursache für die Angriffe auf viele MEV-Bots.

Außerdem genehmigt der Angreifervertrag innerhalb der Callback-Funktion den USDC-Token für den Platypus Finance Pool Contract. Und dieser Poolvertrag ist aktualisierbar!

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

• Den Platypus Finance Pool Contract aktualisieren, um eine Logik zur Abhebung der USDC aus dem Vertrag aufzunehmen
• Den Callback des Angreifervertrags aufrufen, um die USDC an den Poolvertrag zu genehmigen
• Der Poolvertrag kann jede Funktion ersetzen (die vom Angreifervertrag ausgeführt wird), um die USDC vom Angreifervertrag zu übertragen (da der Angreifervertrag die USDC an den Poolvertrag genehmigt hat).

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

Andere zwei Angriffe

Für weitere Details zu den beiden anderen Angriffen verweisen wir auf die 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 Marktschwankungen abweicht und zu einer fehlerhaften Auszahlungslogik führt. Der Link zu einer Angriffstransaktion. Es gibt ein paar davon.

• Angriff III: 12. Oktober 2023, aufgrund manipulierter cash und liability, die den Swap-Preis beeinflussten. [Die erste Angriffstransaktion | Die zweite Angriffstransaktion]

Zusammenfassung

Die drei Angriffe nutzten unterschiedliche Schwachstellen im Protokoll aus. Obwohl einige andere Anbieter das Protokoll auditiert haben, fand der Angreifer dennoch die Lücke und nutzte das Protokoll erfolgreich aus. Glücklicherweise wurden einige Vermögenswerte gerettet, aber wir können nicht erwarten, immer Glück zu haben. Mehr Sicherheitsmaßnahmen einschließlich Angriffüberwachung und automatischer Reaktion, sollten übernommen werden, um das Protokoll und die Benutzervermögen zu sichern.

Lesen Sie andere Artikel in dieser Reihe:

• Einführung: Top Zehn „Großartige“ Sicherheitsvorfälle im Jahr 2023
• Nr. 1: Ernte von MEV-Bots durch Ausnutzung von Schwachstellen im Flashbots Relay
• Nr. 2: Euler Finance Vorfall: Der größte Hack des Jahres 2023
• Nr. 3: KyberSwap Vorfall: Meisterhafte Ausnutzung von Rundungsfehlern mit äußerst subtilen Berechnungen
• Nr. 4: Curve Vorfall: Compilerfehler erzeugt fehlerhaften Bytecode aus unbedenklichem Quellcode
• Nr. 6: Hundred Finance Vorfall: Katalysator für die Welle präzisionsbezogener Exploits in anfälligen Forked-Protokollen
• Nr. 7: ParaSpace Vorfall: Ein Wettlauf gegen die Zeit, um den kritischsten Angriff der Branche abzuwehren
• Nr. 8: SushiSwap Vorfall: Ein unbeholfener Rettungsversuch führt zu einer Reihe von Nachahmungsangriffen
• Nr. 9: MEV Bot 0xd61492: Vom Jäger zum Gejagten in einem genialen Exploit
• Nr. 10: ThirdWeb Vorfall: Inkompatibilität zwischen vertrauenswürdigen Modulen legt Schwachstelle offen