El 2 de diciembre, un laboratorio descubrió a través de datos on-chain que el proyecto aBNBc había sufrido un ataque de Hacker, resultando en una gran emisión de Tokens. El Hacker logró emitir una gran cantidad de Tokens aBNBc, parte de los cuales fueron intercambiados por BNB en una plataforma de intercambio descentralizada, y parte se quedó en la Billetera. Además, el Hacker utilizó herramientas de mezcla para realizar transferencias de fondos. Este incidente de ataque provocó la agotamiento del fondo de liquidez del Token aBNBc, el precio de la moneda cayó drásticamente, mientras que el atacante utilizó los Tokens emitidos para préstamos colaterales, causando pérdidas a la plataforma de préstamos.
Después de analizar múltiples datos de transacciones, se descubrió que, aunque las direcciones de los llamadores son diferentes, todas causaron la emisión adicional de tokens. El proyecto había realizado una actualización del contrato antes de sufrir el ataque, y la función de emisión adicional en el contrato lógico actualizado carecía de verificación de permisos.
El atacante llamó a una función específica en el contrato lógico a través de un contrato de proxy, y dado que esta función no realizó una verificación de permisos, se emitieron en gran cantidad los tokens aBNBc. Después de sufrir el ataque, el equipo del proyecto actualizó nuevamente el contrato lógico, y en la nueva versión se añadió un mecanismo de verificación de permisos a la función de emisión.
Actualmente, los hackers han intercambiado una parte de aBNBc emitido adicionalmente por BNB y lo han transferido, mientras que una gran cantidad de aBNBc restante aún permanece en la billetera del atacante.
El ataque de esta vez se originó principalmente en la actualización del contrato, donde la función de emisión adicional en el nuevo contrato lógico carecía de verificación de permisos, lo que permitió a los hackers emitir tokens sin restricciones. Actualmente, no está claro si se utilizó código de contrato no auditado y no probado, o si la filtración de claves privadas permitió a los hackers actualizar el contrato por su cuenta.
Este evento recuerda a los usuarios y a los proyectos que deben cuidar adecuadamente las claves privadas y las frases semilla de sus Billeteras, evitando almacenarlas de manera descuidada. Al mismo tiempo, 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.
19 me gusta
Recompensa
19
5
Republicar
Compartir
Comentar
0/400
OldLeekMaster
· hace7h
¿Los tontos han sido tomados por tontos otra vez?
Ver originalesResponder0
NFTArtisanHQ
· 08-14 19:27
otro proyecto defi cae víctima de la estética de un mal diseño de contrato inteligente... la verdad es que es bastante poético
Ver originalesResponder0
ZenZKPlayer
· 08-14 19:22
Otro proyecto ha fallado...
Ver originalesResponder0
DancingCandles
· 08-14 19:14
¿No se hizo la verificación de permisos otra vez?
Ver originalesResponder0
OffchainWinner
· 08-14 19:12
Otro proyecto arruinado por una actualización, tsk tsk.
aBNBc fue atacado por un Hacker, la vulnerabilidad en la función de emisión provocó una Gran caída del Token.
El 2 de diciembre, un laboratorio descubrió a través de datos on-chain que el proyecto aBNBc había sufrido un ataque de Hacker, resultando en una gran emisión de Tokens. El Hacker logró emitir una gran cantidad de Tokens aBNBc, parte de los cuales fueron intercambiados por BNB en una plataforma de intercambio descentralizada, y parte se quedó en la Billetera. Además, el Hacker utilizó herramientas de mezcla para realizar transferencias de fondos. Este incidente de ataque provocó la agotamiento del fondo de liquidez del Token aBNBc, el precio de la moneda cayó drásticamente, mientras que el atacante utilizó los Tokens emitidos para préstamos colaterales, causando pérdidas a la plataforma de préstamos.
Después de analizar múltiples datos de transacciones, se descubrió que, aunque las direcciones de los llamadores son diferentes, todas causaron la emisión adicional de tokens. El proyecto había realizado una actualización del contrato antes de sufrir el ataque, y la función de emisión adicional en el contrato lógico actualizado carecía de verificación de permisos.
El atacante llamó a una función específica en el contrato lógico a través de un contrato de proxy, y dado que esta función no realizó una verificación de permisos, se emitieron en gran cantidad los tokens aBNBc. Después de sufrir el ataque, el equipo del proyecto actualizó nuevamente el contrato lógico, y en la nueva versión se añadió un mecanismo de verificación de permisos a la función de emisión.
Actualmente, los hackers han intercambiado una parte de aBNBc emitido adicionalmente por BNB y lo han transferido, mientras que una gran cantidad de aBNBc restante aún permanece en la billetera del atacante.
El ataque de esta vez se originó principalmente en la actualización del contrato, donde la función de emisión adicional en el nuevo contrato lógico carecía de verificación de permisos, lo que permitió a los hackers emitir tokens sin restricciones. Actualmente, no está claro si se utilizó código de contrato no auditado y no probado, o si la filtración de claves privadas permitió a los hackers actualizar el contrato por su cuenta.
Este evento recuerda a los usuarios y a los proyectos que deben cuidar adecuadamente las claves privadas y las frases semilla de sus Billeteras, evitando almacenarlas de manera descuidada. Al mismo tiempo, al realizar actualizaciones de contratos, es imprescindible llevar a cabo pruebas de seguridad exhaustivas para prevenir riesgos similares.