El 2 de diciembre, según los datos on-chain, un proyecto sufrió un ataque de hacker, lo que provocó una emisión ilegal de grandes cantidades de tokens. El atacante intercambió parte de los tokens emitidos ilegalmente por BNB en un DEX, mientras que el resto se mantuvo en la billetera. Además, el hacker utilizó un servicio de transferencia anónima para mover los fondos. Este incidente causó la agotamiento del fondo de liquidez de dicho token, y el precio de la moneda cayó drásticamente, mientras que el hecho de que el atacante utilizara los tokens emitidos ilegalmente para préstamos colaterales también causó pérdidas a la plataforma de préstamos.
Después de analizar múltiples datos de transacciones, se descubrió que, aunque el llamador utilizó diferentes direcciones, todas causaron la emisión adicional de tokens. Una investigación más profunda mostró que el proyecto realizó una actualización del contrato antes de sufrir el ataque, y que la función de emisión adicional en el nuevo contrato lógico no realizó las necesarias verificaciones de permisos.
El atacante llamó a una función específica en el contrato lógico a través de un contrato intermediario, y debido a la falta de verificación de permisos en esa función, se produjo una emisión ilegal de tokens. Tras el ataque, el equipo del proyecto actualizó rápidamente el contrato lógico, y en la nueva versión se añadió un mecanismo de verificación de permisos para la función de emisión.
Actualmente, los hackers han intercambiado parte de los Tokens emitidos ilegalmente por BNB y los han transferido, pero todavía hay una gran cantidad de Tokens emitidos ilegalmente en su Billetera.
La causa fundamental de este ataque radica en que, durante la actualización del contrato, la función de emisión en el nuevo contrato lógico carecía de la verificación de permisos necesaria. Actualmente no está claro si esto se debe al uso de código de contrato no auditado y no probado en términos de seguridad, o si fue causado por la filtración de claves privadas que permitió a los hackers actualizar el contrato por su cuenta. De todos modos, este evento recuerda una vez más a los usuarios y a los proyectos la importancia de proteger adecuadamente las claves privadas y las frases de recuperación de la billetera, y también enfatiza la necesidad de realizar pruebas de seguridad exhaustivas al llevar a cabo actualizaciones de contratos.
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.
13 me gusta
Recompensa
13
5
Compartir
Comentar
0/400
SchroedingerAirdrop
· hace8h
Otra vez se ha aprovechado de los tontos.
Ver originalesResponder0
GasFeeNightmare
· hace9h
¡Otra vez los contratos inteligentes causando problemas!
Ver originalesResponder0
TokenToaster
· hace9h
Otra vez en el agujero de la detección de permisos, gm
Ver originalesResponder0
Token_Sherpa
· hace9h
clásico caso de elasticidad de oferta que salió mal... otro esquema de ponzinomics se va al traste, para ser honesto
Ver originalesResponder0
CountdownToBroke
· hace9h
Otra vez los tontos han sido tomados por tontos y se han ido.
Un fallo en el contrato de un proyecto provocó una emisión masiva de Tokens, un Hacker hizo efectivo BNB causando una oscilación en el mercado.
El 2 de diciembre, según los datos on-chain, un proyecto sufrió un ataque de hacker, lo que provocó una emisión ilegal de grandes cantidades de tokens. El atacante intercambió parte de los tokens emitidos ilegalmente por BNB en un DEX, mientras que el resto se mantuvo en la billetera. Además, el hacker utilizó un servicio de transferencia anónima para mover los fondos. Este incidente causó la agotamiento del fondo de liquidez de dicho token, y el precio de la moneda cayó drásticamente, mientras que el hecho de que el atacante utilizara los tokens emitidos ilegalmente para préstamos colaterales también causó pérdidas a la plataforma de préstamos.
Después de analizar múltiples datos de transacciones, se descubrió que, aunque el llamador utilizó diferentes direcciones, todas causaron la emisión adicional de tokens. Una investigación más profunda mostró que el proyecto realizó una actualización del contrato antes de sufrir el ataque, y que la función de emisión adicional en el nuevo contrato lógico no realizó las necesarias verificaciones de permisos.
El atacante llamó a una función específica en el contrato lógico a través de un contrato intermediario, y debido a la falta de verificación de permisos en esa función, se produjo una emisión ilegal de tokens. Tras el ataque, el equipo del proyecto actualizó rápidamente el contrato lógico, y en la nueva versión se añadió un mecanismo de verificación de permisos para la función de emisión.
Actualmente, los hackers han intercambiado parte de los Tokens emitidos ilegalmente por BNB y los han transferido, pero todavía hay una gran cantidad de Tokens emitidos ilegalmente en su Billetera.
La causa fundamental de este ataque radica en que, durante la actualización del contrato, la función de emisión en el nuevo contrato lógico carecía de la verificación de permisos necesaria. Actualmente no está claro si esto se debe al uso de código de contrato no auditado y no probado en términos de seguridad, o si fue causado por la filtración de claves privadas que permitió a los hackers actualizar el contrato por su cuenta. De todos modos, este evento recuerda una vez más a los usuarios y a los proyectos la importancia de proteger adecuadamente las claves privadas y las frases de recuperación de la billetera, y también enfatiza la necesidad de realizar pruebas de seguridad exhaustivas al llevar a cabo actualizaciones de contratos.