GMX sufrió un ataque significativo de vulnerabilidad de seguridad, con pérdidas de más de 40 millones de dólares.
Recientemente, la conocida plataforma de intercambio descentralizado GMX sufrió un grave incidente de seguridad, lo que resultó en pérdidas de más de 40 millones de dólares. Los atacantes aprovecharon una vulnerabilidad de reentrada y llevaron a cabo el ataque mediante operaciones en corto en el contexto de la activación de la función de apalancamiento del contrato.
El problema central de este ataque radica en el uso incorrecto de la función executeDecreaseOrder. El primer parámetro de esta función debería ser la dirección de una cuenta externa, pero el atacante ingeniosamente pasó una dirección de un contrato inteligente. Esto permitió al atacante ingresar al sistema repetidamente durante el proceso de redención, manipulando el estado interno y extrayendo activos que superan con creces el valor real de GLP que poseía.
En el funcionamiento normal de GMX, GLP es el token de proveedor de liquidez que representa la participación de los usuarios en los activos del fondo (como USDC, ETH, WBTC). Cuando los usuarios canjean GLP, el sistema calcula la cantidad de activos a devolver en función de la proporción de GLP que poseen y el total de activos bajo gestión (AUM) actual. El cálculo del AUM involucra varios factores, incluidos el valor total de cada grupo de tokens, las ganancias y pérdidas no realizadas de las posiciones cortas globales, entre otros.
Sin embargo, cuando la plataforma habilitó la función de trading con margen, los atacantes encontraron una forma de aprovechar las vulnerabilidades del sistema. Antes de canjear GLP, los atacantes abrieron grandes posiciones cortas en WBTC. Dado que una vez que se abre una posición corta, se aumenta la cantidad total de cortos globales, y sin cambios en el precio, el sistema considera esta parte de los cortos como pérdidas no realizadas. Esta parte de la "pérdida" se contabiliza incorrectamente como "activos" en la tesorería, lo que provoca que el AUM se eleve artificialmente. A pesar de que la tesorería no obtuvo un valor adicional, el cálculo del canje se basa en este AUM inflado, lo que permite a los atacantes obtener activos muy por encima de lo que realmente les corresponde.
Este incidente expuso defectos significativos en el diseño del mecanismo de apalancamiento y la protección contra la reentrada de la plataforma. El problema central radica en la excesiva confianza en la lógica de redención de activos respecto al AUM, al no realizar una verificación de seguridad adecuada sobre sus componentes (como las pérdidas no realizadas). Al mismo tiempo, la suposición sobre la identidad del llamador en funciones clave (si es una cuenta externa o un contrato inteligente) también carece de controles obligatorios.
Este incidente de seguridad recuerda nuevamente a los desarrolladores de proyectos de blockchain que, al involucrar operaciones sensibles de fondos, deben asegurarse de que el estado del sistema no pueda ser manipulado maliciosamente. Especialmente al introducir lógicas financieras complejas (como el comercio con apalancamiento y derivados), se debe tener una estricta prevención contra ataques de reentrada y los riesgos sistémicos que pueden surgir de la contaminación del estado. Para los usuarios, esto también es una advertencia, ya que al participar en proyectos de finanzas descentralizadas se debe ser más cauteloso y prestar atención a la seguridad y la capacidad de gestión de riesgos del proyecto.
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 sufrió un ataque de seguridad de 40 millones de dólares, el diseño del mecanismo de apalancamiento presenta defectos importantes.
GMX sufrió un ataque significativo de vulnerabilidad de seguridad, con pérdidas de más de 40 millones de dólares.
Recientemente, la conocida plataforma de intercambio descentralizado GMX sufrió un grave incidente de seguridad, lo que resultó en pérdidas de más de 40 millones de dólares. Los atacantes aprovecharon una vulnerabilidad de reentrada y llevaron a cabo el ataque mediante operaciones en corto en el contexto de la activación de la función de apalancamiento del contrato.
El problema central de este ataque radica en el uso incorrecto de la función executeDecreaseOrder. El primer parámetro de esta función debería ser la dirección de una cuenta externa, pero el atacante ingeniosamente pasó una dirección de un contrato inteligente. Esto permitió al atacante ingresar al sistema repetidamente durante el proceso de redención, manipulando el estado interno y extrayendo activos que superan con creces el valor real de GLP que poseía.
En el funcionamiento normal de GMX, GLP es el token de proveedor de liquidez que representa la participación de los usuarios en los activos del fondo (como USDC, ETH, WBTC). Cuando los usuarios canjean GLP, el sistema calcula la cantidad de activos a devolver en función de la proporción de GLP que poseen y el total de activos bajo gestión (AUM) actual. El cálculo del AUM involucra varios factores, incluidos el valor total de cada grupo de tokens, las ganancias y pérdidas no realizadas de las posiciones cortas globales, entre otros.
Sin embargo, cuando la plataforma habilitó la función de trading con margen, los atacantes encontraron una forma de aprovechar las vulnerabilidades del sistema. Antes de canjear GLP, los atacantes abrieron grandes posiciones cortas en WBTC. Dado que una vez que se abre una posición corta, se aumenta la cantidad total de cortos globales, y sin cambios en el precio, el sistema considera esta parte de los cortos como pérdidas no realizadas. Esta parte de la "pérdida" se contabiliza incorrectamente como "activos" en la tesorería, lo que provoca que el AUM se eleve artificialmente. A pesar de que la tesorería no obtuvo un valor adicional, el cálculo del canje se basa en este AUM inflado, lo que permite a los atacantes obtener activos muy por encima de lo que realmente les corresponde.
Este incidente expuso defectos significativos en el diseño del mecanismo de apalancamiento y la protección contra la reentrada de la plataforma. El problema central radica en la excesiva confianza en la lógica de redención de activos respecto al AUM, al no realizar una verificación de seguridad adecuada sobre sus componentes (como las pérdidas no realizadas). Al mismo tiempo, la suposición sobre la identidad del llamador en funciones clave (si es una cuenta externa o un contrato inteligente) también carece de controles obligatorios.
Este incidente de seguridad recuerda nuevamente a los desarrolladores de proyectos de blockchain que, al involucrar operaciones sensibles de fondos, deben asegurarse de que el estado del sistema no pueda ser manipulado maliciosamente. Especialmente al introducir lógicas financieras complejas (como el comercio con apalancamiento y derivados), se debe tener una estricta prevención contra ataques de reentrada y los riesgos sistémicos que pueden surgir de la contaminación del estado. Para los usuarios, esto también es una advertencia, ya que al participar en proyectos de finanzas descentralizadas se debe ser más cauteloso y prestar atención a la seguridad y la capacidad de gestión de riesgos del proyecto.