Balancer Hack Analyse: Wie kam es zum 120 Millionen Dollar Verlust?

Originaltitel: "Balancer 120M Hack Schwachstellen-Analyse"
Originalquelle: ExVul Security

Vorwort

Am 3. November 2025 wurde das Balancer-Protokoll auf mehreren Chains, darunter Arbitrum und Ethereum, angegriffen, was zu einem Verlust von 120 Millionen Dollar führte. Der Angriff beruhte primär auf einer doppelten Schwachstelle, die Präzisionsverluste und die Manipulation der Invariante umfasste.

Die Infrastruktur von Chainlink setzt seit langem die höchsten Standards im Web3-Bereich, was sie zu einer natürlichen Wahl für X Layer macht, das sich der Bereitstellung von Tools auf institutionellem Niveau für Entwickler widmet.

Das Kernproblem dieses Angriffs liegt in der Logik des Protokolls zur Handhabung kleiner Transaktionen. Wenn Nutzer einen Tausch mit kleinen Beträgen durchführen, ruft das Protokoll die Funktion _upscaleArray auf, die mulDown zum Abrunden von Werten verwendet. Wenn das Guthaben bei der Transaktion und der Eingabebetrag eine spezifische Rundungsgrenze (z. B. den 8-9 wei-Bereich) erreichen, tritt ein spürbarer relativer Präzisionsfehler auf.

Dieser Präzisionsfehler überträgt sich auf die Berechnung des Invarianten-Werts D des Protokolls, was zu einer abnormalen Verringerung 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 geplanten Handelsweg aus, um Arbitrage zu betreiben, was letztlich zu einem massiven Vermögensverlust führte.

Ausgenutzte Transaktion:

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

Vermögenstransfer-Transaktion:

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

Technische Analyse

Angriffsvektor

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

Aus der Perspektive der Funktionsparameter und Einschränkungen lassen sich mehrere Informationen gewinnen:

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 Skalierungsvorgänge zu erhalten.

3. Der Skalierungsvorgang 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 Vermögenswerte jeder BPT erhält.

In der Tauschberechnung des Pools:

Wobei der Teil, der als BPT-Preisanker fungiert, ein unveränderlicher Wert D ist, was bedeutet, dass die Kontrolle des BPT-Preises die Kontrolle von D erfordert. Lassen Sie uns den Berechnungsprozess von D weiter analysieren:

Im obigen Code hängt der Berechnungsprozess von D von dem skalierten Guthaben-Array ab. Dies bedeutet, dass ein Vorgang erforderlich ist, um die Präzision dieser Guthaben zu ändern, was zu einer falschen D-Berechnung führt.

Ursache für Präzisionsverlust

Skalierungsvorgang:

Wie oben gezeigt, führt das Abrunden in mulDown bei sehr kleinem Guthaben (z. B. 8-9 wei) beim Durchlaufen von _upscaleArray zu einem erheblichen Präzisionsverlust.

Detaillierter Angriffsablauf

Phase 1: Anpassung an die Rundungsgrenze

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

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

Oben verwendet der Angreifer Batch Swap, um mehrere Tausche in einer Transaktion durchzuführen:

1. Erster Tausch: BPT → cbETH (Guthabenanpassung)

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

3. Dritter Tausch: Basiswert → BPT (Gewinnmitnahme)

Alle diese Tausche erfolgen in derselben Batch-Swap-Transaktion und teilen sich denselben Guthabenstatus, aber jeder Tausch ruft _upscaleArray auf, um das Guthaben-Array zu ändern.

Fehlender Callback-Mechanismus

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

Wenn man sich den obigen Code ansieht, erstellt der Vault zwar jedes Mal ein neues currentBalances-Array, wenn onSwap aufgerufen wird, aber beim Batch Swap:

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

2. Der zweite Tausch setzt die Berechnung basierend auf dem Ergebnis des ersten Tauschs fort

3. Präzisionsverluste akkumulieren sich, was schließlich dazu führt, dass der Invarianten-Wert D signifikant abnimmt

Kernproblem:

Zusammenfassung

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

1. Skalierungsfunktion verwendet Abrunden: _upscaleArray verwendet mulDown zur Skalierung, was zu einem erheblichen relativen Präzisionsverlust führt, wenn das Guthaben sehr klein ist (z. B. 8-9 wei).

2. Berechnung des Invarianten-Werts ist präzisionsempfindlich: Die Berechnung des Invarianten-Werts D beruht auf dem skalierten Guthaben-Array, und der Präzisionsverlust wirkt sich direkt auf die Berechnung von D aus, was dazu führt, dass D abnimmt.

3. Fehlende Validierung der Änderung des Invarianten-Werts: Während des Tauschprozesses gab es keine Validierung, um sicherzustellen, dass die Änderung des Invarianten-Werts D in einem angemessenen Bereich liegt, was es Angreifern ermöglichte, wiederholt Präzisionsverluste auszunutzen, um den BPT-Preis zu unterdrücken.

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

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

Dieser Artikel ist ein Beitrag und repräsentiert nicht die Ansichten von BlockBeats.