DxSale traci $7.3M w ataku na dostawców płynności (LP) na BNB Chain

DxSale, długo działająca platforma do launchów tokenów i blokowania płynności, szeroko używana podczas wczesnego boomu memecoinów na BNB Chain, padła ofiarą poważnego exploitu, który uszczuplił szacunkowo $7.3 million środków dostawców płynności (LP).

Zdarzenie dotknęło ponad 1,400 pul płynności, zgodnie z analizą on-chain udostępnioną po incydencie.

Pule rozciągały się na wiele starszych projektów tokenów, z których wiele nie odnotowało aktywnego rozwoju ani obrotu od lat, lecz nadal miało zablokowaną płynność w kontraktach DxSale.

Co istotne, exploit nie wydawał się atakować pojedynczego tokena czy projektu. Zamiast tego uderzył w warstwę wspólnej infrastruktury używaną przez setki wdrożeń, co zwiększyło skalę strat.

How the attack on the BNB Chain LPs happened

Analiza on-chain i rozbicia śledcze Tahax sugerują, że exploit nie był nagły.

Zamiast tego rozegrał się poprzez serię kontrolowanych zmian administracyjnych, które miały miejsce miesiące przed faktycznym odpływem środków.

Około 269 dni przed zdarzeniem, deployer DxSale rzekomo przeniósł własność kluczowego kontraktu locker do nowego portfela. Transfer nie został publicznie ogłoszony i nie wydano żadnego powiadomienia o migracji dla użytkowników ani zespołów tokenów polegających na systemie.

Z czasem kontrola własności nie pozostała statyczna. Prawa administracyjne podobno były przekazywane przez około 80 oddzielnych transferów między portfelami, z których każdy miał na celu ukrycie śladów zmian własności.

Te ruchy zmniejszyły przejrzystość tego, kto ostatecznie kontrolował system locker, przy jednoczesnym utrzymaniu uprawnień administracyjnych.

Dwa dni przed rozpoczęciem ataku, własność została skonsolidowana w jednym portfelu:

0xC4574DDEF299e7E563971e200433e592EeaaFA69

Portfel został nowo utworzony i podobno zasilony przez Bybit, z aktywnością routingu związaną z infrastrukturą mostów międzyłańcuchowych często używaną do zaciemniania źródeł środków.

W ciągu kilku godzin od tej konsolidacji rozpoczęła się działalność odpływu płynności w setkach pul tokenów.

Technical execution of the drain

A szczegółowe opracowanie analityków bezpieczeństwa on-chain z Coinsult opisało mechanizm użyty do wydobycia środków z systemu locker DxSale.

Atakujący kontrakt, wdrożony krótko przed incydentem, nie był zweryfikowany i został zbudowany przy użyciu Solidity 0.8.33. Działał jako pojedynczy koordynator, pozwalając na wykonanie wielu akcji w jednej transakcji za pomocą logiki samowywołań.

Sekwencja działań wymierzona była w wewnętrzne mechanizmy kontraktu locker.

Najpierw napastnik wywołał funkcję, która obniżyła opłatę za blokowanie do 1 wei, skutecznie usuwając barierę kosztową przy modyfikowaniu zablokowanych pozycji.

Następnie podjęto drugą czynność, która ustawiła znacznik czasu wygaśnięcia blokady na 68 sekund po epoce Unix, skutecznie resetując blokadę do momentu, który już nie chronił zdeponowanej płynności.

Potem parametr opłaty został podniesiony do ekstremalnie wysokiej wartości, około 1e29, która najwyraźniej została użyta do zakłócenia normalnego zachowania interakcji z kontraktem podczas wykonania.

Gdy stan wewnętrzny został zmodyfikowany, napastnik zainicjował powtarzające się wywołania wypłat, które pozwoliły na wyciągnięcie tokenów z locker.

Środki te zostały następnie skonwertowane na WBNB i BNB, zanim zostały przetransferowane wieloma trasami w celu zaciemnienia śladu transakcji.

Struktura kontraktu oznaczała, że po zmianie parametrów administracyjnych status 'zablokowane' płynności nie odzwierciedlał już rzeczywistych ograniczeń wypłat.

Why the LP locker system became a target

DxSale był powszechnie używany podczas boomu memecoinów w 2021 roku na BNB Chain jako domyślne narzędzie do blokowania płynności.

Wiele emisji tokenów polegało na nim, by wykazać bezpieczeństwo wobec wczesnych inwestorów, blokując tokeny puli płynności na dłuższe okresy.

Jednak model bezpieczeństwa systemu w dużej mierze opierał się na kontroli administracyjnej, a nie na całkowicie niezmiennym kodzie kontraktu.

Według analizy, funkcje takie jak dostosowywanie opłat i konfiguracja blokad pozostawały dostępne poprzez uprzywilejowane role właścicielskie.

Analitycy bezpieczeństwa zauważyli, że exploit stał się możliwy, ponieważ kontrakt locker wciąż miał aktywny klucz właściciela zdolny do modyfikowania krytycznych parametrów.

Oznaczało to, że 'zablokowana' płynność nie była ściśle egzekwowana przez niezmienny kod, lecz rządzona przez konfigurowalne ustawienia kontraktu.