Zurück zum Blog

Analyse des Popsicle Finance Sicherheitsvorfalls

Code Auditing
4. August 2021
4 Min. Lesezeit

Am 4. August 2021 erlitt Popsicle Finance einen riesigen finanziellen Verlust (über 20 Mio. USD) durch einen Angriff [1]. Nach manueller Analyse bestätigen wir, dass es sich um einen double-claiming-Angriff handelt, d. h. eine Lücke im Belohnungssystem ermöglichte es dem Angreifer, Belohnungen wiederholt einzufordern. Im Folgenden werden wir eine Angriffstransaktion verwenden, um den Angriffsprozess und die Grundursache der Schwachstelle zu veranschaulichen.

Hintergrund

Popsicle Finance ist eine Yield-Optimierungsplattform, die mehrere Vaults für verschiedene Ketten (z. B. Ethereum und BSC) unterstützt.

Insbesondere ruft ein Benutzer zuerst die Funktion deposit auf, um Liquidität bereitzustellen, und erhält Popsicle LP-Token (kurz PLP). Danach verwaltet Popsicle Finance die Liquidität (interagiert mit Plattformen wie Uniswap) für den Benutzer, um Gewinne zu erzielen. Der Benutzer kann die Funktion withdraw aufrufen, um die Liquidität von Popsicle Finance zurückzuholen, wobei die Menge auf Basis der PLP-Token berechnet wird. Die Anreizbelohnung stammt aus der Liquidität, die im Laufe der Zeit angesammelt wird. Der Benutzer kann die Funktion collectFees aufrufen, um die Belohnungen einzufordern, was der Schlüssel zu diesem Angriff ist.

Schwachstellenanalyse

In der Funktion collectFees werden token0Reward und token1Reward (Belohnungen des entsprechenden LP-Token-Paares) für den Benutzer berechnet. Die gesamte Berechnungslogik ist unkompliziert. Die Funktion verwendet jedoch einen Modifikator namens updateVault, der zur entsprechenden Aktualisierung der Belohnungen dient.

Kurz gesagt, updateVault wird:

  1. zuerst die Funktion _earnFees aufrufen, um die angesammelten Gebühren aus dem Pool zu erhalten;
  2. dann die Funktion _tokenPerShare aufrufen, um token0PerShareStored und token1PerShareStored zu aktualisieren, die die Mengen an Token0 und Token1 im Pool pro Share darstellen;
  3. schließlich die Funktionen _fee0Earned und _fee1Earned aufrufen, um die Belohnungen für den Benutzer zu aktualisieren (d. h. token0Rewards bzw. token1Rewards).

Die Funktionen _fee0Earned und _fee1Earned teilen sich dieselbe Logik, d. h. sie implementieren die folgende Formel (am Beispiel von Token0):

user.token0Rewards += PLP.balanceOf(account) * (fee0PerShare - user.token0PerSharePaid) / 1e18

Beachten Sie, dass die Berechnung inkrementell ist, was bedeutet, dass die berechnete Belohnung den in token0Rewards gespeicherten Wert beibehält, auch wenn der Benutzer KEINEN PLP-Token hält.

Daher können wir die folgenden zwei Beobachtungen ableiten:

  1. Die Belohnungen des Benutzers werden in token0Rewards und token1Rewards gespeichert, die nicht mit PLP-Token verbunden sind.;
  2. Die Funktion collectFees hängt nur vom Status von token0Rewards und token1Rewards ab, was bedeutet, dass Belohnungen ohne Besitz von PLP-Token abgehoben werden können.

In der realen Welt bedeutet dies, dass eine Benutzerin Geld bei einer Bank einzahlt und die Bank ihr eine Einzahlungsbescheinigung ausstellt. Leider ist diese Bescheinigung weder fälschungssicher noch an die Benutzerin gebunden. In einem solchen Fall ist es möglich, Duplikate zu erstellen und diese an andere zu verteilen, um Gewinne von der Bank zu erzielen.

Angriffablauf

Kurz gesagt, der Angreifer führte die folgenden Schritte aus, um den Angriff zu starten:

  1. Erstellte drei Verträge. Einer davon wurde verwendet, um den Angriff zu starten, während die anderen beiden verwendet wurden, um die Funktion collectFees aufzurufen und die Belohnungen einzufordern;
  2. Nutzte den Flash Loan, d. h. die Ausleihe einer großen Menge Liquidität von AAVE;
  3. Startete den Deposit-Withdraw-CollectFees-Zyklus, um den Angriff durchzuführen (es gab insgesamt 8 Zyklen, und viel Liquidität wurde aus mehreren Vaults von Popsicle Finance abgezogen);
  4. Gab den Flash Loan zurück an AAVE und wusch die Gewinne über Tornado.Cash.

Insbesondere besteht der Deposit-Withdraw-CollectFees-Zyklus aus mehreren Schritten, die leicht gekennzeichnet und klar zusammengefasst werden können, indem unser Online-Tool verwendet wird [2];

Gewinnanalyse

Insgesamt erntete der Angreifer 20 Mio. USD von Popsicle Finance, darunter 2,56 K WETH, 96,2 WBTC, 160 K DAI, 5,39 Mio. USDC, 4,98 Mio. USDT, 10,5 K UNI. Nach dieser Ausnutzung tauschte der Angreifer zunächst alle anderen Token über Uniswap und WETH in ETH um und führte dann Geldwäsche mit Tornado.Cash durch.

Credits

Yufeng Hu, Ziling Lin, Junjie Fei, Lei Wu, Yajin Zhou @BlockSec

(In alphabetischer Reihenfolge nach Nachnamen)

https://www.blocksecteam.com

Medium: https://blocksecteam.medium.com/

Twitter: https://twitter.com/BlockSecTeam

Kontakt: [email protected]

Referenz

[1] https://twitter.com/defiprime/status/1422708265423556611

[2] https://tx.blocksecteam.com/

Für die neuesten Informationen anmelden
Über die sichere Speicherung hinaus, Teil 2: Wallet-Kryptografie sicher implementieren
Security Insights

Über die sichere Speicherung hinaus, Teil 2: Wallet-Kryptografie sicher implementieren

Kann ein Angreifer einen privaten Schlüssel rekonstruieren, ohne dessen geschützte Kopie auszulesen? Teil 2 von Beyond Secure Storage untersucht sechs Vorfälle, bei denen schwache Zufallszahlen, Entropieverlust oder Fehler bei Signatur-Nonces Schlüssel vorhersagbar oder rekonstruierbar machten. Daraus leitet er Anforderungen an die Implementierung der Schlüsselerzeugung und des Signierens ab und erläutert anschließend, wie Zahlungsinstitute deren Einhaltung durch Code-Reviews und Tests des produktiv eingesetzten Systems überprüfen können.

Über sichere Speicherung hinaus, Teil 1: Sichere Zahlungs- und Signaturabläufe gestalten
Security Insights

Über sichere Speicherung hinaus, Teil 1: Sichere Zahlungs- und Signaturabläufe gestalten

Wie kann ein nicht autorisierter Vorgang eine gültige Signatur erhalten, ohne dass der Angreifer den privaten Schlüssel stiehlt? Teil 1 von Beyond Secure Storage untersucht anhand von Vorfällen bei Bitget, Bybit und Binance Autorisierungsfehler bei Zahlungsanforderungen, der Erstellung, Signierung und Ausführung von Transaktionen sowie bei deren Abwicklung. Daraus leitet er Gestaltungsprinzipien ab, um nicht autorisierte Vorgänge zu verhindern und Verluste zu begrenzen. Anschließend erläutert er, wie Überprüfungen, Audits, Penetrationstests und Übungen diese Schutzmaßnahmen verifizieren können.

NEAR-Intents-Exploit: Fehler bei der Rückerstattung und Lehren für die Sicherheit
Security Insights

NEAR-Intents-Exploit: Fehler bei der Rückerstattung und Lehren für die Sicherheit

Beim Exploit von NEAR Intents wurden überdimensionierte Rückerstattungsereignisse genutzt, um interne Guthaben zu erhalten, nachdem die eingezahlten Vermögenswerte zurückgegeben worden waren. Diese Analyse rekonstruiert den Ablauf der Receipts und sieben Auszahlungen auf der BNB Chain in Höhe von insgesamt 3.865.021 USDT. Sie unterscheidet diese Mittelabflüsse von der vom Projekt gemeldeten vollständigen Rückgewinnung der Mittel und erläutert Sicherheitsaspekte bei der Entwicklung und Prüfung von NEAR-Smart-Contracts.

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
Analyse des Popsicle Finance Sicherheitsvorfalls