BlockSec: Análisis del principio de ataque de GMX

robot
Generación de resúmenes en curso

Escrito por: BlockSec

GMX sufrió un ataque de hackers, con pérdidas que superan los 40 millones de dólares. Los atacantes aprovecharon una vulnerabilidad de reentrada y, en el caso de que el contrato activara la función de apalancamiento, abrieron posiciones cortas para llevar a cabo el ataque.

La raíz del problema radica en el uso incorrecto de la función executeDecreaseOrder. Se suponía que el primer parámetro de esta función debía ser una cuenta externa (EOA), pero el atacante proporcionó 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.

Mecanismo de redención normal de GLP

En GMX, GLP es el token de proveedor de liquidez que representa una participación en los activos de la tesorería (como USDC, ETH, WBTC). Cuando un usuario llama a unstakeAndRedeemGlp, el sistema utiliza la siguiente fórmula para calcular la cantidad de activos que se deben devolver:

redeem_amount = (user_GLP / total_GLP_supply) * AUM

El cálculo del AUM (activos bajo gestión) es el siguiente:

AUM = El valor total de todos los pools de token + Pérdidas no realizadas globales de cortos - Ganancias no realizadas globales de cortos - Monto reservado - Deducción preestablecida (aumDeduction)

Este mecanismo garantiza que los poseedores de GLP obtengan una parte proporcional de los activos reales del tesoro.

Problemas después de activar el apalancamiento

Cuando enableLeverage está activado, los usuarios pueden abrir posiciones apalancadas (largas o cortas). Un atacante abrió una gran posición corta de WBTC antes de canjear GLP.

Debido a que la apertura de una posición corta aumenta la escala global de posiciones cortas, en caso de que no haya cambios en el precio, el sistema asume por defecto que esa posición corta está en pérdidas, y esta parte de la pérdida no realizada se contabiliza como "activos" del tesoro, lo que provoca un aumento artificial del AUM. Aunque el tesoro no ha obtenido valor adicional en realidad, el cálculo de reembolso se basará en este AUM inflado, lo que permite a los atacantes obtener activos muy por encima de lo que les corresponde.

Proceso de ataque

Ataque de transacción

Escrito al final

Este ataque expuso graves defectos en el mecanismo de apalancamiento y el diseño de protección contra reentradas de GMX. El problema central radica en la confianza excesiva en la lógica de redención de activos respecto al AUM, sin realizar suficientes verificaciones de seguridad sobre sus componentes (como las pérdidas no realizadas). Al mismo tiempo, la suposición sobre la identidad del llamador en funciones clave (EOA vs contrato) también carece de una validación obligatoria. Este incidente recuerda nuevamente a los desarrolladores que, al involucrar operaciones sensibles de fondos, deben asegurarse de que el estado del sistema no pueda ser manipulado, especialmente al introducir lógica financiera compleja (como apalancamiento y derivados), donde se debe tener especial cuidado para prevenir los riesgos sistémicos derivados de reentradas y contaminación del estado.

Ver originales
This page may contain third-party content, which is provided for information purposes only (not representations/warranties) and should not be considered as an endorsement of its views by Gate, nor as financial or professional advice. See Disclaimer for details.
  • Recompensa
  • Comentar
  • Compartir
Comentar
0/400
Sin comentarios
  • Anclado
Opere con criptomonedas en cualquier momento y lugar
qrCode
Escanee para descargar la aplicación Gate
Comunidad
Español
  • 简体中文
  • English
  • Tiếng Việt
  • 繁體中文
  • Español
  • Русский
  • Français (Afrique)
  • Português (Portugal)
  • Bahasa Indonesia
  • 日本語
  • بالعربية
  • Українська
  • Português (Brasil)