O atacante drenou cerca de 2 mil milhões de GALA (cerca de $3 milhões) e dezenas de outros tokens de nove carteiras GalaChain a 18 de agosto, usando 74 assinaturas recolhidas de transações falhadas ao longo de 55 dias. Duas falhas combinaram-se: um verificador EIP-712 que aceitava definições de tipo fornecidas pelo chamador em vez de derivá-las da operação chamada, e um sistema de proteção contra replay que revertia as chaves únicas de transação sempre que um pedido falhava. Das 59 combinações de conta-token visadas, 56 foram drenadas no saldo exato logo na primeira tentativa, e as quatro maiores posições em GALA foram capturadas por ordem decrescente em 18 segundos. O padrão aponta para reconhecimento prévio ao ataque, e não para descoberta oportunista.
Porquê é relevante
As assinaturas por trás do esvaziamento eram criptograficamente válidas. Os efeitos económicos que autorizaram não correspondiam ao que os signatários originais tinham aceite: um único exemplo on-chain mostra uma chamada TransferToken a processar cerca de 1,64 mil milhões de GALA, embora a estrutura EIP-712 submetida para verificação descrevesse uma operação AddLiquidity. Chaves privadas, frases-semente e palavras-passe não foram comprometidas, sendo este o aspeto que deve preocupar operadores de infraestruturas semelhantes. Uma bridge cujo modelo de segurança parte do princípio de que a intenção de uma assinatura corresponde à operação que ela autoriza pode ser esvaziada sem forjar nada nem roubar qualquer chave.
Ambas as lacunas sobreviveram à revisão externa. A Gala afirmou que a lógica de autorização relevante foi examinada num trabalho da CertiK no final de 2025 e numa revisão da Hashlock ao SDK em janeiro. Nenhuma das duas sinalizou a interação entre verificação de assinaturas e proteção contra replay. O próprio mecanismo de replay tinha sido introduzido após uma descoberta anterior da CertiK, o que significa que a salvaguarda foi acrescentada sem testar o cenário-fronteira em que deixava de se aplicar: transações falhadas cujos payloads assinados já eram públicos.
Impacto no mercado
A Gala pausou a sua bridge cerca de 2 horas e 47 minutos após a primeira transferência não autorizada verificada, começando depois a remover permissões do endereço recetor cerca de 13 minutos mais tarde. As tentativas de movimentar ativos através da bridge após a pausa foram rejeitadas. A cronologia é o sinal mais amplo para os operadores de bridges: as submissões chegaram com um intervalo mediano de 4,5 segundos, com 73,9% a entrarem com exatamente um bloco de diferença, enquanto a deteção, a investigação e a intervenção humana consumiram a maior parte de uma manhã. A exploração à velocidade das máquinas encontra a resposta à velocidade humana, e a diferença reflete-se diretamente em ativos perdidos.
As correções eliminam as duas falhas específicas, mas não o problema de auditoria subjacente.
Perguntas frequentes
-
Quanto foi roubado no exploit da GalaChain?
Foram drenados cerca de 2 mil milhões de GALA (cerca de $3 milhões) e dezenas de outros tokens de nove carteiras GalaChain a 18 de agosto, segundo a análise post-mortem da Gala de 14 de setembro.
-
Como é que o atacante drenou a GalaChain sem roubar chaves privadas?
O atacante repetiu 74 assinaturas criptograficamente válidas, recolhidas de transações históricas falhadas, explorando uma falha na verificação EIP-712 que permitia que os efeitos económicos de uma operação diferissem do que o signatário tinha autorizado.
-
Alguma auditoria sinalizou a vulnerabilidade da GalaChain antes do ataque?
Não. A Gala afirmou que a lógica de autorização afetada foi analisada pela CertiK no final de 2025 e pela Hashlock em janeiro, mas nenhuma identificou a interação entre verificação de assinaturas e proteção contra replay que o exploit combinou.
-
Quanto tempo demorou à Gala a pausar a bridge depois de o exploit ter começado?
A primeira transferência não autorizada verificada ocorreu às 02:21:54 UTC. A Gala pausou a bridge às 05:09:19 UTC, cerca de 2 horas e 47 minutos depois, e começou a remover permissões do endereço recetor cerca de 13 minutos após isso.
-
O que mudou a Gala desde o ataque?
A verificação de assinaturas passa agora a derivar os dados de tipo a partir da operação chamada, em vez de confiar em definições fornecidas pelo chamador; os payloads assinados incluem carimbos de validade, e as chaves de replay persistem mesmo quando uma operação de negócio subjacente falha. A Gala também adicionou…