DxSale förlorar $7.3M i hack mot BNB Chain LP:er

DxSale, en långlivad plattform för tokenlanseringar och likviditetslåsning som användes flitigt under den tidiga memecoin-boomen på BNB Chain, har drabbats av ett stort utnyttjande som dränerade uppskattningsvis $7.3M i likviditetsleverantörers (LP) medel.

Händelsen påverkade mer än 1,400 likviditetspooler, enligt on-chain-övervakning som delats efter incidenten.

Poolsen var spridda över flera äldre tokenprojekt, många av vilka inte sett aktiv utveckling eller handelsaktivitet på åratal men som fortfarande hade låst likviditet i DxSale-kontrakt.

Anmärkningsvärt är att exploateringen inte verkade rikta in sig på en enskild token eller ett enskilt projekt. Istället påverkade den ett delat infrastrukturlager som användes av hundratals deployment, vilket förstärkte omfattningen av förlusterna.

Hur attacken mot BNB Chain LP:erna gick till

On-chain-analys och utredarnas genomgångar från Tahax antyder att exploateringen inte var plötslig.

I stället utvecklades den genom en serie kontrollerade administrativa ändringar som skedde månader före den faktiska dräneringen.

Cirka 269 dagar före incidenten överförde DxSale-deployern enligt uppgift ägarskapet av ett centralt locker-kontrakt till en ny plånbok. Övergången tillkännagavs inte offentligt och ingen migreringsavisering skickades till användare eller tokenteam som förlitade sig på systemet.

Med tiden förblev inte ägarkontrollen statisk. Admin-rättigheterna flyttades enligt uppgift genom ungefär 80 separata plånbokstransfer, vardera utformade för att dölja spåret av vårdförändringar.

Dessa förflyttningar minskade insynen i vem som slutligen kontrollerade lockersystemet samtidigt som administrativa privilegier bibehölls.

Två dagar före att exploateringen inleddes konsoliderades ägarskapet till en enskild plånbok:

0xC4574DDEF299e7E563971e200433e592EeaaFA69

Plånboken var nyskapad och finansierades enligt uppgift via Bybit, med routingaktivitet kopplad genom cross-chain-bridge-infrastruktur som ofta används för att dölja fonders ursprung.

Inom några timmar efter denna konsolidering började likviditetsdränerande aktivitet över hundratals tokenpools.

Teknisk genomföring av dräneringen

En detaljerad genomgång från on-chain-säkerhetsanalytikerna på Coinsult beskrev mekanismen som användes för att extrahera medel från DxSale-lockersystemet.

Det attackerande kontraktet, deployerat kort före incidenten, var overifierat och byggt med Solidity 0.8.33. Det fungerade som en enda orkestrator, vilket gjorde det möjligt att flera åtgärder kördes i en transaktion genom själv-anropande logik.

Exekveringssekvensen riktade in sig mot de interna mekanismerna i locker-kontraktet.

Först utlöste angriparen en funktion som sänkte låsavgiften till 1 wei, vilket i praktiken avlägsnade kostnadsbarriärer för att ändra låsta positioner.

Det följdes av en andra åtgärd som satte lock-expiration-tidsstämpeln till 68 sekunder efter Unix-epoken, vilket i praktiken återställde låset till en tid som inte längre skyddade den insatta likviditeten.

Därefter höjdes avgiftsparametern till ett extremt högt värde, cirka 1e29, vilket verkar ha använts för att störa normalt kontraktsinteraktionsbeteende under exekveringen.

När det interna tillståndet väl förändrats initierade angriparen upprepade uttagsanrop som tillät tokens att dras ur lockern.

Dessa medel konverterades sedan till WBNB och BNB innan de fördes genom flera rutter för att dölja transaktionsspåret.

Kontraktets struktur innebar att när administrativa parametrar ändrats så speglade inte längre den ”låsta” statusen faktiska uttagsbegränsningar.

Varför LP-låssystemet blev ett mål

DxSale användes i stor utsträckning under memecoin-boomen 2021 på BNB Chain som ett standardverktyg för likviditetslåsning.

Många tokenlanseringar förlitade sig på det för att visa säkerhet för tidiga investerare genom att låsa likviditetspool-tokens under längre perioder.

Systemets säkerhetsmodell byggde dock till stor del på administrativ kontroll snarare än fullt immutabel kontraktslogik.

Enligt analysen förblev funktioner såsom avgiftsjusteringar och låskonfiguration åtkomliga via privilegierade ägarroller.

Säkerhetsanalytiker noterade att exploateringen blev möjlig eftersom locker-kontraktet fortfarande hade en aktiv ägarnyckel som kunde ändra kritiska parametrar.

Detta innebar att ”låst” likviditet inte strikt upprätthölls av immutabel kod utan istället styrdes av justerbara kontraktsinställningar.