DxSale mister $7.3M i hack af BNB Chain LP'er

DxSale, en veletableret platform til tokenlanceringer og likviditetslåsning, som var bredt brugt under den tidlige BNB Chain memecoin-bølge, har været udsat for en større udnyttelse, der drænede anslået $7.3 million i likviditetsudbyder (LP)-midler.

Hændelsen ramte mere end 1,400 likviditetspools, ifølge on-chain-sporing delt efter hændelsen.

Poolsene var spredt på tværs af flere ældre tokenprojekter, hvoraf mange ikke havde set aktiv udvikling eller handelsaktivitet i årevis, men alligevel havde låst likviditet i DxSale-kontrakterne.

Bemærkelsesværdigt nok syntes udnyttelsen ikke at have haft et enkelt token eller projekt som mål. I stedet ramte den et delt infrastrukturlag, der blev brugt af hundredvis af deploymenter, hvilket forstørrede tabenes omfang.

Hvordan angrebet mod BNB Chain LP'erne skete

On-chain-analyse og efterforskeres gennemgange fra Tahax antyder, at udnyttelsen ikke var pludselig.

I stedet udfoldede den sig gennem en række kontrollerede administrative ændringer, der fandt sted måneder før det faktiske dræn.

Cirka 269 dage før hændelsen overførte DxSale-deployeren angiveligt ejerskabet af en central locker-kontrakt til en ny wallet. Overgangen blev ikke offentliggjort, og der blev ikke udsendt nogen migrationsmeddelelse til brugere eller tokenteams, der var afhængige af systemet.

Over tid forblev ejerskabskontrollen ikke statisk. Administrationsrettighederne blev angiveligt flyttet gennem cirka 80 separate wallet-overførsler, hver designet til at sløre sporene af custody-ændringer.

Disse bevægelser reducerede gennemsigtigheden i, hvem der i sidste ende kontrollerede lockersystemet, samtidig med at administrative privilegier blev bevaret.

To dage før udnyttelsen begyndte, blev ejerskabet konsolideret i én wallet:

0xC4574DDEF299e7E563971e200433e592EeaaFA69

Walleten var nyskabt og blev angiveligt finansieret via Bybit, med routing-aktivitet knyttet gennem cross-chain bridge-infrastruktur, som ofte bruges til at sløre oprindelsen af midler.

Inden for få timer efter denne konsolidering begyndte likviditetsdrænende aktivitet på tværs af hundreder af tokenpools.

Teknisk eksekvering af drænet

En detaljeret gennemgang fra on-chain-sikkerhedsanalytikere hos Coinsult beskrev den mekanisme, der blev brugt til at trække midler ud af DxSale-locker-systemet.

Den angribende kontrakt, udrullet kort før hændelsen, var uverificeret og bygget med Solidity 0.8.33. Den fungerede som en enkelt orkestrator, der tillod flere handlinger at blive udført i én transaktion via selvkaldende logik.

Eksekveringssekvensen målrettede de interne mekanismer i locker-kontrakten.

Først udløste angriberen en funktion, der reducerede låsegebyret til 1 wei, hvilket effektivt fjernede omkostningsbarrierer for at modificere låste positioner.

Derefter fulgte en handling, der satte låsens udløbstidsstempel til 68 sekunder efter Unix-epoken, hvilket reelt nulstillede låsen til et tidspunkt, der ikke længere beskyttede de deponerede midler.

Efter dette blev gebyrparameteren sat til en ekstremt høj værdi, cirka 1e29, hvilket ser ud til at være blevet brugt til at forstyrre normal kontraktinteraktionsadfærd under eksekveringen.

Da den interne tilstand var ændret, initierede angriberen gentagne udbetalingskald, som tillod tokens at blive trukket fra locker'en.

Disse midler blev derefter konverteret til WBNB og BNB, før de blev flyttet gennem flere ruter for at sløre transaktionssporet.

Kontraktens struktur betød, at når administrative parametre var ændret, afspejlede den "låste" status for likviditet ikke længere reelle begrænsninger på udbetalinger.

Hvorfor LP-lockersystemet blev et mål

DxSale var bredt anvendt under memecoin-boomet i 2021 på BNB Chain som et standardværktøj til likviditetslåsning.

Mange tokenlanceringer stolede på det for at vise sikkerhed over for tidlige investorer ved at låse likviditetspool-tokens i længere perioder.

Systemets sikkerhedsmodel var dog i høj grad afhængig af administrativ kontrol frem for fuldt uforanderlig kontraktlogik.

Ifølge analysen forblev funktioner som gebyrjusteringer og låsekonfiguration tilgængelige via privilegerede ejerskabsroller.

Sikkerhedsanalytikere bemærkede, at udnyttelsen blev mulig, fordi locker-kontrakten stadig havde en aktiv ejer-nøgle, der kunne ændre kritiske parametre.

Det betød, at "låst" likviditet ikke var håndhævet strengt af uforanderlig kode, men i stedet blev styret af justerbare kontraktindstillinger.