fondo
Blast es una red Ethereum Layer 2 lanzada por Pacman (Tieshun Roquerre, también conocido como Tieshun), el fundador de Blur. Lanzó la red principal el 29 de febrero. Actualmente, aproximadamente 19,500 ETH y 640,000 stETH están comprometidos en la red principal de Blast.
El proyecto atacado Munchables es un proyecto de alta calidad que ganó el concurso Bigbang organizado por Blast.
Los funcionarios de Blast emitirán puntos ordinarios a los usuarios que prometan ETH en la red principal de Blast:
Para alentar a los usuarios a participar en proyectos DeFi en el ecosistema Blast, los funcionarios de Blast seleccionarán proyectos de alta calidad para recomendarlos y alentarán a los usuarios a comprometer ETH por segunda vez en DeFi para obtener un aumento de puntos y puntos de oro más rápido, por lo que hay bastante Pocos usuarios prometieron el ETH prometido en la red principal de Blast al proyecto DeFi recién creado.
Aún no se ha examinado la madurez y la seguridad de estos proyectos DeFi, y si estos contratos tienen suficientes consideraciones de seguridad para salvaguardar decenas de millones o incluso cientos de millones de dólares de los usuarios.
Resumen del evento
Menos de un mes después de que la red principal de Blast estuviera en línea, se produjo un ataque al SSS Token (Super Sushi Samurai) el 21 de marzo de 2024. Hubo un error de lógica de transferencia en el contrato del Token, lo que permitió al atacante aumentar el SSS Token del En última instancia, el proyecto perdió más de 1.310 ETH (aproximadamente 4,6 millones de dólares).
Menos de una semana después del ataque al token SSS, se produjo otro ataque más grande en Blast: el proyecto Munchables fue barrido por atacantes con 17413,96 ETH, un total de aproximadamente 62,5 millones de dólares estadounidenses.
Media hora después de que se produjera la transacción del ataque, un pirata informático también robó 73,49 WETH del contrato del proyecto desde otra dirección.
En este momento, todavía hay 7276 WETH, 7758267 USDB y 4 ETH almacenados en la dirección del contrato de la parte del proyecto, que caerán en manos de los piratas informáticos en cualquier momento. El pirata informático tiene la autoridad para quitar todos los fondos de todo el proyecto, por un total aproximado de 97 millones de dólares americanos, expuesto al riesgo.
Inmediatamente después del incidente, el conocido detective en cadena de X (Twitter), zachXBT, señaló que la causa fundamental de este ataque fue la contratación de piratas informáticos de un determinado país.
Echemos un vistazo más de cerca a cómo un “hacker de cierto país” completó un ataque por valor de casi 100 millones de dólares.
Restauración in situ
Las víctimas hablan
[UTC+ 0 ] A las 21:37 del 26 de marzo de 2024 (5 minutos después del ataque), Munchables publicó oficialmente en X (Twitter) indicando que estaba bajo ataque.
Según la investigación del detective en cadena Zach, el atacante vino a hacer un trabajo de desarrollo de juegos. Era muy rudo y realmente parecía un hacker chino. Lo despedimos al mes. También intentó que contratáramos a uno de sus amigos, que probablemente también era un hacker.
Dado que este ataque causó enormes pérdidas a los usuarios de la comunidad, inmediatamente iniciamos una investigación en la cadena. Echemos un vistazo en profundidad a los detalles del ataque de este “hacker de un determinado país”.
Primera escena
[UTC+ 0] A las 21:32 del 26 de marzo de 2024, se produjo un ataque que involucró 17413,96 ETH.
A través de Blastscan podemos ver esta transacción de ataque:
El contrato dañado (0x 29…1 F) es un contrato proxy que almacena los fondos comprometidos del usuario. Podemos ver que el atacante llamó a la función de desbloqueo del contrato de compromiso, pasó todas las comprobaciones de permiso y lo transfirió. Todo ETH en el contrato va a la dirección 1 del atacante (0x 6 E…c 5).
Parece que el atacante invocó una función de desbloqueo con un comportamiento similar al de un retiro y quitó la mayor parte del ETH del contrato comprometido (0x 29…1 F).
¿El grupo del proyecto se olvidó de cerrar la bóveda?
Hay dos comprobaciones relacionadas para desbloquear el contrato dañado (0x 29…1 F), veámoslas una por una.
Primero, descubrimos que durante el proceso de verificación de permisos, se llamó al método isRegistered del contrato (0x 16…A 0) para verificar si el msg.sender actual, es decir, la dirección del hacker 1 (0x 6 E…c 5) Ya registrado:
La respuesta es: pasó la verificación.
Esto involucra el contrato (0x 16…A 0) y su último contrato lógico correspondiente (0x e 7…f 1)
[UTC+ 0] A las 08:39 del 24 de marzo de 2024 (2 días antes del ataque), se actualizó el contrato lógico correspondiente al contrato (0x 16…A 0).
Transacción de actualización de contrato lógico:
El contrato lógico se actualiza a 0x e 7…f 1.
La dirección del contrato lógico original se puede ver aquí, que es 0x 9 e…CD.
En este momento, sospechamos que el hacker actualizó el contrato de implementación lógica del contrato de agente, que será 0x 9 e… CD se vuelve malicioso 0x e 7…f 1 , completando la omisión de los permisos de verificación.
¿Es realmente?
En Web3.0, nunca necesita adivinar ni escuchar a los demás, solo necesita dominar la tecnología para obtener la respuesta usted mismo.
Al comparar los dos contratos (no los contratos de código abierto), existen algunas diferencias obvias entre el contrato 0x 9 e…CD original y el 0x e 7…f 1 actualizado:
La parte de la función de inicialización de 0x e 7…f 1 se implementa de la siguiente manera:
La parte de la función de inicialización de 0x 9 e…CD se implementa de la siguiente manera:
Se puede ver que el atacante configuró la dirección del atacante (0x 6 e…c 5) como registro en el contrato lógico original (0x 9 e…CD), y también hay otras dos direcciones del atacante 0x c 5 …0 d, 0x bf…87 también están registrados y su campo 0 se establece en el tiempo de bloqueo durante la inicialización. El uso del campo 0 se explicará más adelante.
De hecho, contrariamente a lo que suponíamos, el contrato lógico real con puerta trasera existió desde el principio, ¡y las actualizaciones posteriores fueron normales!
Espera, esta actualización apareció a las 08:39 del 24 de marzo de 2024 [UTC+ 0] (2 días antes del ataque). Es decir, antes de este incidente, el contrato lógico se había convertido en un contrato sin puertas traseras. ¿Por qué? El atacante aún puede completar ¿el ataque?
Esto se debe a la llamada delegada, por lo que la actualización del almacenamiento del estado real está en el contrato (0x 16…A 0), lo que resulta en el hecho de que incluso si el contrato lógico se actualiza posteriormente al contrato lógico sin puerta trasera 0x e 7… f 1, la ranura modificada en el contrato (0x 16…A 0) aún no se restaurará.
Comprobémoslo:
Como puede ver, el espacio correspondiente en el contrato (0x 16…A 0) tiene un valor numérico.
Esto permite que un atacante pase la verificación del método isRegistered:
Posteriormente, el atacante cambia el contrato de puerta trasera a un contrato normal para ocultar el hecho de que la puerta trasera ya ha sido colocada.
Además, el proceso de desbloqueo también implica una segunda verificación:
Con respecto a la verificación del tiempo de bloqueo, esta parte es para garantizar que los activos bloqueados no se transfieran antes de su vencimiento.
El atacante debe asegurarse de que el tiempo de bloqueo cuando se solicita el desbloqueo sea mayor que el tiempo de vencimiento del bloqueo requerido (campo 3).
Esta parte de la verificación involucra el contrato dañado (0x 29…1 F) y el contrato lógico correspondiente 0x f 5…cd.
En una transacción a las 11:54 del 21 de marzo de 2024 [UTC+ 0] (5 días antes del ataque),
Podemos ver que el contrato lógico original del contrato dañado (0x 29…1 F) era 0x 91…11, y solo cuatro minutos después, en
Actualizado a 0x f 5…cd.
También comparamos los dos contratos y podemos encontrar que el atacante también hizo trucos en la función de inicialización como antes.
Implementación parcial de la función de inicialización de 0x f 5…cd:
Implementación parcial de la función de inicialización de 0x 91…11:
Se puede ver que es obvio que se utilizó nuevamente el mismo método para alterar la cantidad de ETH y el tiempo de desbloqueo, y luego se reemplazó con el contrato normal para engañar a otros. Cuando el equipo del proyecto y los investigadores de seguridad estaban depurando, todos los contratos lógicos vistos son normales y, debido a que todos los contratos son contratos de código no abierto, es aún más difícil ver claramente el núcleo del problema.
Hasta ahora, entendemos esta transacción que involucra 17413 ETH y cómo la hizo el atacante, pero ¿hay sólo esta cantidad de información detrás de este incidente?
En nuestro análisis anterior, vimos que el hacker incorporó 3 direcciones en el contrato:
0x 6 e…c 5 (dirección del atacante 1)
0x c 5…0 d (dirección del atacante 2)
0x bf…87 (dirección del atacante 3)
Sin embargo, en la transacción de ataque que encontramos arriba solo vimos 0x 6 e…c 5. ¿Qué hicieron las otras dos direcciones? ¿Y qué secretos se esconden en la dirección (0), _dodoApproveAddress, _uniswapV3Factorty?
Segunda escena
Primero echemos un vistazo a la dirección 3 del atacante (0x bf…87), que robó 73,49 WETH mediante el mismo método:
Y ataque la dirección de origen del gas (0x 97…de) y proporcione tarifas de manejo tanto a 0x c 5…0 d (dirección del atacante 2) como a 0x bf…87 (dirección del atacante 3).
La fuente del 0.1 ETH que ataca la dirección de la fuente de gas (0x 97…de) proviene de owlto.finance (puente entre cadenas).
0x c 5…0 d (dirección del atacante 2) no llevó a cabo ningún ataque después de recibir la tarifa de manejo, pero en realidad cargó con un plan oculto.Continuemos analizándolo.
De hecho, según la transacción de rescate oficial, la dirección original del contrato dañado (0x 29…1 F) no era solo 73,49 WETH: hasta el final del ataque, todavía había 7276,5 WETH y 7758267 USDB.
Acuerdo de rescate:
El atacante originalmente planeó robar estos activos. Puede ver que la dirección 0x c 5…0 d (dirección del atacante 2) se usó originalmente para robar USDB.
La _dodoApproveAddress aquí es 0x000000000000000000000000000000043000000000000000000000000000000000000003
es la dirección de usdb
0x bf…87 (dirección del atacante 3) Esta dirección se utiliza para robar:
La fábrica _uniswap V3 aquí es 0x000000000000000000000000000000004300000000000000000000000000000000000004
es la dirección de wet
Y 0x 6 e…c 5 (dirección del atacante 1) es responsable de robar la dirección (0), que es el activo nativo ETH.
Al establecer el campo 0, el atacante puede robar los activos correspondientes mediante la siguiente lógica:
pregunta
¿Por qué el atacante no robó todos los activos?
En teoría, puede robar todos los activos, es decir, el resto de WETH y USDB.
0x bf…87 (dirección del atacante 3) solo robó 73.49 WETH. 0x bf…87 (dirección del atacante 3) en realidad puede quitar todos los 7350 WETH, o puedes usar 0x c 5…0 d (dirección del atacante 2) tomó lejos todos los 7758267 USDB. ¿Por qué se detuvo después de tomar solo un poco de WETH? No lo sabemos. Es posible que sea necesario que un conocido detective de la cadena lleve a cabo una investigación interna en profundidad.
¿Por qué el atacante no transfirió 17413 ETH a la red principal de Ethereum?
Como todos sabemos, es posible que la red principal de Blast intercepte estos ETH a través de un método centralizado y los deje permanecer aquí permanentemente sin causar pérdidas sustanciales a los usuarios. Sin embargo, una vez que estos ETH ingresan a la red principal de Ethereum, no hay forma de interceptarlos. él.
Evaluamos los puentes entre cadenas actuales de Blast. No hay límite en el número de puentes entre cadenas oficiales, pero se necesitan 14 días para salir, lo que es suficiente para que los funcionarios de Blast preparen un plan de interceptación.
El puente de cadena cruzada de terceros se puede acreditar casi en tiempo real, al igual que la fuente de tarifas del atacante, y puede completar rápidamente la cadena cruzada. ¿Por qué el atacante no cruzó la cadena de inmediato?
De hecho, el atacante realizó una cadena cruzada en el primer momento (a los 2 minutos del ataque):
Además, los fondos tardaron 20 segundos en llegar a la red principal de Ethereum. En teoría, un atacante puede continuar cruzando cadenas y transfiriendo una gran cantidad de ETH entre cadenas antes de que el puente entre cadenas pueda intervenir manualmente.
En cuanto a por qué solo pueden ser 3 ETH a la vez, el motivo es el límite de liquidez del puente entre cadenas, de Blast a ETH:
Otro puente de cadenas cruzadas que soporta Blast soporta aún menos:
Después de esta transacción entre cadenas, el atacante no continuó con otras operaciones entre cadenas. El motivo lo desconocemos. Parece que el “hacker de cierto país” no hizo los preparativos adecuados para retirar fondos de Blast.
Desarrollo de los acontecimientos tras el ataque.
Según los comentarios del usuario de la comunidad Nearisbuilding, encontró más información de identidad del atacante y encontró formas de solicitarle que devuelva los fondos.
Al final, con la atención y los esfuerzos de la comunidad de cifrado, el “hacker de cierto país”, tal vez porque tenía miedo de exponer su identidad, proporcionó las claves privadas de las tres direcciones de atacante anteriores al grupo del proyecto y las devolvió todas. fondos. La parte del proyecto también llevó a cabo una transacción de rescate: transferir todos los fondos del contrato dañado al contrato de firmas múltiples para su custodia.
