GMX sufrió una intrusión de un Hacker, causando pérdidas de más de 40 millones de dólares. Los atacantes aprovecharon una vulnerabilidad de reentrada y establecieron posiciones en corto para llevar a cabo el ataque en el caso de que el contrato habilitara la función de apalancamiento.
El núcleo del problema radica en el uso incorrecto de la función executeDecreaseOrder. El primer parámetro de esta función debería ser una cuenta externa (EOA), pero el atacante pasó una dirección de contrato inteligente. Esto permitió al atacante volver a ingresar al sistema durante el proceso de redención, manipular el estado interno y, en última instancia, redimir activos que superan con creces el valor real de GLP que poseía.
En GMX, GLP es un token de proveedor de liquidez que representa una participación en los activos de la tesorería (como USDC, ETH, WBTC). Normalmente, cuando un usuario canjea GLP, el sistema calculará la cantidad de activos a devolver en función de la proporción de GLP que posee el usuario y el total de activos gestionados en ese momento (AUM). El cálculo de AUM incluye el valor total de todos los pools de tokens, las pérdidas y ganancias no realizadas de las posiciones en corto globales, los montos reservados y las deducciones preestablecidas, entre otros factores.
Sin embargo, cuando se habilitó la función de apalancamiento, el sistema presentó una vulnerabilidad. El atacante abrió una gran posición en WBTC posiciones en corto antes de canjear GLP. Dado que la apertura de posiciones en corto aumentó la escala global de posiciones en corto, y sin que el precio hubiera cambiado, el sistema asumió por defecto que dicha posición en corto estaba en pérdidas. Esta parte de las pérdidas no realizadas se contabilizó erróneamente como "activos" del tesorería, lo que llevó a un aumento artificial del AUM. A pesar de que el tesorería no había obtenido valor adicional, el cálculo del canje se basó en este AUM inflado, lo que permitió al atacante obtener activos muy por encima de lo que le correspondía.
Este ataque expuso las graves fallas de GMX en el diseño de mecanismos de apalancamiento y protección contra reentradas. El problema central radica en que la lógica de redención de activos confía demasiado en el AUM, sin realizar suficientes verificaciones de seguridad prudentes sobre sus componentes (como las pérdidas no realizadas). Al mismo tiempo, la suposición de la identidad del llamador en las funciones clave (EOA vs contrato) también carece de una validación obligatoria.
Este evento recuerda nuevamente a los desarrolladores que, al involucrar operaciones sensibles al capital, deben asegurarse de que el estado del sistema no pueda ser manipulado. Especialmente al introducir lógicas financieras complejas (como el apalancamiento y los derivados), se debe tener un especial cuidado para prevenir los riesgos sistémicos que pueden surgir de la reentrada y la contaminación del estado. El equipo de desarrollo debería revisar su diseño de contratos, fortalecer las medidas de seguridad y considerar la introducción de mecanismos de verificación de identidad y chequeo de estado más estrictos para prevenir que ataques similares ocurran nuevamente.
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.
GMX fue atacado por un Hacker, una vulnerabilidad de reentrada causó pérdidas de 40 millones de dólares.
GMX sufrió una intrusión de un Hacker, causando pérdidas de más de 40 millones de dólares. Los atacantes aprovecharon una vulnerabilidad de reentrada y establecieron posiciones en corto para llevar a cabo el ataque en el caso de que el contrato habilitara la función de apalancamiento.
El núcleo del problema radica en el uso incorrecto de la función executeDecreaseOrder. El primer parámetro de esta función debería ser una cuenta externa (EOA), pero el atacante pasó una dirección de contrato inteligente. Esto permitió al atacante volver a ingresar al sistema durante el proceso de redención, manipular el estado interno y, en última instancia, redimir activos que superan con creces el valor real de GLP que poseía.
En GMX, GLP es un token de proveedor de liquidez que representa una participación en los activos de la tesorería (como USDC, ETH, WBTC). Normalmente, cuando un usuario canjea GLP, el sistema calculará la cantidad de activos a devolver en función de la proporción de GLP que posee el usuario y el total de activos gestionados en ese momento (AUM). El cálculo de AUM incluye el valor total de todos los pools de tokens, las pérdidas y ganancias no realizadas de las posiciones en corto globales, los montos reservados y las deducciones preestablecidas, entre otros factores.
Sin embargo, cuando se habilitó la función de apalancamiento, el sistema presentó una vulnerabilidad. El atacante abrió una gran posición en WBTC posiciones en corto antes de canjear GLP. Dado que la apertura de posiciones en corto aumentó la escala global de posiciones en corto, y sin que el precio hubiera cambiado, el sistema asumió por defecto que dicha posición en corto estaba en pérdidas. Esta parte de las pérdidas no realizadas se contabilizó erróneamente como "activos" del tesorería, lo que llevó a un aumento artificial del AUM. A pesar de que el tesorería no había obtenido valor adicional, el cálculo del canje se basó en este AUM inflado, lo que permitió al atacante obtener activos muy por encima de lo que le correspondía.
Este ataque expuso las graves fallas de GMX en el diseño de mecanismos de apalancamiento y protección contra reentradas. El problema central radica en que la lógica de redención de activos confía demasiado en el AUM, sin realizar suficientes verificaciones de seguridad prudentes sobre sus componentes (como las pérdidas no realizadas). Al mismo tiempo, la suposición de la identidad del llamador en las funciones clave (EOA vs contrato) también carece de una validación obligatoria.
Este evento recuerda nuevamente a los desarrolladores que, al involucrar operaciones sensibles al capital, deben asegurarse de que el estado del sistema no pueda ser manipulado. Especialmente al introducir lógicas financieras complejas (como el apalancamiento y los derivados), se debe tener un especial cuidado para prevenir los riesgos sistémicos que pueden surgir de la reentrada y la contaminación del estado. El equipo de desarrollo debería revisar su diseño de contratos, fortalecer las medidas de seguridad y considerar la introducción de mecanismos de verificación de identidad y chequeo de estado más estrictos para prevenir que ataques similares ocurran nuevamente.