En este blog, queremos revisar todo el proceso del hackeo de Poly Network y analizar las lecciones aprendidas.
Supimos que Poly Network estaba siendo hackeada el 10 de agosto de 2021 (utilizamos la zona horaria +8 en este blog). Sin embargo, no había ninguna pista sobre cómo estaba ocurriendo el hackeo ni cuál era la causa raíz. Como equipo de investigación de seguridad, iniciamos nuestra investigación.
Paso 1: Encontrar la transacción del ataque
Reproducimos la transacción del ataque 0xd8c1f7424593ddba11a0e072b61082bf3d931583cb75f7843fc2a8685d20033a en nuestro sistema de virtualización de transacciones (https://tx.blocksecteam.com).
La traza es bastante simple, lo cual es diferente de otros ataques que manipulan el precio. Estos suelen tener invocaciones de funciones muy complicadas (Ver el hackeo de Popsicle.)
Paso 2: Analizar el código del contrato
Después de obtener la traza del ataque, necesitamos revisar el código fuente del contrato. Sorprendentemente, Poly Network NO tiene código fuente verificado en Etherscan. Sin embargo, logramos encontrar el código fuente publicado en GitHub.
Tras revisar el código fuente, no encontramos ninguna vulnerabilidad de código obvia. También comparamos la traza del ataque con una traza de transacción legítima y encontramos que son similares.
Paso 3: Recuperar los estados críticos
Luego recuperamos los estados críticos durante el ataque. Dado que el ataque se lanza desde la invocación de VerifyHeaderAndExecuteTxEvent, recuperamos varios valores de variables críticas, los cuales compartimos en nuestro primer análisis [1].
Durante este proceso, encontramos que solo hay un keeper (ver la figura anterior). Dado que el valor se obtiene de la traza del ataque y la transacción del ataque ha pasado todas las verificaciones de firma, pensamos que la razón potencial podría ser la filtración de la clave privada o un error en el proceso de firma del servidor [1].
Sin embargo, cometimos un error aquí. Analizar un ataque es como pelar una cebolla. La pelas capa por capa, hasta que localizas la verdadera causa "raíz raíz raíz". En ese momento, no pelamos más la cebolla para ver si el keeper había sido cambiado.
Paso 4: Nueva pista
Unas horas más tarde, Kelvin y slow mist dieron nuevas pistas en Twitter, mostrando que el keeper había sido cambiado. El proceso de cambio abusa de la colisión de hash para invocar una función poderosa — un hackeo muy "inteligente".
Entonces nos dimos cuenta de que nuestro primer análisis no era completo. Basándonos en la información más reciente, reproducimos la transacción que cambió el keeper. La traza sigue siendo muy simple.
Pero recuerda que, durante esta transacción, hay cuatro keepers (en lugar de uno). Todas estas claves son las mismas que en otras transacciones legítimas — lo que significa que las claves son legítimas. Aquí surge la pregunta: ¿por qué la transacción que cambia el keeper puede ser incluida en la cadena y ejecutarse en primer lugar?
Paso 5: Localizar la transacción de origen
Luego intentamos localizar la transacción de origen, ya que Poly Network es un puente entre cadenas. Debería existir una transacción de origen en algún lugar. Lo hicimos decodificando la variable crítica (como se muestra en la siguiente imagen). Muestra el hash de la transacción de la cadena de origen y de la poly chain.
Hay un truco que no ha sido mencionado en ningún otro lugar. El valor del hash de transacción en la variable tiene una representación diferente al valor oficial en la poly chain. Por ejemplo, el hash de transacción de la poly chain en la figura es 0x80cc978479eb082e1e656993c63dee7a5d08a00dc2b2aab88bc0e465cfa0721a. Pero en el explorador de la poly chain, el valor del hash es 1a72a0cf65e4c08bb8aab2c20da0085d7aee3dc69369651e2e08eb798497cc80 (¿ves la diferencia?). Compartimos nuestros hallazgos en el grupo de Telegram EthereumSecurity el 11 de agosto a las 16:55.
Paso 6: Localizar la causa raíz
Pero aún así, no podíamos responder la pregunta "¿por qué la transacción para cambiar el keeper puede ser empaquetada en la cadena?". Para responder esta pregunta, comenzamos desde la cadena Ontology y encontramos el flujo de transacciones:
Transacción Ontology -> Relayer de Ontology -> Poly chain -> Relayer de Ethereum -> Ethereum
Luego leímos el código fuente de la cadena Ontology y los relayers. Después de un par de horas, encontramos que el relayer de Ontology no tiene suficiente validación para la transacción entre cadenas. Esto puede permitir que la transacción maliciosa sea empaquetada en la poly chain. Después de eso, el sistema fue comprometido.
Tras una discusión interna y revisión, publicamos nuestros hallazgos el 12 de agosto a las 02:41 en Twitter y Medium [3].
Lecciones
-
Seguridad por diseño. La seguridad debe estar presente en todo el proceso del proyecto DeFi. Los usuarios confían su dinero al proyecto. A cambio, el proyecto debe merecer esa confianza. Desafortunadamente, vimos la negligencia en materia de seguridad por parte de Poly Network. Por ejemplo, la falta de validación es una vulnerabilidad de seguridad antigua, que yo enseño en clases de pregrado.
-
No existe código fuente verificado para un proyecto DeFi con más de 600M de TVL. La base de la infraestructura descentralizada es la confianza, y el fundamento de esa confianza es la transparencia. Desafortunadamente, los usuarios están dispuestos a poner su dinero en un proyecto de caja negra, lo cual me sorprende y me preocupa. Cómo mejorar el sentido de seguridad del usuario probablemente requiere una nueva solución.
Referencias
[1]https://blocksecteam.medium.com/the-initial-analysis-of-the-polynetwork-hack-270ac6072e2a
[2]https://twitter.com/kelvinfichter/status/1425290462076747777
[3]https://blocksecteam.medium.com/the-further-analysis-of-the-poly-network-attack-6c459199c057
Créditos: Yufeng Hu, Siwei Wu, Lei Wu, Yajin Zhou @ BlockSecTeam
