Technische Analyse: Balancer wurde um 120 Millionen Dollar gehackt – Wo lag die Schwachstelle?

Originaltitel: „Balancer $120M Exploit Technical Analysis“
Originalquelle: ExVul Security

Einleitung

Am 3. November 2025 wurde das Balancer-Protokoll auf mehreren Blockchains wie Arbitrum und Ethereum von Hackern angegriffen, was zu einem Verlust von 120 Millionen US-Dollar an Vermögenswerten führte. Der Kern des Angriffs lag in einer doppelten Schwachstelle, die auf Präzisionsverlust und Manipulation der Invariante (Invariant) zurückzuführen ist.

Die Infrastruktur von Chainlink hält seit langem den höchsten Standard im Web3-Bereich und ist daher die natürliche Wahl für X Layer, um Entwicklern institutionelle Tools bereitzustellen.

Das Schlüsselproblem dieses Angriffs lag in der Logik des Protokolls zur Verarbeitung von Kleinsttransaktionen. Wenn Benutzer kleine Beträge tauschten, rief das Protokoll die Funktion _upscaleArray auf, die mit mulDown eine Abrundung nach unten vornimmt. Sobald das Guthaben und der Eingabebetrag einer Transaktion gleichzeitig an einer bestimmten Rundungsgrenze (z. B. im Bereich von 8-9 wei) liegen, entsteht ein signifikanter relativer Präzisionsfehler.

Der Präzisionsfehler wird in die Berechnung der Invariante D des Protokolls weitergegeben, was dazu führt, dass der D-Wert ungewöhnlich verkleinert wird. Die Veränderung des D-Werts senkt direkt den Preis des BPT (Balancer Pool Token) im Balancer-Protokoll. Hacker nutzten diesen künstlich gedrückten BPT-Preis aus, um durch vorab geplante Handelswege Arbitrage zu betreiben, was letztlich zu enormen Vermögensverlusten führte.

Exploit-Transaktion (Tx):

Asset-Transfer-Transaktion (Tx):

Technische Analyse

Angriffseinstieg

Der Einstiegspunkt des Angriffs war der Balancer: Vault-Vertrag, wobei die Einstiegsfunktion die batchSwap-Funktion ist, die intern onSwap für den Token-Tausch aufruft.

Aus den Funktionsparametern und -beschränkungen ergeben sich einige Informationen:

1. Der Angreifer muss diese Funktion über den Vault aufrufen, ein direkter Aufruf ist nicht möglich.

2. Die Funktion ruft intern _scalingFactors() auf, um Skalierungsfaktoren für die Skalierung zu erhalten.

3. Die Skalierungsoperationen konzentrieren sich auf _swapGivenIn oder _swapGivenOut.

Analyse des Angriffsmodus

Berechnungsmechanismus des BPT-Preises

Im Stable-Pool-Modell von Balancer ist der BPT-Preis eine wichtige Referenzgröße, die bestimmt, wie viele BPT ein Nutzer erhält und wie viele Vermögenswerte jeder BPT enthält.

Bei der Berechnung des Pool-Tauschs:

Der maßgebliche Teil für den BPT-Preis ist die Invariante D. Um den BPT-Preis zu manipulieren, muss D manipuliert werden. Im Folgenden wird der Berechnungsprozess von D analysiert:

Im obigen Code hängt die Berechnung von D vom skalierten balances-Array ab. Das bedeutet, dass eine Operation erforderlich ist, um die Präzision dieser balances zu verändern und so einen Fehler in der D-Berechnung zu verursachen.

Ursprung des Präzisionsverlusts

Skalierungsoperation:

Wie oben gezeigt, führt die Verwendung von _upscaleArray bei sehr kleinen Guthaben (z. B. 8-9 wei) durch die Abrundung mit mulDown zu erheblichen Präzisionsverlusten.

Detaillierter Angriffsablauf

Phase 1: Anpassung an die Rundungsgrenze

Phase 2: Auslösen des Präzisionsverlusts (Kernschwachstelle)

Phase 3: Profit durch den gedrückten BPT-Preis

Wie oben gezeigt, führt der Angreifer mit Batch Swap mehrere Swaps in einer Transaktion durch:

1. Erster Swap: BPT → cbETH (Anpassung des Guthabens)

2. Zweiter Swap: wstETH (8) → cbETH (Auslösen des Präzisionsverlusts)

3. Dritter Swap: Basiswert → BPT (Profit)

Alle diese Swaps finden in derselben batch swap-Transaktion statt und teilen sich denselben Kontostand, aber bei jedem Swap wird _upscaleArray aufgerufen, um das balances-Array zu ändern.

Fehlender Callback-Mechanismus

Der Hauptprozess wird vom Vault gestartet – wie kommt es also zur Akkumulation des Präzisionsverlusts? Die Antwort liegt im Übertragungsmechanismus des balances-Arrays.

Wie im obigen Code zu sehen ist, erstellt der Vault bei jedem Aufruf von onSwap zwar ein neues currentBalances-Array, aber im Batch Swap gilt:

1. Nach dem ersten Swap wird das Guthaben aktualisiert (kann aber durch Präzisionsverlust ungenau sein)

2. Der zweite Swap basiert auf dem Ergebnis des ersten Swaps

3. Der Präzisionsverlust akkumuliert sich und führt schließlich dazu, dass die Invariante D deutlich kleiner wird

Schlüsselproblem:

Fazit

Der Angriff auf Balancer lässt sich auf folgende Ursachen zurückführen:

1. Skalierungsfunktion verwendet Abrundung nach unten: _upscaleArray verwendet mulDown zur Skalierung. Bei sehr kleinen Guthaben (z. B. 8-9 wei) führt dies zu erheblichen relativen Präzisionsverlusten.

2. Invariante-Berechnung ist präzisionssensitiv: Die Berechnung der Invariante D hängt vom skalierten balances-Array ab. Präzisionsverluste werden direkt in die D-Berechnung übertragen und verkleinern D.

3. Fehlende Überprüfung der Invariante-Veränderung: Während des Swaps wird nicht überprüft, ob die Veränderung der Invariante D im akzeptablen Bereich liegt, sodass Angreifer den Präzisionsverlust wiederholt ausnutzen können, um den BPT-Preis zu drücken.

4. Akkumulation von Präzisionsverlusten im Batch Swap: Bei mehreren Swaps in einem Batch Swap akkumulieren sich die Präzisionsverluste und führen schließlich zu erheblichen finanziellen Schäden.

Diese beiden Probleme – Präzisionsverlust und fehlende Überprüfung – kombiniert mit der sorgfältigen Gestaltung der Randbedingungen durch die Angreifer, führten zu diesem Verlust.