Technische Analyse: Balancer-Hack von 120 Millionen Dollar – Was war die Schwachstelle?

Original Article Title: " Balancer $120M Hack Vulnerability Technical Analysis"
Original Source: ExVul Security

Vorwort

Am 3. November 2025 wurde das Balancer-Protokoll auf mehreren Chains, darunter Arbitrum und Ethereum, angegriffen, was zu einem Vermögensverlust von 120 Millionen US-Dollar führte. Der Angriff beruhte hauptsächlich auf einer doppelten Schwachstelle, die sowohl einen Präzisionsverlust als auch eine Manipulation der Invariant betraf.

Die Infrastruktur von Chainlink hat im Web3-Bereich schon lange die höchsten Standards gehalten, was sie zur natürlichen Wahl für X Layer macht, das sich der Bereitstellung von institutionellen Entwickler-Tools verschrieben hat.

Das Hauptproblem bei diesem Angriff liegt in der Protokoll-Logik zur Verarbeitung kleiner Transaktionen. Wenn Nutzer mit kleinen Beträgen tauschen, ruft das Protokoll die Funktion _upscaleArray auf, die mulDown für das Abrunden von Werten verwendet. Wenn sowohl das Guthaben in der Transaktion als auch der Eingabebetrag eine bestimmte Rundungsgrenze erreichen (z. B. im Bereich von 8-9 wei), tritt ein deutlicher relativer Präzisionsfehler auf.

Dieser Präzisionsfehler wird in die Berechnung des Invariant-Werts D des Protokolls weitergegeben, was zu einer abnormalen Reduzierung des D-Werts führt. Die Schwankung des D-Werts senkt direkt den Preis des Balancer Pool Token (BPT) im Balancer-Protokoll. Der Angreifer nutzte diesen unterdrückten BPT-Preis durch einen vorbereiteten Handelsweg für Arbitrage aus, was letztlich zu einem massiven Vermögensverlust führte.

Ausgenutzte Transaktion:

https://etherscan.io/tx/0x6ed07db1a9fe5c0794d44cd36081d6a6df103fab868cdd75d581e3bd23bc9742

Vermögensübertragungs-Transaktion:

https://etherscan.io/tx/0xd155207261712c35fa3d472ed1e51bfcd816e616dd4f517fa5959836f5b48569

Technische Analyse

Angriffsvektor

Der Einstiegspunkt des Angriffs war der Balancer: Vault-Vertrag, wobei die entsprechende Einstiegsfunktion die batchSwap-Funktion war, die intern onSwap für Token-Tauschvorgänge aufruft.

Aus Sicht der Funktionsparameter und -einschränkungen lassen sich mehrere Informationen ableiten:

1. Der Angreifer muss diese Funktion über den Vault aufrufen und kann sie nicht direkt aufrufen.

2. Die Funktion ruft intern _scalingFactors() auf, um den Skalierungsfaktor für Skalierungsoperationen zu erhalten.

3. Die Skalierungsoperation konzentriert sich entweder auf _swapGivenIn oder _swapGivenOut.

Analyse des Angriffsmusters

BPT-Preiskalkulationsmechanismus

Im Stable-Pool-Modell von Balancer ist der BPT-Preis ein entscheidender Referenzpunkt, der bestimmt, wie viel BPT ein Nutzer erhält und wie viel jeder BPT an Vermögenswerten erhält.

Bei der Berechnung des Pool-Tauschs:

Der Teil, der als BPT-Preisanker fungiert, ist ein unveränderlicher Wert D, was bedeutet, dass die Kontrolle des BPT-Preises die Kontrolle über D erfordert. Analysieren wir den Berechnungsprozess von D weiter:

Im obigen Code hängt der Berechnungsprozess von D vom skalierten Salden-Array ab. Das bedeutet, dass eine Operation erforderlich ist, um die Präzision dieser Salden zu ändern, was zu einer fehlerhaften D-Berechnung führt.

Ursache des Präzisionsverlusts

Skalierungsoperation:

Wie oben gezeigt, führt das Durchlaufen von _upscaleArray bei sehr kleinen Salden (z. B. 8-9 wei) dazu, dass das Abrunden in mulDown zu erheblichen Präzisionsverlusten führt.

Angriffsprozess im Detail

Phase 1: Anpassung an die Rundungsgrenze

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

Phase 3: Ausnutzen des gedrückten BPT-Preises für Profit

Oben nutzt der Angreifer Batch Swap, um mehrere Tauschvorgänge in einer Transaktion durchzuführen:

1. Erster Tausch: BPT → cbETH (Saldoanpassung)

2. Zweiter Tausch: wstETH (8) → cbETH (Präzisionsverlust auslösen)

3. Dritter Tausch: Basiswert → BPT (Gewinnmitnahme)

Alle diese Tauschvorgänge finden in derselben Batch-Swap-Transaktion statt und teilen denselben Saldenzustand, aber jeder Tausch ruft _upscaleArray auf, um das Salden-Array zu modifizieren.

Fehlender Callback-Mechanismus

Der Hauptprozess wird vom Vault initiiert. Wie führt dies zur Akkumulation von Präzisionsverlusten? Die Antwort liegt im Übertragungsmechanismus des Salden-Arrays.

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

1. Nach dem ersten Swap wird das Guthaben aktualisiert (aber aufgrund des Präzisionsverlusts kann der aktualisierte Wert ungenau sein)

2. Der zweite Swap setzt die Berechnung auf Basis des Ergebnisses des ersten Swaps fort

3. Der Präzisionsverlust akkumuliert sich und führt schließlich dazu, dass der Invariant-Wert D erheblich sinkt

Schlüsselproblem:

Zusammenfassung

Der Balancer-Angriff lässt sich aus folgenden Gründen zusammenfassen:

1. Skalierungsfunktion verwendet Abrunden: _upscaleArray verwendet mulDown für die Skalierung, was bei sehr kleinen Salden (z. B. 8-9 wei) zu erheblichen relativen Präzisionsverlusten führt.

2. Invariant-Wert-Berechnung ist empfindlich gegenüber Präzision: Die Berechnung des Invariant-Werts D basiert auf dem skalierten Salden-Array, und Präzisionsverlust wirkt sich direkt auf die Berechnung von D aus und führt zu dessen Abnahme.

3. Fehlende Validierung der Änderung des Invariant-Werts: Während des Swap-Prozesses gab es keine Validierung, um sicherzustellen, dass die Änderung des Invariant-Werts D im angemessenen Bereich lag, sodass Angreifer den Präzisionsverlust wiederholt ausnutzen konnten, um den BPT-Preis zu drücken.

4. Akkumulation von Präzisionsverlusten bei Batch Swaps: Innerhalb desselben Batch Swaps akkumulieren sich die Präzisionsverluste mehrerer Swaps und führen schließlich zu erheblichen finanziellen Verlusten.

Diese beiden Probleme – Präzisionsverlust und fehlende Validierung – in Kombination mit der sorgfältigen Gestaltung der Randbedingungen durch den Angreifer führten zu diesem Verlust.