DxSale perde $7.3M in hack che svuota LP su BNB Chain

DxSale, una piattaforma storica per il lancio di token e il blocco della liquidità, ampiamente usata durante il primo boom dei memecoin su BNB Chain, ha subito un grave exploit che ha prosciugato circa $7.3 million dai fondi dei fornitori di liquidità (LP).

L'incidente ha colpito più di 1,400 pool di liquidità, secondo il tracciamento on-chain condiviso dopo l'accaduto.

I pool erano distribuiti su diversi progetti token più vecchi, molti dei quali non registravano sviluppo attivo o attività di trading da anni ma mantenevano ancora liquidità bloccata all'interno dei contratti DxSale.

Degno di nota, l'exploit non sembrava prendere di mira un singolo token o progetto. Ha invece interessato uno strato d'infrastruttura condiviso utilizzato da centinaia di deployment, amplificando l'entità delle perdite.

Come è avvenuto l'attacco agli LP su BNB Chain

Analisi on-chain e ricostruzioni degli investigatori di Tahax suggeriscono che l'exploit non sia stato improvviso.

Si è invece sviluppato tramite una serie di modifiche amministrative controllate avvenute mesi prima del reale prosciugamento.

Circa 269 days prima dell'incidente, il deployer di DxSale avrebbe trasferito la proprietà di un contratto locker chiave a un nuovo wallet. La transizione non è stata annunciata pubblicamente e non è stato emesso alcun avviso di migrazione agli utenti o ai team dei token che si appoggiavano al sistema.

I diritti di amministrazione sarebbero stati spostati attraverso circa 80 trasferimenti separati di wallet, ciascuno progettato per offuscare la traccia dei cambi di custodia.

Questi spostamenti hanno ridotto la visibilità su chi controllasse in ultima istanza il sistema di locker, pur mantenendo intatti i privilegi amministrativi.

Due giorni prima dell'inizio dell'exploit, la proprietà è stata consolidata in un unico wallet:

0xC4574DDEF299e7E563971e200433e592EeaaFA69

Il wallet era di nuova creazione e sarebbe stato finanziato tramite Bybit, con attività di instradamento collegate a infrastrutture di bridge cross-chain spesso utilizzate per offuscare l'origine dei fondi.

Entro poche ore da questo consolidamento, è iniziata un'attività di prosciugamento della liquidità su centinaia di pool di token.

Esecuzione tecnica del prosciugamento

Una ricostruzione dettagliata degli analisti di sicurezza on-chain di Coinsult ha descritto il meccanismo usato per estrarre fondi dal sistema di locker di DxSale.

Il contratto attaccante, distribuito poco prima dell'incidente, non era verificato ed era stato scritto usando Solidity 0.8.33. Funzionava come un unico orchestratore, permettendo l'esecuzione di più azioni all'interno di una singola transazione tramite logica di auto-invocazione.

La sequenza di esecuzione ha preso di mira la meccanica interna del contratto locker.

Per prima cosa, l'attaccante ha attivato una funzione che ha ridotto la commissione di locking a 1 wei, eliminando di fatto le barriere di costo per modificare le posizioni bloccate.

Questo è stato seguito da una seconda azione che ha impostato il timestamp di scadenza del lock a 68 secondi dopo l'epoca Unix, resettando di fatto il lock a un momento che non proteggeva più la liquidità depositata.

Dopo questo, il parametro della fee è stato alzato a un valore estremamente elevato, circa 1e29, che sembra essere stato usato per disturbare il normale comportamento di interazione con il contratto durante l'esecuzione.

Una volta modificato lo stato interno, l'attaccante ha iniziato chiamate ripetute di prelievo che hanno permesso di estrarre token dal locker.

Questi fondi sono stati poi convertiti in WBNB e BNB prima di essere trasferiti attraverso più rotte per offuscare la tracciabilità delle transazioni.

La struttura del contratto faceva sì che, una volta modificati i parametri amministrativi, lo stato “locked” della liquidità non rispecchiasse più le effettive restrizioni di prelievo.

Perché il sistema di locker per LP è diventato un bersaglio

DxSale è stato ampiamente usato durante il boom dei memecoin del 2021 su BNB Chain come strumento di default per il locking della liquidità.

Molti lanci di token si sono affidati a esso per dimostrare sicurezza agli investitori iniziali bloccando i token del pool di liquidità per periodi prolungati.

Tuttavia, il modello di sicurezza del sistema dipendeva fortemente dal controllo amministrativo piuttosto che da una logica contrattuale completamente immutabile.

Secondo l'analisi, funzioni come la regolazione delle fee e la configurazione del lock restavano accessibili tramite ruoli di proprietà privilegiati.

Gli analisti di sicurezza hanno osservato che l'exploit è diventato possibile perché il contratto locker aveva ancora una chiave del proprietario attiva in grado di modificare parametri critici.

Ciò significava che la liquidità “locked” non era rigorosamente imposta da codice immutabile ma era governata da impostazioni contrattuali modificabili.