DxSale pierde $7.3M tras hackeo a proveedores de liquidez (LP) en BNB Chain

DxSale, una plataforma con larga trayectoria para el lanzamiento de tokens y el bloqueo de liquidez, ampliamente utilizada durante el auge temprano de memecoins en BNB Chain, ha sufrido una explotación importante que drenó un estimado de $7.3 millones en fondos de proveedores de liquidez (LP).

El incidente afectó a más de 1.400 piscinas de liquidez, según el seguimiento on-chain compartido tras el suceso.

Las piscinas estaban repartidas entre múltiples proyectos de tokens más antiguos, muchos de los cuales no habían tenido desarrollo activo ni actividad de negociación en años, pero aún mantenían liquidez bloqueada dentro de los contratos de DxSale.

Es notable que la explotación no pareció dirigirse a un único token o proyecto. En cambio, impactó una capa de infraestructura compartida utilizada por cientos de despliegues, amplificando la escala de las pérdidas.

Análisis on-chain y desgloses de investigadores de Tahax sugieren que la explotación no fue repentina.

En lugar de eso, se desarrolló mediante una serie de cambios administrativos controlados que ocurrieron meses antes del drenado real.

Aproximadamente 269 días antes del incidente, el desplegador de DxSale supuestamente transfirió la propiedad de un contrato locker clave a una nueva cartera. La transición no fue anunciada públicamente y no se emitió ningún aviso de migración a los usuarios ni a los equipos de tokens que dependían del sistema.

Con el tiempo, el control de la propiedad no permaneció estático. Los derechos de administrador fueron, según se informa, trasladados a través de aproximadamente 80 transferencias de carteras separadas, cada una diseñada para oscurecer la pista de cambios de custodia.

Estos movimientos redujeron la visibilidad sobre quién controlaba finalmente el sistema de locker, al tiempo que mantenían intactos los privilegios administrativos.

Dos días antes de que comenzara la explotación, la propiedad se consolidó en una única cartera:

0xC4574DDEF299e7E563971e200433e592EeaaFA69

La cartera era recién creada y, según se informa, fue financiada a través de Bybit, con actividad de enrutamiento vinculada a infraestructura de puentes cross-chain frecuentemente usada para ocultar el origen de los fondos.

A las pocas horas de esta consolidación, comenzó la actividad de drenaje de liquidez en cientos de piscinas de tokens.

Un desglose detallado de analistas de seguridad on-chain de Coinsult describió el mecanismo utilizado para extraer fondos del sistema de locker de DxSale.

El contrato atacante, desplegado poco antes del incidente, no estaba verificado y fue construido con Solidity 0.8.33. Funcionaba como un único orquestador, permitiendo que múltiples acciones se ejecutaran en una sola transacción mediante lógica de auto-invocación.

La secuencia de ejecución apuntó a la mecánica interna del contrato locker.

Primero, el atacante activó una función que redujo la tarifa de bloqueo a 1 wei, eliminando efectivamente las barreras de coste para modificar las posiciones bloqueadas.

A esto le siguió una segunda acción que fijó la marca temporal de expiración del bloqueo a 68 segundos después de la época Unix, restableciendo efectivamente el bloqueo a un momento que ya no protegía la liquidez depositada.

Después de esto, el parámetro de tarifa se elevó a un valor extremadamente alto, aproximadamente 1e29, que parece haber sido usado para alterar el comportamiento normal de interacción con el contrato durante la ejecución.

Una vez modificado el estado interno, el atacante inició llamadas de retirada repetidas que permitieron extraer tokens del locker.

Estos fondos fueron luego convertidos en WBNB y BNB antes de ser movidos por múltiples rutas para ocultar la pista de transacciones.

La estructura del contrato implicaba que, una vez cambiados los parámetros administrativos, el estado “bloqueado” de la liquidez ya no reflejaba restricciones reales de retirada.

DxSale fue ampliamente utilizado durante el auge de memecoins de 2021 en BNB Chain como herramienta por defecto para el bloqueo de liquidez.

Muchos lanzamientos de tokens dependieron de él para demostrar seguridad a los inversores iniciales bloqueando tokens de los pools de liquidez por períodos prolongados.

Sin embargo, el modelo de seguridad del sistema dependía en gran medida del control administrativo en lugar de una lógica de contrato totalmente inmutable.

Según el análisis, funciones como el ajuste de tarifas y la configuración de bloqueos seguían siendo accesibles a través de roles privilegiados de propiedad.

Los analistas de seguridad señalaron que la explotación fue posible porque el contrato locker aún tenía una clave de propietario activa capaz de modificar parámetros críticos.

Esto significaba que la liquidez “bloqueada” no estaba estrictamente aplicada por código inmutable, sino gobernada por ajustes de contrato susceptibles de modificarse.