La red PolyNetwork ha sido hackeada y se han robado más de 300 millones de dólares. El atacante realizó el ataque en múltiples cadenas. En este blog, utilizamos la transacción del ataque en Ethereum (0xd8c1f7424593ddba11a0e072b61082bf3d931583cb75f7843fc2a8685d20033a) para analizar la posible razón del hackeo. Nuestro análisis inicial muestra que una posible razón podría ser la filtración de la clave privada utilizada para firmar el mensaje entre cadenas, o bien existe un error en el proceso de firma de PolyNetwork que ha sido explotado para firmar un mensaje manipulado.
Descargo de responsabilidad: Este blog solo contiene los resultados de nuestro análisis inicial basado en los datos en cadena de Ethereum. No podemos verificar nuestros hallazgos sin información adicional de Poly Network.
Actualización 2021/08/12: La información adicional muestra que la causa del ataque se debe a que el keeper fue modificado por el atacante (no por la filtración de la clave privada). Tenemos un análisis más detallado para responder por qué la transacción para cambiar el keeper puede ejecutarse en primer lugar.
Transacción y traza de llamadas
Utilizamos nuestro sistema de análisis de transacciones para recuperar la traza.
Atacante -> EthCrossChainManager -> EthCrossChainData -> LockProxy -> managerProxyContractforLockProxy
- 0xc8a65fadf0e0ddaf421f28feab69bf6e2e589963: Atacante
- 0x838bf9e95cb12dd76a54c9f9d2e3082eaf928270: EthCrossChainManager
- 0xcf2afe102057ba5c16f899271045a0a37fcb10f2: EthCrossChainData
- 0x250e76987d838a75310c34bf422ea9f1ac4cc906: LockProxy
- 0x5a51e2ebf8d136926b9ca7b59b60464e7c44d2eb: managerProxyContract para LockProxy
Firmas de funciones:
- d450e04c (verifyHeaderAndExecuteTx)
- 69d48074 (getCurEpochConPubKeyBytes)
- 5ac40790 (getCurEpochStartHeight)
- 0586763c (checkIfFromChainTxExist)
- e90bfdcf (markFromChainTxExist(uint64,bytes32))
El proceso principal del ataque
El proceso principal del ataque consiste en que el atacante pasó los datos firmados a la función verifyHeaderAndExecuteTx(). Esta función decodificará los datos y verificará las firmas utilizadas para firmar los datos. Si este proceso es exitoso, el método (y la dirección del contrato) especificado en el mensaje será ejecutado. Durante este ataque, se invoca la función unlock del contrato inteligente 0x250e76987d838a75310c34bf422ea9f1ac4cc906 para transferir el Fei al atacante.
En resumen, el ataque se debe a los parámetros válidos pasados a la función verifyHeaderAndExecuteTx. Y los parámetros pueden superar el proceso de verificación de firmas. Después de eso, la transacción especificada en el mensaje será ejecutada (como la ejecución de comandos arbitrarios en seguridad de software).
Para comprender mejor este proceso, recuperamos los valores críticos de la traza de llamadas.
Función: verifyHeaderAndExecuteTx:
verifySig
unlock
La variable managerProxyContract en el LockProxy. Coincide con el valor de la dirección del llamante de la función unlock.
Conclusión
A partir de los valores recuperados, encontramos que:
- El atacante proporciona un mensaje firmado válido a la función verifyHeaderAndExecuteTx
- El modificador
onlyManagerContracten el contrato inteligente LockProxy NO es eludido.
Basándonos en estas dos observaciones, sospechamos que:
- El atacante puede tener las claves legítimas para firmar los mensajes, lo que indica que las claves de firma pueden haber sido filtradas.
O
- Existe un error en el proceso de firma de PolyNetwork que ha sido explotado para firmar un mensaje manipulado.
Sin embargo, no contamos con datos adicionales fuera de la cadena para verificar nuestros hallazgos. Esperamos que nuestro análisis sea útil para una investigación más profunda.
Créditos: Yufeng Hu, Siwei Wu, Lei Wu, Yajin Zhou @BlockSec
Twitter: https://twitter.com/BlockSecTeam
