aBNBc sufrió un ataque de Hacker, la negligencia en la actualización del contrato provocó una emisión ilegal de una gran cantidad de Token.

El 2 de diciembre, un laboratorio descubrió a través de datos on-chain que el proyecto aBNBc había sido víctima de un ataque de hackers, lo que resultó en la emisión ilegal de una gran cantidad de tokens aBNBc. Los hackers intercambiaron parte de los tokens emitidos ilegalmente por BNB en un DEX, mientras que otra parte se mantuvo en una billetera. Además, los atacantes también utilizaron estos tokens emitidos ilegalmente para préstamos colaterales, causando pérdidas a la plataforma de préstamos. Este evento provocó una grave falta de liquidez para el token aBNBc, y su precio cayó drásticamente.

A través del análisis de múltiples datos de transacciones, los investigadores descubrieron que aunque las direcciones de llamada eran diferentes, todas llevaron a la emisión adicional de Token. Una investigación más profunda mostró que el proyecto había realizado una actualización de contrato antes de sufrir el ataque, y que la función de emisión adicional en el contrato lógico actualizado carecía de las revisiones de permisos necesarias.

El Hacker llamó a una función específica en el contrato lógico a través de un contrato proxy. Debido a que esta función no realizó la verificación de permisos, logró implementar la emisión ilegal de tokens aBNBc.

Después de sufrir un ataque, el equipo del proyecto actualizó inmediatamente el contrato lógico, añadiendo un mecanismo de verificación de permisos a la función de emisión en la nueva versión.

En términos de flujo de fondos, el Hacker ya ha intercambiado una parte del aBNBc emitido adicionalmente por BNB y lo ha transferido, pero una gran cantidad de aBNBc todavía permanece en su Billetera.

En general, este ataque se originó principalmente por una negligencia en el proceso de actualización del contrato, es decir, la función de emisión en el nuevo contrato lógico carecía de la detección de permisos necesaria. Actualmente, no está claro si esto se debió al uso de código de contrato no auditado y no probado en términos de seguridad, o si fue debido a la filtración de claves privadas que permitió a los hackers actualizar el contrato por su cuenta. De cualquier manera, este evento vuelve a enfatizar la importancia de mantener adecuadamente las claves privadas y las frases de recuperación de la billetera, así como la necesidad de realizar pruebas de seguridad exhaustivas al actualizar contratos.