El proyecto aBNBc sufre un ataque de Hacker, la masiva emisión de Token provoca una Gran caída del precio
Recientemente, una agencia de monitoreo de datos descubrió que el proyecto aBNBc había sido atacado por un hacker, resultando en una emisión masiva de tokens. El hacker emitió una gran cantidad de tokens aBNBc a través de una vulnerabilidad, de los cuales una parte ya se ha cambiado por BNB en un intercambio descentralizado, mientras que otra parte permanece en la billetera del hacker. Además, el hacker también utilizó herramientas de transferencia anónima para mover fondos. Este ataque ha llevado a la agotamiento del fondo de liquidez del token aBNBc, lo que ha provocado una gran caída en el precio de la moneda. Más grave aún, el atacante también utilizó los tokens aBNBc emitidos para préstamos colaterales, causando pérdidas a la plataforma de préstamos.
A través del análisis de múltiples datos de transacciones, los investigadores descubrieron que las direcciones que llamaban a la función de emisión adicional eran diferentes, pero todas conducían a la emisión adicional de tokens. Una investigación más profunda mostró que el proyecto había realizado una actualización de contrato antes de sufrir el ataque, y la función de emisión adicional en el contrato lógico actualizado carecía de las necesarias verificaciones de permisos.
Después del ataque, el equipo del proyecto actualizó nuevamente el contrato lógico, añadiendo un mecanismo de verificación de permisos a la función de emisión adicional en la nueva versión. Sin embargo, esta medida llegó demasiado tarde para recuperar las pérdidas ya causadas.
Sobre el flujo de fondos, se sabe que un hacker ha intercambiado parte del aBNBc recién emitido por BNB y lo ha transferido, mientras que una gran cantidad del aBNBc restante aún se encuentra en la billetera controlada por el hacker.
La causa fundamental de este incidente de ataque radica en la negligencia durante la actualización del contrato. La función de emisión adicional en el contrato lógico carecía de una verificación de permisos, lo que brindó una oportunidad al Hacker. Actualmente, no está claro si esto se debe al uso de código de contrato no auditado y no probado por seguridad, o si fue causado por la filtración de la clave privada que permitió al Hacker actualizar el contrato por sí mismo.
De todos modos, este evento recuerda nuevamente a los usuarios y a los proyectos que deben cuidar adecuadamente las claves privadas y las frases de recuperación de sus billeteras, y no deben almacenarlas de manera descuidada. Al mismo tiempo, al realizar actualizaciones de contratos, es imprescindible llevar a cabo pruebas de seguridad exhaustivas para prevenir posibles vulnerabilidades y riesgos.
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.
14 me gusta
Recompensa
14
5
Republicar
Compartir
Comentar
0/400
BrokenDAO
· 08-16 22:32
Otro ejemplo de actualización de contrato sin verificación de permisos.
Ver originalesResponder0
SigmaBrain
· 08-16 22:30
Otra vez los hackers han tomado a la gente por tonta, trampa trampa trampa
Ver originalesResponder0
ShamedApeSeller
· 08-16 22:28
Otra vez se han utilizado cupones de clip en contratos inteligentes.
Ver originalesResponder0
LayerZeroEnjoyer
· 08-16 22:26
La vulnerabilidad de día cero ser liquidado, ¿quién se atreve a actualizar el contrato a la ligera?
Ver originalesResponder0
GasOptimizer
· 08-16 22:11
¿No se verifican los permisos después de la actualización del contrato? Un truco que cualquier Novato entiende.
aBNBc fue atacado por hackers, la emisión masiva de tokens causó una gran caída en el precio.
El proyecto aBNBc sufre un ataque de Hacker, la masiva emisión de Token provoca una Gran caída del precio
Recientemente, una agencia de monitoreo de datos descubrió que el proyecto aBNBc había sido atacado por un hacker, resultando en una emisión masiva de tokens. El hacker emitió una gran cantidad de tokens aBNBc a través de una vulnerabilidad, de los cuales una parte ya se ha cambiado por BNB en un intercambio descentralizado, mientras que otra parte permanece en la billetera del hacker. Además, el hacker también utilizó herramientas de transferencia anónima para mover fondos. Este ataque ha llevado a la agotamiento del fondo de liquidez del token aBNBc, lo que ha provocado una gran caída en el precio de la moneda. Más grave aún, el atacante también utilizó los tokens aBNBc emitidos para préstamos colaterales, causando pérdidas a la plataforma de préstamos.
A través del análisis de múltiples datos de transacciones, los investigadores descubrieron que las direcciones que llamaban a la función de emisión adicional eran diferentes, pero todas conducían a la emisión adicional de tokens. Una investigación más profunda mostró que el proyecto había realizado una actualización de contrato antes de sufrir el ataque, y la función de emisión adicional en el contrato lógico actualizado carecía de las necesarias verificaciones de permisos.
Después del ataque, el equipo del proyecto actualizó nuevamente el contrato lógico, añadiendo un mecanismo de verificación de permisos a la función de emisión adicional en la nueva versión. Sin embargo, esta medida llegó demasiado tarde para recuperar las pérdidas ya causadas.
Sobre el flujo de fondos, se sabe que un hacker ha intercambiado parte del aBNBc recién emitido por BNB y lo ha transferido, mientras que una gran cantidad del aBNBc restante aún se encuentra en la billetera controlada por el hacker.
La causa fundamental de este incidente de ataque radica en la negligencia durante la actualización del contrato. La función de emisión adicional en el contrato lógico carecía de una verificación de permisos, lo que brindó una oportunidad al Hacker. Actualmente, no está claro si esto se debe al uso de código de contrato no auditado y no probado por seguridad, o si fue causado por la filtración de la clave privada que permitió al Hacker actualizar el contrato por sí mismo.
De todos modos, este evento recuerda nuevamente a los usuarios y a los proyectos que deben cuidar adecuadamente las claves privadas y las frases de recuperación de sus billeteras, y no deben almacenarlas de manera descuidada. Al mismo tiempo, al realizar actualizaciones de contratos, es imprescindible llevar a cabo pruebas de seguridad exhaustivas para prevenir posibles vulnerabilidades y riesgos.