Analyse des Sicherheitvorfalls bei Popsicle Finance

Analyse des Sicherheitvorfalls bei Popsicle Finance

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 verwenden wir eine Angriffstransaktion, um den Angriffsprozess und die Grundursache der Schwachstelle zu veranschaulichen.

Hintergrund

Popsicle Finance ist eine Plattform zur Ertragsoptimierung, die mehrere Tresore für verschiedene Ketten (z. B. Ethereum und BSC) unterstützt.

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

Schwachstellenanalyse

In der collectFees-Funktion 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 Modifier namens updateVault, der verwendet wird, um die Belohnungen entsprechend zu aktualisieren.

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 Anteil darstellen;
  3. schließlich die Funktionen _fee0Earned und _fee1Earned aufrufen, um die Belohnungen für den Benutzer zu aktualisieren (d. h. token0Rewards und token1Rewards entsprechend).

Die Funktionen _fee0Earned und _fee1Earned teilen sich die gleiche 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 auch dann den in token0Rewards gespeicherten Wert beibehält, wenn der Benutzer KEINE PLP-Token besitzt.

Daher können wir die folgenden beiden Beobachtungen ableiten:

  1. Die Belohnungen des Benutzers werden in token0Rewards und token1Rewards gespeichert, die nicht mit PLP-Token verknüpft sind.
  2. Die Funktion collectFees ist nur vom Status von token0Rewards und token1Rewards abhängig, 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 mit der Benutzerin verknüpft. In einem solchen Fall ist es möglich, Duplikate zu erstellen und diese an andere zu verteilen, um Gewinne von der Bank zu erzielen.

Angriffsablauf

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

  1. Erstellung von drei Verträgen. Einer davon wurde verwendet, um den Angriff zu starten, während die beiden anderen verwendet wurden, um die collectFees-Funktion aufzurufen und die Belohnungen abzurufen;
  2. Nutzung des Flash Loans, d. h. Ausleihe einer großen Menge an Liquidität von AAVE;
  3. Start des Deposit-Withdraw-CollectFees-Zyklus, um den Angriff durchzuführen (es gab insgesamt 8 Zyklen und erhebliche Mengen an Liquidität wurden aus mehreren Tresoren von Popsicle Finance abgezogen);
  4. Rückgabe des Flash Loans an AAVE und Verschleierung der Gewinne über Tornado.Cash.

Insbesondere besteht der Deposit-Withdraw-CollectFees-Zyklus aus mehreren Schritten, die leicht beschriftet und mithilfe unseres Online-Tools [2] klar zusammengefasst werden können:

Gewinnanalyse

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

Anerkennung

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/

Sign up for the latest updates
Weekly Web3 Security Incident Roundup | Feb 9 – Feb 15, 2026

Weekly Web3 Security Incident Roundup | Feb 9 – Feb 15, 2026

During the week of February 9 to February 15, 2026, three blockchain security incidents were reported with total losses of ~$657K. All incidents occurred on the BNB Smart Chain and involved flawed business logic in DeFi token contracts. The primary causes included an unchecked balance withdrawal from an intermediary contract that allowed donation-based inflation of a liquidity addition targeted by a sandwich attack, a post-swap deflationary clawback that returned sold tokens to the caller while draining pool reserves to create a repeatable price-manipulation primitive, and a token transfer override that burned tokens directly from a Uniswap V2 pair's balance and force-synced reserves within the same transaction to artificially inflate the token price.

Top 10 "Awesome" Security Incidents in 2025

Top 10 "Awesome" Security Incidents in 2025

To help the community learn from what happened, BlockSec selected ten incidents that stood out most this year. These cases were chosen not only for the scale of loss, but also for the distinct techniques involved, the unexpected twists in execution, and the new or underexplored attack surfaces they revealed.

#10 Panoptic Incident: XOR Linearity Breaks the Position Fingerprint Scheme

#10 Panoptic Incident: XOR Linearity Breaks the Position Fingerprint Scheme

On August 29, 2025, Panoptic disclosed a Cantina bounty finding and confirmed that, with support from Cantina and Seal911, it executed a rescue operation on August 25 to secure roughly $400K in funds. The issue stemmed from a flaw in Panoptic’s position fingerprint calculation algorithm, which could have enabled incorrect position identification and downstream fund risk.