DxSale verliest $7.3M bij hack van BNB Chain liquidity providers (LPs)

DxSale, een langlopend platform voor tokenlanceringen en het vergrendelen van liquiditeit dat veel werd gebruikt tijdens de vroege BNB Chain-memecoinboom, is getroffen door een grote exploit waardoor naar schatting $7.3 miljoen aan fondsen van liquidity providers (LP) is onttrokken.

Volgens on-chain tracking die na het incident werd gedeeld, raakte het incident meer dan 1,400 liquidity pools.

De pools waren verspreid over meerdere oudere tokenprojecten, van veel daarvan was al jaren geen actieve ontwikkeling of handelsactiviteit meer te zien, maar ze hielden nog steeds vergrendelde liquiditeit in DxSale-contracten.

Opvallend is dat de exploit niet gericht leek op één token of project. In plaats daarvan trof het een gedeelde infrastructuurlaag die door honderden implementaties werd gebruikt, waardoor de schaal van de verliezen werd vergroot.

Hoe de aanval op de BNB Chain LPs plaatsvond

On-chainanalyse en door onderzoekers gepubliceerde analyses van Tahax suggereren dat de exploit niet plotseling was.

In plaats daarvan ontwikkelde het zich via een reeks gecontroleerde administratieve wijzigingen die maanden voor de daadwerkelijke onttrekking plaatsvonden.

Ongeveer 269 dagen voor het incident zou de DxSale-deployer het eigendom van een kernachtig lockercontract naar een nieuw walletadres hebben overgedragen. De overgang werd niet openbaar aangekondigd en er werd geen migratiebericht uitgegeven aan gebruikers of tokenteams die op het systeem vertrouwden.

In de loop van de tijd bleef de eigendomscontrole niet statisch. De adminrechten zouden via ongeveer 80 afzonderlijke walletoverdrachten zijn verplaatst, elk bedoeld om het spoor van eigendomsoverdrachten te verhullen.

Door deze bewegingen nam de zichtbaarheid af wie uiteindelijk het locker-systeem controleerde, terwijl de administratieve privileges intact bleven.

Twee dagen voordat de exploit begon, werd het eigendom geconsolideerd in één wallet:

0xC4574DDEF299e7E563971e200433e592EeaaFA69

De wallet was nieuw aangemaakt en zou gefinancierd zijn via Bybit, met routeringsactiviteit gekoppeld via cross-chain bridge-infrastructuur die vaak wordt gebruikt om de oorsprong van fondsen te verhullen.

Binnen enkele uren na deze consolidatie begon het onttrekken van liquiditeit in honderden tokenpools.

Technische uitvoering van de onttrekking

Een gedetailleerde analyse door on-chain security-analisten van Coinsult beschreef het mechanisme dat werd gebruikt om fondsen uit het DxSale-lockersysteem te halen.

Het aanvallende contract, kort voor het incident uitgerold, was niet geverifieerd en gebouwd met Solidity 0.8.33. Het fungeerde als één orkestrator, waardoor meerdere acties binnen één transactie konden worden uitgevoerd via zelfaanroepende logica.

De uitvoeringsvolgorde was gericht op de interne mechanismen van het lockercontract.

Eerst activeerde de aanvaller een functie die de locking fee terugbracht naar 1 wei, waardoor kostenbarrières voor het wijzigen van vergrendelde posities effectief verdwenen.

Hierop volgde een tweede actie die de lock-expiratietimestamp instelde op 68 seconden na de Unix-epoch, waarmee de lock effectief werd teruggezet naar een tijd die de gestorte liquiditeit niet langer beschermde.

Daarna werd de fee-parameter verhoogd tot een extreem hoge waarde, ongeveer 1e29, die blijkbaar werd gebruikt om het normale contractinteractiegedrag tijdens de uitvoering te verstoren.

Zodra de interne staat was aangepast, startte de aanvaller herhaalde withdrawal-aanroepen waardoor tokens uit het locker konden worden onttrokken.

Deze fondsen werden vervolgens geconverteerd naar WBNB en BNB voordat ze via meerdere routes werden verplaatst om het transactiepad te verdoezelen.

De structuur van het contract betekende dat zodra administratieve parameters waren gewijzigd, de “vergrendelde” status van liquiditeit niet langer overeenkwam met daadwerkelijke opnamebeperkingen.

Waarom het LP-lockersysteem een doelwit werd

DxSale werd veel gebruikt tijdens de memecoin-boom van 2021 op BNB Chain als standaardtool voor het vergrendelen van liquiditeit.

Veel tokenlanceringen vertrouwden erop om vroege investeerders zekerheid te tonen door liquidity pool-tokens voor langere periodes te vergrendelen.

Het beveiligingsmodel van het systeem was echter sterk afhankelijk van administratieve controle in plaats van volledig immutabele contractlogica.

Volgens de analyse bleven functies zoals fee-aanpassingen en lockconfiguratie toegankelijk via bevoorrechte eigendomsrollen.

Security-analisten merkten op dat de exploit mogelijk werd omdat het lockercontract nog een actieve owner-sleutel had die kritieke parameters kon wijzigen.

Dit betekende dat “vergrendelde” liquiditeit niet strikt werd afgedwongen door onveranderlijke code, maar in plaats daarvan werd beheerst door aanpasbare contractinstellingen.