Analiza techniczna: Atak na Balancer o wartości 120 milionów dolarów – na czym polegała luka w zabezpieczeniach?

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

Wstęp

3 listopada 2025 roku protokół Balancer został zaatakowany na wielu łańcuchach, w tym na Arbitrum i Ethereum, co doprowadziło do utraty aktywów o wartości 120 milionów dolarów. Atak był głównie wynikiem podwójnej podatności związanej z utratą precyzji oraz manipulacją Invariant.

Infrastruktura Chainlink od dawna utrzymuje najwyższe standardy w przestrzeni Web3, co czyni ją naturalnym wyborem dla X Layer, który jest dedykowany dostarczaniu narzędzi klasy instytucjonalnej dla deweloperów.

Kluczowy problem w tym ataku leży w logice protokołu dotyczącej obsługi małych transakcji. Gdy użytkownicy dokonują wymian na niewielkie kwoty, protokół wywołuje funkcję _upscaleArray, która używa mulDown do zaokrąglania wartości w dół. Gdy saldo w transakcji oraz kwota wejściowa osiągają określoną granicę zaokrąglenia (np. zakres 8-9 wei), pojawia się zauważalny względny błąd precyzji.

Błąd ten jest propagowany do obliczania wartości Invariant D protokołu, powodując nienormalne zmniejszenie wartości D. Wahania wartości D bezpośrednio obniżają cenę Balancer Pool Token (BPT) w protokole Balancer. Haker wykorzystał tę zaniżoną cenę BPT poprzez zaplanowaną ścieżkę handlową do arbitrażu, co ostatecznie doprowadziło do ogromnej straty aktywów.

Wykorzystana transakcja:

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

Transakcja transferu aktywów:

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

Analiza techniczna

Wektor ataku

Punktem wejścia ataku był kontrakt Balancer: Vault, a odpowiadającą mu funkcją wejściową była batchSwap, która wewnętrznie wywołuje onSwap do wymiany tokenów.

Z perspektywy parametrów funkcji i ograniczeń można uzyskać kilka informacji:

1. Atakujący musi wywołać tę funkcję przez Vault i nie może jej wywołać bezpośrednio.

2. Funkcja wewnętrznie wywołuje _scalingFactors(), aby uzyskać współczynnik skalowania do operacji skalowania.

3. Operacja skalowania jest skoncentrowana w _swapGivenIn lub _swapGivenOut.

Analiza wzorca ataku

Mechanizm obliczania ceny BPT

W modelu stable pool Balancer, cena BPT jest kluczowym punktem odniesienia, który określa, ile BPT otrzymuje użytkownik i ile aktywów przypada na każdy BPT.

W obliczeniach wymiany w puli:

Częścią pełniącą rolę kotwicy ceny BPT jest niezmienna wartość D, co oznacza, że kontrolowanie ceny BPT wymaga kontrolowania D. Przeanalizujmy dalej proces obliczania D:

W powyższym kodzie proces obliczania D zależy od tablicy zbilansowanych wartości po skalowaniu. Oznacza to, że potrzebna jest operacja zmieniająca precyzję tych sald, prowadząca do nieprawidłowego obliczenia D.

Główna przyczyna utraty precyzji

Operacja skalowania:

Jak pokazano powyżej, podczas przechodzenia przez _upscaleArray, jeśli saldo jest bardzo małe (np. 8-9 wei), zaokrąglenie w dół w mulDown skutkuje znaczną utratą precyzji.

Szczegółowy przebieg ataku

Faza 1: Dostosowanie do granicy zaokrąglenia

Faza 2: Wywołanie utraty precyzji (główna podatność)

Faza 3: Wykorzystanie zaniżonej ceny BPT dla zysku

Powyżej atakujący używa Batch Swap, aby wykonać wiele wymian w jednej transakcji:

1. Pierwsza wymiana: BPT → cbETH (dostosowanie salda)

2. Druga wymiana: wstETH (8) → cbETH (wywołanie utraty precyzji)

3. Trzecia wymiana: Aktywo bazowe → BPT (realizacja zysku)

Wszystkie te wymiany odbywają się w ramach tej samej transakcji batch swap, dzieląc ten sam stan salda, ale każda wymiana wywołuje _upscaleArray, aby zmodyfikować tablicę sald.

Brak mechanizmu callback

Główny proces jest inicjowany przez Vault. Jak to prowadzi do kumulowania się utraty precyzji? Odpowiedź tkwi w mechanizmie przekazywania tablicy sald.

Patrząc na powyższy kod, chociaż Vault tworzy nową tablicę currentBalances za każdym razem, gdy wywoływany jest onSwap, w Batch Swap:

1. Po pierwszej wymianie saldo jest aktualizowane (ale z powodu utraty precyzji zaktualizowana wartość może być niedokładna)

2. Druga wymiana kontynuuje obliczenia na podstawie wyniku pierwszej wymiany

3. Utrata precyzji się kumuluje, co ostatecznie powoduje znaczny spadek wartości invariant D

Kluczowy problem:

Podsumowanie

Atak na Balancer można podsumować następująco:

1. Funkcja skalowania używa zaokrąglania w dół: _upscaleArray używa mulDown do skalowania, co skutkuje znaczną względną utratą precyzji, gdy saldo jest bardzo małe (np. 8-9 wei).

2. Obliczanie wartości invariant jest wrażliwe na precyzję: Obliczanie wartości invariant D opiera się na tablicy zbilansowanych wartości po skalowaniu, a utrata precyzji bezpośrednio wpływa na obliczanie D, powodując jego spadek.

3. Brak walidacji zmiany wartości invariant: Podczas procesu wymiany nie było walidacji, aby upewnić się, że zmiana wartości invariant D mieści się w rozsądnym zakresie, co pozwoliło atakującym wielokrotnie wykorzystywać utratę precyzji do zaniżania ceny BPT.

4. Kumulacja utraty precyzji w batch swapach: W ramach tego samego batch swap utrata precyzji z wielu wymian się kumuluje i ostatecznie prowadzi do znacznych strat finansowych.

Te dwa problemy — utrata precyzji i brak walidacji — w połączeniu z przemyślanym projektowaniem warunków brzegowych przez atakującego, doprowadziły do tej straty.