El atacante sustrajo aproximadamente 2.000 millones de GALA (unos $3 millones) y decenas de otros tokens de nueve monederos de GalaChain el 18 de agosto, usando 74 firmas obtenidas de transacciones fallidas que se remontaban a 55 días atrás. Se combinaron dos fallos: un verificador EIP-712 que aceptaba definiciones de tipo proporcionadas por el llamante en lugar de derivarlas de la operación invocada, y un sistema de protección contra replay que revertía claves de transacción únicas cada vez que una solicitud fallaba. De las 59 combinaciones de cuenta y token atacadas, 56 fueron vaciadas hasta su saldo exacto en el primer intento, y las cuatro mayores posiciones de GALA se tomaron en orden descendente en 18 segundos. El patrón apunta a un reconocimiento previo al ataque en lugar de un descubrimiento oportunista.
Por qué importa
Las firmas detrás del vaciado eran criptográficamente válidas. Los efectos económicos que autorizaron no coincidían con lo que los firmantes originales habían comprometido: un único ejemplo on-chain muestra una llamada TransferToken procesando unos 1.640 millones de GALA aunque la estructura EIP-712 enviada para verificación describía una operación AddLiquidity. No se comprometieron claves privadas, frases semilla ni contraseñas, que es la parte que debería preocupar a los operadores de infraestructuras similares. Un puente cuyo modelo de seguridad asume que la intención de una firma coincide con su operación puede ser vaciado sin falsificar nada ni robar ninguna clave.
Ambas brechas sobrevivieron a la revisión externa. Gala declaró que la lógica de autorización relevante fue examinada en un encargo de CertiK a finales de 2025 y en una revisión del SDK de Hashlock en enero. Ninguna señaló la interacción entre la verificación de firmas y la protección contra replay. El propio mecanismo de replay se había introducido tras un hallazgo anterior de CertiK, lo que significa que la salvaguarda se añadió sin probar el caso límite donde dejaba de aplicarse: transacciones fallidas cuyos payloads firmados ya eran públicos.
Impacto en el mercado
Gala pausó su puente unas 2 horas y 47 minutos después de la primera transferencia no autorizada verificada, y comenzó a retirar roles de la dirección receptora aproximadamente 13 minutos después. Los intentos de mover activos a través del puente tras la pausa fueron rechazados. La cronología es la señal más amplia para los operadores de puentes: los envíos llegaron con una mediana de intervalo de 4,5 segundos, con un 73,9% cayendo exactamente a un bloque de distancia, mientras que la detección, la investigación y la intervención humana ocuparon la mayor parte de una mañana. La explotación a velocidad de máquina se encuentra con la respuesta a velocidad humana, y la brecha se refleja directamente en los activos perdidos.
Los parches cierran las dos debilidades específicas, pero no el problema de auditoría subyacente.
Preguntas frecuentes
-
¿Cuánto se robó en el exploit de GalaChain?
Según la autopsia de Gala del 14 de septiembre, unos 2.000M de GALA (~$3 millones) y decenas de otros tokens fueron sustraídos de nueve monederos de GalaChain el 18 de agosto.
-
¿Cómo vació el atacante GalaChain sin robar claves privadas?
El atacante reprodujo 74 firmas criptográficamente válidas obtenidas de transacciones históricas fallidas, explotando un fallo en la verificación EIP-712 que permitía que los efectos económicos de una operación difirieran de lo que el firmante había comprometido.
-
¿Alguna auditoría señaló la vulnerabilidad de GalaChain antes del ataque?
No. Gala declaró que la lógica de autorización afectada fue revisada por CertiK a finales de 2025 y por Hashlock en enero, pero ninguna identificó la interacción entre la verificación de firmas y la protección contra replay que combinó el exploit.
-
¿Cuánto tardó Gala en pausar el puente tras iniciarse el exploit?
La primera transferencia no autorizada verificada ocurrió a las 02:21:54 UTC. Gala pausó el puente a las 05:09:19 UTC, unas 2 horas y 47 minutos después, y comenzó a retirar roles de la dirección receptora unos 13 minutos más tarde.
-
¿Qué ha cambiado Gala desde el ataque?
La verificación de firmas ahora deriva los datos de tipo de la operación invocada en lugar de confiar en definiciones del llamante, los payloads firmados llevan marcas de expiración, y las claves de replay persisten aunque falle la operación subyacente. Gala añadió también límites de velocidad por identidad y…