Análisis del incidente de ataque de Hacker a Poly Network
Recientemente, el protocolo de interoperabilidad entre cadenas Poly Network sufrió un ataque de un Hacker, lo que ha generado una amplia atención en la industria. Según el análisis del equipo de seguridad, este ataque no fue causado por la filtración de la clave privada del keeper, sino que el atacante, a través de datos cuidadosamente elaborados, modificó con éxito la dirección del keeper del contrato EthCrossChainData.
Detalles del ataque
El núcleo del ataque radica en que la función verifyHeaderAndExecuteTx del contrato EthCrossChainManager puede ejecutar transacciones específicas entre cadenas a través de la función _executeCrossChainTx.
La propiedad del contrato EthCrossChainData pertenece al contrato EthCrossChainManager, lo que permite a este último llamar a la función putCurEpochConPubKeyBytes para cambiar el keeper.
El atacante aprovecha las características de la función verifyHeaderAndExecuteTx, ingresando datos diseñados cuidadosamente, para que la función _executeCrossChainTx llame a la función putCurEpochConPubKeyBytes del contrato EthCrossChainData, cambiando así el rol de keeper a la dirección especificada por el atacante.
Una vez completada la sustitución del rol de keeper, el atacante podrá construir transacciones libremente y extraer cualquier cantidad de fondos del contrato.
Proceso de ataque
El atacante primero llama a la función putCurEpochConPubKeyBytes a través de la función verifyHeaderAndExecuteTx del contrato EthCrossChainManager, cambiando con éxito al keeper.
A continuación, el atacante comenzó a llevar a cabo una serie de transacciones de ataque para extraer fondos del contrato.
Debido a que el keeper fue modificado, las transacciones normales de otros usuarios fueron rechazadas.
Este modo de ataque no solo ocurre en la cadena BSC, sino que también se han observado operaciones similares en la red de Ethereum.
Conclusión
La causa fundamental de este ataque radica en que el keeper del contrato EthCrossChainData puede ser modificado por el contrato EthCrossChainManager, y la función verifyHeaderAndExecuteTx de este último puede ejecutar los datos proporcionados por el usuario. Los atacantes aprovecharon esta vulnerabilidad de diseño y, mediante datos cuidadosamente construidos, lograron cambiar la dirección del keeper del contrato EthCrossChainData, lo que permitió el robo de fondos. Este incidente nos recuerda una vez más que en el diseño de contratos inteligentes, la gestión de permisos y la seguridad en las llamadas a funciones son cruciales.
Ver originales
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
6
Republicar
Compartir
Comentar
0/400
RetailTherapist
· hace2h
Otro que ha sido atacado ha caído.
Ver originalesResponder0
StableGeniusDegen
· hace2h
Otro frío~
Ver originalesResponder0
NotSatoshi
· hace2h
Otra vez los hackers están haciendo de las suyas.
Ver originalesResponder0
ShibaSunglasses
· hace2h
¿Otra vez es un juego de ganarse entre ellos?
Ver originalesResponder0
SorryRugPulled
· hace2h
¿Otro Rug Pull? Ya estoy acostumbrado.
Ver originalesResponder0
RektButSmiling
· hace2h
¿Ha ocurrido otro problema? ¿Keeper ya no es seguro?
Poly Network fue atacado por un Hacker: el keeper del contrato EthCrossChainData fue alterado
Análisis del incidente de ataque de Hacker a Poly Network
Recientemente, el protocolo de interoperabilidad entre cadenas Poly Network sufrió un ataque de un Hacker, lo que ha generado una amplia atención en la industria. Según el análisis del equipo de seguridad, este ataque no fue causado por la filtración de la clave privada del keeper, sino que el atacante, a través de datos cuidadosamente elaborados, modificó con éxito la dirección del keeper del contrato EthCrossChainData.
Detalles del ataque
El núcleo del ataque radica en que la función verifyHeaderAndExecuteTx del contrato EthCrossChainManager puede ejecutar transacciones específicas entre cadenas a través de la función _executeCrossChainTx.
La propiedad del contrato EthCrossChainData pertenece al contrato EthCrossChainManager, lo que permite a este último llamar a la función putCurEpochConPubKeyBytes para cambiar el keeper.
El atacante aprovecha las características de la función verifyHeaderAndExecuteTx, ingresando datos diseñados cuidadosamente, para que la función _executeCrossChainTx llame a la función putCurEpochConPubKeyBytes del contrato EthCrossChainData, cambiando así el rol de keeper a la dirección especificada por el atacante.
Una vez completada la sustitución del rol de keeper, el atacante podrá construir transacciones libremente y extraer cualquier cantidad de fondos del contrato.
Proceso de ataque
El atacante primero llama a la función putCurEpochConPubKeyBytes a través de la función verifyHeaderAndExecuteTx del contrato EthCrossChainManager, cambiando con éxito al keeper.
A continuación, el atacante comenzó a llevar a cabo una serie de transacciones de ataque para extraer fondos del contrato.
Debido a que el keeper fue modificado, las transacciones normales de otros usuarios fueron rechazadas.
Este modo de ataque no solo ocurre en la cadena BSC, sino que también se han observado operaciones similares en la red de Ethereum.
Conclusión
La causa fundamental de este ataque radica en que el keeper del contrato EthCrossChainData puede ser modificado por el contrato EthCrossChainManager, y la función verifyHeaderAndExecuteTx de este último puede ejecutar los datos proporcionados por el usuario. Los atacantes aprovecharon esta vulnerabilidad de diseño y, mediante datos cuidadosamente construidos, lograron cambiar la dirección del keeper del contrato EthCrossChainData, lo que permitió el robo de fondos. Este incidente nos recuerda una vez más que en el diseño de contratos inteligentes, la gestión de permisos y la seguridad en las llamadas a funciones son cruciales.