Recientemente, un proyecto llamado aBNBc sufrió un ataque de Hacker, resultando en la emisión ilegal de una gran cantidad de Token. Según el monitoreo de datos on-chain, el Hacker emitió una gran cantidad de Token aBNBc y convirtió parte de ellos en BNB, mientras que el resto quedó en la Billetera. Este incidente llevó al agotamiento del fondo de liquidez del Token aBNBc, provocando una caída significativa en el precio de la moneda, mientras que el atacante también utilizó los Token emitidos para préstamos colateralizados, causando pérdidas a la plataforma de préstamos.
Tras analizar varios datos de transacciones, se encontró que múltiples direcciones diferentes activaron la emisión de nuevos Token. Una investigación adicional reveló que el proyecto realizó una actualización del contrato antes de ser atacado, pero la función de emisión en el contrato lógico actualizado carecía de las necesarias comprobaciones de permisos.
El atacante llamó a una función específica en el contrato lógico a través de un contrato proxy, y debido a que esta función no realizó una verificación de permisos, se produjo una emisión ilegal de tokens aBNBc. Después del incidente, el equipo del proyecto actualizó nuevamente el contrato lógico y agregó un mecanismo de verificación de permisos a la función de emisión.
Actualmente, el Hacker ha intercambiado una parte del aBNBc emitido adicionalmente por BNB y lo ha transferido, pero una gran cantidad de aBNBc todavía permanece en la Billetera del atacante.
La causa principal de este incidente es que durante la actualización del contrato, la función de emisión en el nuevo contrato lógico carecía de verificación de permisos. Actualmente, no está claro si se utilizó código de contrato no auditado y probado de manera segura, o si la filtración de claves privadas permitió que un Hacker actualizara el contrato por su cuenta.
Este evento recuerda una vez más a los usuarios y a los proyectos que deben gestionar adecuadamente las claves privadas y las frases de recuperación de sus billeteras, evitando almacenarlas de manera descuidada. Al realizar actualizaciones de contratos, es imprescindible llevar a cabo pruebas de seguridad exhaustivas para prevenir riesgos similares.
Esta página puede contener contenido de terceros, que se proporciona únicamente con fines informativos (sin garantías ni declaraciones) y no debe considerarse como un respaldo por parte de Gate a las opiniones expresadas ni como asesoramiento financiero o profesional. Consulte el Descargo de responsabilidad para obtener más detalles.
16 me gusta
Recompensa
16
2
Republicar
Compartir
Comentar
0/400
ZKProofster
· 08-11 17:12
técnicamente hablando, implementación de seguridad de nivel amateur... smh
El proyecto aBNBc fue atacado por un Hacker, lo que llevó a la emisión ilegal de Tokens y a la sequía de Liquidez.
Recientemente, un proyecto llamado aBNBc sufrió un ataque de Hacker, resultando en la emisión ilegal de una gran cantidad de Token. Según el monitoreo de datos on-chain, el Hacker emitió una gran cantidad de Token aBNBc y convirtió parte de ellos en BNB, mientras que el resto quedó en la Billetera. Este incidente llevó al agotamiento del fondo de liquidez del Token aBNBc, provocando una caída significativa en el precio de la moneda, mientras que el atacante también utilizó los Token emitidos para préstamos colateralizados, causando pérdidas a la plataforma de préstamos.
Tras analizar varios datos de transacciones, se encontró que múltiples direcciones diferentes activaron la emisión de nuevos Token. Una investigación adicional reveló que el proyecto realizó una actualización del contrato antes de ser atacado, pero la función de emisión en el contrato lógico actualizado carecía de las necesarias comprobaciones de permisos.
El atacante llamó a una función específica en el contrato lógico a través de un contrato proxy, y debido a que esta función no realizó una verificación de permisos, se produjo una emisión ilegal de tokens aBNBc. Después del incidente, el equipo del proyecto actualizó nuevamente el contrato lógico y agregó un mecanismo de verificación de permisos a la función de emisión.
Actualmente, el Hacker ha intercambiado una parte del aBNBc emitido adicionalmente por BNB y lo ha transferido, pero una gran cantidad de aBNBc todavía permanece en la Billetera del atacante.
La causa principal de este incidente es que durante la actualización del contrato, la función de emisión en el nuevo contrato lógico carecía de verificación de permisos. Actualmente, no está claro si se utilizó código de contrato no auditado y probado de manera segura, o si la filtración de claves privadas permitió que un Hacker actualizara el contrato por su cuenta.
Este evento recuerda una vez más a los usuarios y a los proyectos que deben gestionar adecuadamente las claves privadas y las frases de recuperación de sus billeteras, evitando almacenarlas de manera descuidada. Al realizar actualizaciones de contratos, es imprescindible llevar a cabo pruebas de seguridad exhaustivas para prevenir riesgos similares.