Más de 40 millones de dólares robados, la historia del ataque preciso a GMX

Original | Odaily Odaily日报（@OdailyChina）

Autor | Asher（**@Asher_ 0210 ）

Anoche, la plataforma GMX, un protocolo DeFi líder en la cadena, sufrió un importante incidente de seguridad, con más de 40 millones de dólares en activos criptográficos robados por hackers, involucrando varios tokens principales como WBTC, WETH, UNI, FRAX, LINK, USDC, USDT. Después del incidente, Bithumb emitió un anuncio anunciando que los servicios de depósito y retiro de GMX se suspenderán hasta que la red esté estable.

Debido a este incidente de robo, el token GMX ha caído más del 25% en 4 horas, alcanzando un precio que llegó a caer por debajo de 11 dólares, actualmente se reporta a 11.8 dólares. Según los datos de DefiLlama, el TVL de GMX ha bajado de 500 millones de dólares antes del incidente de robo a 400 millones de dólares, con una caída temporal de hasta el 20%.

La TVL de la plataforma GMX se vio afectada por el incidente de robo, cayendo temporalmente a 400 millones de dólares.

A continuación, el diario Odaily de la estrella organiza las razones de este incidente de robo de GMX, la respuesta del equipo y los últimos movimientos del hacker.

Los atacantes aprovechan la vulnerabilidad de reentrancia

La raíz del incidente de robo de GMX radica en una vulnerabilidad de reentrada en la función central executeDecreaseOrder. El primer parámetro de esta función debería ser una cuenta externa (EOA), pero el atacante ingresó una dirección de contrato inteligente, lo que permitió al atacante reingresar al sistema durante el proceso de redención, manipulando el estado interno, y finalmente, los activos redimidos superaron con creces el valor real de GLP que poseía.

El socio y Director de Seguridad de la Información de Slow Mist, 23pds, declaró en la plataforma X que en la versión V1 de GMX, el establecimiento de posiciones cortas actualizará inmediatamente el precio promedio global de cortos (globalShortAveragePrices), y este precio afecta directamente el cálculo del total de activos gestionados (AUM), lo que a su vez impacta la valoración y el monto de rescate del token GLP.

Los atacantes aprovecharon el diseño de GMX que habilitó la función timelock.enableLeverage durante la ejecución de órdenes (lo que es un prerrequisito para abrir posiciones cortas grandes), y activaron la vulnerabilidad de reentrada del contrato al invocar la función executeDecreaseOrder. Aprovechando esta vulnerabilidad, los atacantes crearon repetidamente posiciones cortas, elevando artificialmente el precio promedio global de las posiciones cortas sin cambiar realmente el precio del mercado.

Debido a que el AUM depende de este precio para su cálculo, la plataforma incluyó erróneamente las pérdidas infladas de los cortos en el total de activos, lo que resultó en una sobrevaloración del GLP. Posteriormente, el atacante canjeó el GLP y extrajo activos que superaban con creces su parte correspondiente, logrando así enormes beneficios.

Ejemplo de transacción de ataque: line= 93

Respuesta oficial de GMX: El pool de liquidez GLP de la versión V1 de GMX en Arbitrum fue atacado por un exploit, la versión V2 de GMX no se vio afectada.

En respuesta a este importante incidente de seguridad, el equipo de GMX ha emitido una declaración oficial de inmediato. En una publicación en la plataforma X, indicaron que el fondo GLP de GMX V1 en la plataforma Arbitrum sufrió un ataque de vulnerabilidad, y aproximadamente 40 millones de dólares en tokens han sido transferidos desde el fondo GLP a una billetera desconocida. Un socio de seguridad ha participado en la investigación de este incidente de ataque.

Actualmente, las plataformas Arbitrum y Avalanche han deshabilitado el comercio de la versión GMX V1, así como las funciones de acuñación y canje de GLP, para prevenir cualquier ataque adicional, pero esta vulnerabilidad no afecta a la versión GMX V2 ni a los tokens GMX en sí.

Debido a que la versión V1 de GMX ha sido atacada, los usuarios pueden reducir el riesgo mediante las siguientes acciones:

• Desactivar la función de apalancamiento: se puede llamar a Vault.setIsLeverageEnabled (false) para desactivarla; si se utiliza Vault Timelock, se debe llamar a Timelock.setShouldToggleIsLeverageEnabled (false).
• Establecer maxUsdgAmounts de todos los tokens en “1”: usar Vault.setTokenConfig o Timelock.setTokenConfig para evitar que GLP se acuñen más. Es importante señalar que este valor debe establecerse en “1”, y no en “0”, ya que establecerlo en 0 indica que no hay límite, lo que a su vez podría permitir que la vulnerabilidad siga siendo explotable.

Según la última actualización, la oficina ha confirmado que el ataque solo estaba dirigido a la versión GMX V1, mientras que el contrato de la versión GMX V2 no utiliza el mismo mecanismo de cálculo. Sin embargo, por cuestiones de precaución, GMX ha actualizado el límite de tokens de la versión GMX V2 en Arbitrum y Avalanche, por lo que la acuñación de nuevos tokens en la mayoría de los pools de liquidez está actualmente restringida. Se notificará de inmediato una vez que se levante esta restricción.

Además, los datos en la cadena muestran que GMX ha dejado un mensaje en la dirección del hacker indicando que reconoce haber sufrido una vulnerabilidad en la versión GMX Vl y está dispuesto a ofrecer un 10% de recompensa a los hackers éticos. Si el 90% restante de los fondos es devuelto en 48 horas, se comprometen a no tomar más acciones legales.

GMX ha dejado un mensaje en la dirección del hacker ofreciendo un 10% de recompensa de hacker ético.

Hackers han transferido más de 30 millones de dólares a una nueva dirección

Según las señales en la cadena, esta es una acción premeditada; los fondos iniciales del hacker se transfirieron hace unos días desde el protocolo de mezcla de monedas privadas Tornado Cash, lo que indica que ya habían preparado este ataque.

Después de robar más de 40 millones de dólares en activos criptográficos, los hackers rápidamente transfirieron más de 30 millones de dólares en activos. Según los datos en la cadena, la dirección marcada del hacker de GMX (dirección: 88 BTC (valor aproximado de 9.8 millones de dólares), más de 2200 ETH (valor aproximado de 5.85 millones de dólares), más de 3 millones de USDC, más de 1.3 millones de DAI se transfirieron a la nueva dirección 0x99cdeb84064c2bc63de0cea7c6978e272d0f2dae; más de 4300 ETH (valor aproximado de 11 millones de dólares) se transfirieron a la nueva dirección 0x6acc60b11217a1fd0e68b0ecaee7122d34a784c1. En total, se han transferido más de 30 millones de dólares a otras nuevas direcciones.

Los hackers robaron activos por más de 40 millones de dólares.

La dirección del hacker aún tiene 10 millones de dólares en fondos que no se han transferido.

“El detective de la cadena” ZachXBT publicó en la plataforma X criticando la inacción de Circle ante el comportamiento de los hackers. Él mencionó que el ataque a GMX ocurrió hace entre 1 y 2 horas, pero Circle no ha tomado ninguna medida contra los hackers. Los atacantes incluso utilizaron el protocolo de transferencia entre cadenas de Circle, CCTP, para mover los fondos robados de Arbitrum a Ethereum.

Resumen

Este incidente de robo no solo revela las fallas clave en la verificación de permisos de los llamadores, la secuencia de actualización de estado y el diseño del mecanismo de apalancamiento en la versión V1 de GMX, sino que también vuelve a sonar la alarma para toda la industria: en sistemas que involucran lógica financiera compleja (como apalancamiento, precios dinámicos) y rutas de ejecución de contratos entrelazadas, cualquier entrada no protegida podría convertirse en el punto de partida de un evento de cisne negro.

Es importante notar que los hackers han convertido la mayor parte de los activos robados en criptomonedas más difíciles de congelar, especialmente en activos descentralizados como ETH y DAI, y han completado la dispersión de fondos a través de múltiples nuevas direcciones, lo que ha aumentado aún más la dificultad de rastrear y recuperar. Además, la propuesta de GMX de “10% de recompensa para hackers éticos a cambio de inmunidad” también expone la realidad de la falta de un mecanismo unificado de responsabilidad legal en el mundo de Web3.

Para los desarrolladores de DeFi, quizás la pregunta más importante a considerar no sea “¿Cómo lograron los hackers entrar?”, sino más bien: cuando el sistema gestiona los activos reales de los usuarios, ¿se han establecido suficientes mecanismos para limitar la ocurrencia de las rutas de ataque más extremas? De lo contrario, incluso la lógica de producto más perfecta, si carece de un diseño de límites de seguridad, inevitablemente enfrentará el costo del riesgo sistémico.