DxSale přišel o $7.3M v útoku na poskytovatele likvidity BNB Chain (LPs)

DxSale, dlouhodobá platforma pro launch tokenů a zamykání likvidity široce používaná v počátečním memecoinovém boomu na BNB Chain, utrpěla závažný exploit, který vyčerpal odhadovaných $7.3 million prostředků poskytovatelů likvidity (LP).

Incident postihl více než 1,400 likviditních poolů, podle on-chain sledování sdíleného po incidentu.

Pooly byly rozmístěny napříč několika staršími tokenovými projekty, z nichž mnohé několik let neprocházely aktivním vývojem ani obchodováním, ale přesto měly v DxSale kontraktech uzamčenou likviditu.

Zvláště pozoruhodné je, že exploit se nezdál cílit na jeden konkrétní token nebo projekt. Místo toho zasáhl sdílenou infrastrukturní vrstvu používanou stovkami nasazení, čímž se rozsah ztrát znásobuje.

Jak k útoku na BNB Chain LPs došlo

On-chain analýzy a rozbory vyšetřovatelů od Tahax naznačují, že exploit nebyl náhlý.

Místo toho se odehrál v průběhu série řízených administrativních změn, které proběhly měsíce před samotným odčerpáním.

Přibližně 269 dní před incidentem údajně přenesl deployer DxSale vlastnictví klíčového locker kontraktu na novou peněženku. Přechod nebyl veřejně oznámen a uživatelé ani týmy tokenů na systému nebyli informováni o migraci.

V průběhu času se kontrola vlastnictví neponechala statická. Administrátorská práva byla podle zpráv přesouvána přibližně v 80 samostatných převodech mezi peněženkami, z nichž každý byl navržen tak, aby zakryl stopu změn v držení.

Tyto přesuny snížily přehled o tom, kdo nakonec systém lockerů kontroloval, přičemž administrativní privilegia zůstávala v platnosti.

Dva dny před začátkem exploitu bylo vlastnictví konsolidováno do jedné peněženky:

0xC4574DDEF299e7E563971e200433e592EeaaFA69

Peněženka byla nově vytvořena a podle zpráv financována přes Bybit, přičemž směrovací aktivita byla navázána přes cross-chain bridge infrastrukturu často používanou k zakrytí původu prostředků.

Během několika hodin po této konsolidaci začala aktivita odčerpávající likviditu napříč stovkami tokenových poolů.

Technické provedení odčerpání

A podrobný rozbor od on-chain bezpečnostních analytiků ve Coinsult popsal mechanismus použitý k extrakci prostředků z DxSale locker systému.

Útočný kontrakt, nasazený krátce před incidentem, nebyl ověřen a byl postaven pomocí Solidity 0.8.33. Fungoval jako jediný orchestrátor, umožňující provedení více akcí v rámci jedné transakce prostřednictvím self-calling logiky.

Pořadí vykonání cílilo na interní mechanismy locker kontraktu.

Nejprve útočník spustil funkci, která snížila poplatek za zamykání na 1 wei, čímž de facto odstranil nákladové bariéry pro úpravy zamknutých pozic.

Následovala druhá akce, která nastavila časový údaj vypršení zámku na 68 sekund po Unix epochě, čímž resetovala zámek na čas, který již nechránil deponovanou likviditu.

Poté byl parametr poplatku zvýšen na extrémně vysokou hodnotu, přibližně 1e29, která se zdá byla použita k narušení normálního chování při interakci s kontraktem během vykonávání.

Jakmile byl interní stav změněn, útočník zahájil opakované volání výběrů, které umožnilo vytáhnout tokeny z lockeru.

Tyto prostředky byly následně převedeny na WBNB a BNB a poté přesunuty více trasami, aby byla zakryta transakční stopa.

Struktura kontraktu znamenala, že jakmile byly administrativní parametry změněny, stav „zamknuté“ likvidity již nereflektoval skutečná omezení pro výběry.

Proč se systém LP lockerů stal cílem

DxSale byl široce používán během memecoinového boomu roku 2021 na BNB Chain jako standardní nástroj pro zamykání likvidity.

Mnoho launchů tokenů se na něj spoléhalo, aby ukázalo zabezpečení raným investorům tím, že zamykalo tokeny likviditních poolů na delší období.

Systém však silně závisel na administrativní kontrole spíše než na plně neměnné logice kontraktu.

Podle analýzy zůstaly funkce jako úpravy poplatků a konfigurace zámku přístupné prostřednictvím privilegovaných vlastnických rolí.

Bezpečnostní analytici poukázali, že exploit byl možný, protože locker kontrakt stále disponoval aktivním klíčem vlastníka schopným měnit kritické parametry.

To znamenalo, že „zamknutá“ likvidita nebyla striktně vynucena neměnným kódem, ale byla řízena nastavitelými parametry kontraktu.