DxSale perd $7.3M dans le piratage des LPs sur BNB Chain

DxSale, une plateforme historique de lancement de tokens et de verrouillage de liquidité largement utilisée lors du premier boom des memecoins sur BNB Chain, a subi une importante faille qui a drainé environ $7.3 million de fonds de fournisseurs de liquidité (LP).

L'incident a affecté plus de 1,400 pools de liquidité, selon le suivi on-chain publié après les faits.

Les pools étaient répartis sur plusieurs projets de tokens anciens, dont beaucoup n'avaient pas connu de développement actif ni d'activité de trading depuis des années, mais détenaient toujours de la liquidité verrouillée dans des contrats DxSale.

Notamment, l'exploit ne semblait pas cibler un seul token ou projet. Il a plutôt impacté une couche d'infrastructure partagée utilisée par des centaines de déploiements, amplifiant l'ampleur des pertes.

Comment l'attaque contre les LPs de BNB Chain s'est déroulée

L'analyse on-chain et les comptes rendus d'enquête de Tahax suggèrent que l'exploit n'a pas été soudain.

Il s'est plutôt déroulé via une série de modifications administratives contrôlées intervenues des mois avant le drain effectif.

Environ 269 jours avant l'incident, le déployeur DxSale aurait transféré la propriété d'un contrat de verrouillage clé vers un nouveau portefeuille. La transition n'a pas été annoncée publiquement et aucun avis de migration n'a été émis aux utilisateurs ou aux équipes de tokens dépendant du système.

Au fil du temps, le contrôle de la propriété n'est pas resté fixe. Les droits d'administration auraient été déplacés via environ 80 transferts de portefeuilles distincts, chacun conçu pour obscurcir la trace des changements de garde.

Ces mouvements ont réduit la visibilité sur l'identité de celui qui contrôlait finalement le système de verrouillage tout en conservant les privilèges administratifs.

Deux jours avant le début de l'exploit, la propriété a été consolidée dans un seul portefeuille :

0xC4574DDEF299e7E563971e200433e592EeaaFA69

Le portefeuille avait été nouvellement créé et aurait été financé via Bybit, avec une activité de routage liée à des infrastructures de pont cross-chain souvent utilisées pour masquer l'origine des fonds.

En l'espace de quelques heures après cette consolidation, des activités de vidage de liquidités ont commencé sur des centaines de pools de tokens.

Exécution technique du siphonnage

Une analyse détaillée des analystes sécurité on-chain de Coinsult décrit le mécanisme utilisé pour extraire des fonds du système de lockers DxSale.

Le contrat attaquant, déployé peu avant l'incident, n'était pas vérifié et avait été construit en Solidity 0.8.33. Il fonctionnait comme un seul orchestrateur, permettant l'exécution de plusieurs actions dans une seule transaction via une logique d'auto-appel.

La séquence d'exécution visait la mécanique interne du contrat de verrouillage.

Premièrement, l'attaquant a déclenché une fonction qui a réduit les frais de verrouillage à 1 wei, supprimant de fait les barrières de coût pour modifier les positions verrouillées.

Ensuite, une deuxième action a fixé le timestamp d'expiration du verrou à 68 secondes après l'époque Unix, réinitialisant de fait le verrou à un moment qui ne protégeait plus la liquidité déposée.

Après cela, le paramètre de frais a été porté à une valeur extrêmement élevée, environ 1e29, qui semble avoir été utilisée pour perturber le comportement d'interaction normal du contrat lors de l'exécution.

Une fois l'état interne modifié, l'attaquant a lancé des appels de retrait répétés qui ont permis d'extraire des tokens du locker.

Ces fonds ont ensuite été convertis en WBNB et BNB avant d'être acheminés par plusieurs routes pour obscurcir la piste des transactions.

La structure du contrat faisait que, une fois les paramètres administratifs modifiés, le statut « locked » de la liquidité ne reflétait plus de réelles restrictions de retrait.

Pourquoi le système de verrouillage des LP est devenu une cible

DxSale était largement utilisé pendant le boom des memecoins de 2021 sur BNB Chain comme outil par défaut de verrouillage de liquidité.

De nombreux lancements de tokens l'utilisaient pour démontrer la sécurité aux premiers investisseurs en verrouillant les tokens de pool de liquidité pour des périodes prolongées.

Cependant, le modèle de sécurité du système reposait fortement sur le contrôle administratif plutôt que sur une logique de contrat entièrement immuable.

Selon l'analyse, des fonctions telles que les ajustements de frais et la configuration des verrous restaient accessibles via des rôles de propriété privilégiés.

Les analystes en sécurité ont noté que l'exploit a été rendu possible parce que le contrat de locker disposait toujours d'une clé propriétaire active capable de modifier des paramètres critiques.

Cela signifiait que la liquidité « locked » n'était pas strictement appliquée par un code immuable mais régie par des paramètres de contrat ajustables.