Un atacante drenó alrededor de 2.000 millones de GALA, valorados en unos 3 millones de dólares, además de decenas de tokens de otras clases, tras explotar dos fallos relacionados con la validación de firmas y la protección contra repeticiones en GalaChain. El incidente, ocurrido el 18 de agosto, afectó a nueve monederos y permitió reutilizar firmas procedentes de transacciones que habían fallado.
Gala Games detalló el ataque en un informe publicado el 14 de septiembre. La compañía sostiene que no hay indicios de que se comprometieran las claves privadas, las frases semilla o las contraseñas de los usuarios afectados. Su conclusión se basa en evidencias internas que no han sido publicadas.
Firmas válidas para operaciones que nunca se autorizaron
El atacante había reunido 74 firmas reutilizables de transacciones fallidas, algunas generadas hasta 55 días antes del ataque. Esas firmas se combinaron con un conocimiento aparentemente preciso de los saldos de las cuentas. De 59 combinaciones de cuenta y token seleccionadas, 56 fueron vaciadas por completo en el primer intento. Las cuatro mayores posiciones en GALA se retiraron en orden descendente en apenas 18 segundos.
El patrón apunta a que la preparación se produjo antes de las primeras transferencias no autorizadas. GalaChain registró 1.066 envíos, con un intervalo mediano de 4,5 segundos; el 73,9% llegó exactamente con un bloque de diferencia respecto al anterior.
La raíz del problema estaba, en parte, en la forma en que la red verificaba los datos tipados de EIP-712. Antes de la corrección, el sistema aceptaba la definición de los tipos incluida en la solicitud, en lugar de derivarla de la operación que iba a ejecutarse. Eso permitía presentar una firma asociada a un conjunto de campos y ejecutar después otro método con información adicional que el usuario nunca había autorizado expresamente.
GalaChain documentó un caso en cadena en el que una llamada para transferir tokens procesó unos 1.640 millones de GALA, aunque la estructura utilizada para verificar la firma describía una operación de provisión de liquidez. El destino, la cantidad y la identificación del token transferido quedaban fuera de los datos firmados. La firma era criptográficamente válida, pero el sistema no podía garantizar que el titular hubiese autorizado el resultado económico de la operación.
El fallo de las transacciones fallidas
El segundo problema amplió el número de firmas que podían utilizarse. GalaChain asignaba una clave única a cada transacción para impedir que una misma carga firmada se presentara más de una vez. Sin embargo, cuando una transacción fallaba, esa clave podía revertirse junto con los cambios de estado no ejecutados. La firma permanecía visible en el registro público, mientras que el mecanismo que debía impedir su repetición seguía disponible.
Según el informe, 57 de las 60 transacciones históricas vinculadas al ataque contenían al menos una operación interna fallida y ninguna se había completado íntegramente. La combinación de ambos fallos convirtió solicitudes antiguas y fallidas en permisos que podían reutilizarse. El atacante no necesitó falsificar todas las firmas ni hacerse con las claves privadas de cada monedero: algunas autorizaciones auténticas ya estaban publicadas en la cadena.
La vulnerabilidad había sobrevivido a revisiones externas. Gala afirma que la lógica de autorización fue examinada en una auditoría de CertiK realizada a finales de 2025 y que el kit de desarrollo fue revisado por Hashlock en enero. Ninguna de las dos detectó el problema relacionado con el alcance de las firmas. Los informes no se han hecho públicos, por lo que no es posible conocer qué pruebas incluyeron ni hasta qué punto analizaron la interacción entre la verificación y la protección contra repeticiones.
Gala corrigió el código, pero persiste el reto de la respuesta
Tras detener el puente durante el ataque, Gala modificó ambos sistemas. La verificación de firmas ahora obtiene la información de tipos a partir de la operación llamada, en vez de confiar en una definición proporcionada por quien envía la solicitud. Además, las peticiones incorporan identificadores vinculados al canal, el contrato y el método autorizado, junto con fechas de expiración. La clave única de cada transacción también se conserva aunque falle la operación subyacente.
La primera transferencia no autorizada verificada se produjo a las 02:21:54 UTC. Gala pausó el puente a las 05:09:19 y comenzó a retirar permisos de la dirección receptora a las 05:22. La empresa no ha indicado cuándo detectó inicialmente la actividad, de modo que ese intervalo no puede considerarse por sí solo su tiempo de reacción. Tras la pausa, los intentos de sacar fondos a través del puente fueron rechazados.
La compañía ha añadido límites de frecuencia por identidad, vigilancia del comportamiento de las cuentas con grandes saldos y revisiones adicionales para determinadas retiradas del puente. También presentó una denuncia ante el Centro de Denuncias de Delitos en Internet del FBI y envió solicitudes de conservación y congelación a plataformas implicadas mientras rastrea los fondos en cuatro cadenas.
El caso deja una conclusión relevante para los operadores: revisar por separado las firmas, las repeticiones y la ejecución puede no bastar si el riesgo aparece precisamente en la interacción entre esos mecanismos. Una vez automatizado el ataque, las transacciones avanzan cada pocos segundos, mientras que la detección, la investigación y la activación de controles de emergencia siguen dependiendo en buena medida de decisiones humanas.
