Un hacker transforme 55 jours de transactions échouées en une clé maîtresse de 3 millions de dollars qui a vidé les portefeuilles de GalaChain

L'exploitation de GalaChain en août a transformé des transactions échouées en autorisations réutilisables, exposant une faille de sécurité qui avait survécu à plusieurs audits.

La blockchain développée par Gala Games a déclaré que l'attaquant avait utilisé des signatures historiques provenant de transactions infructueuses pour siphonner environ 2 milliards de GALA (environ 3 millions de dollars) et des dizaines d'autres tokens de neuf portefeuilles le 18 août.

Son rapport d'autopsie du 14 septembre décrit une opération préparée avant le premier transfert non autorisé, avec des soldes cartographiés, des soumissions automatisées et une faiblesse touchant à la fois la vérification des signatures et la protection contre les rejets.

Gala a corrigé les failles après avoir suspendu son pont pendant l'attaque. L'incident soulève désormais une question plus large pour les opérateurs de blockchain : les systèmes construits autour de signatures valides et de contrôles d'urgence déclenchés par l'homme peuvent-ils répondre suffisamment rapidement une fois que l'exploitation a été automatisée ?

Les transactions échouées sont devenues un inventaire d'attaques

L'attaquant est arrivé avec 74 signatures rejouables rassemblées à partir de transactions échouées s'étalant sur 55 jours, a déclaré Gala.

Ces signatures étaient associées à ce qui semble avoir été une connaissance détaillée des comptes affectés. Sur 59 combinaisons compte-token ciblées lors de l'incident, 56 ont été vidées de leur solde exact lors de la première tentative. Les quatre plus grandes positions en GALA ont été prises dans l'ordre décroissant en 18 secondes.

Ce schéma suggère qu'une reconnaissance a eu lieu avant que l'exploitation ne commence plutôt que les soldes des comptes ne soient découverts transaction par transaction pendant l'attaque.

L'exécution s'est ensuite déroulée rapidement. Gala a enregistré 1 066 soumissions à un intervalle médian de 4,5 secondes, avec 73,9 % arrivant exactement à un bloc d'intervalle.

Les signatures historiques étaient précieuses en raison de la manière dont GalaChain gérait la vérification des données typées EIP-712.

Avant le correctif, le vérificateur acceptait les définitions de type fournies avec la demande plutôt que de les dériver de l'opération invoquée. Cela a permis qu'une signature couvrant un ensemble de champs soit présentée tandis qu'une autre méthode s'exécutait en utilisant des informations supplémentaires que le signataire n'avait jamais engagées.

Un exemple sur la chaîne montre un appel TransferToken traitant environ 1,64 milliard de GALA bien que la structure EIP-712 fournie pour vérification décrivait une opération AddLiquidity. La destination, la quantité et l'instance de token utilisées par le transfert étaient en dehors de la structure signée.

La signature elle-même était cryptographiquement valide. Le système ne pouvait pas garantir que le titulaire du compte avait autorisé les effets économiques que l'exécution a finalement produits.

Gala a déclaré que les enquêteurs n'avaient trouvé aucune preuve que les clés privées, les phrases de départ ou les mots de passe des utilisateurs affectés avaient été compromis. Cette conclusion repose en partie sur des preuves internes que l'entreprise n'a pas publiées.

Une autre faiblesse de rejet a élargi le pool de signatures que l'attaquant pouvait utiliser.

GalaChain a attribué des clés de transaction uniques destinées à empêcher qu'un même payload signé ne soit soumis plus d'une fois. Mais lorsqu'une transaction échouait, la clé pouvait revenir à l'état des changements d'état infructueux.

La signature restait visible sur le grand livre public tandis que la clé de rejet restait disponible.

Gala a déclaré que 57 des 60 transactions sources historiques liées à l'exploitation contenaient au moins une opération interne échouée, tandis qu'aucune n'a été entièrement réussie.

La combinaison a effectivement transformé des demandes historiques infructueuses en autorisations réutilisables. Un attaquant n'avait pas besoin de falsifier des signatures ou de voler les clés privées derrière chaque portefeuille ciblé car des signatures authentiques avaient déjà été publiées sur la chaîne.

Les audits de GALA ont manqué l'interaction entre les protections

Pendant ce temps, la vulnérabilité avait survécu à des examens de sécurité externes avant l'attaque.

Gala a déclaré que la logique de vérification pertinente avait été examinée lors d'un engagement CertiK axé sur l'autorisation fin 2025 et d'un examen du SDK par Hashlock en janvier. Aucun n'a identifié le problème de portée de signature.

L'entreprise n'a pas publié ces rapports, rendant difficile la détermination de ce que chaque examen a testé ou de l'étendue de l'examen de l'interaction entre la vérification de signature et la protection contre la répétition.

Notamment, le mécanisme de répétition lui-même a été introduit après une découverte antérieure de CertiK.

Cette protection pourrait empêcher la réutilisation après qu'une clé de transaction ait été consommée. L'attaquant du 18 août a trouvé la limite où la protection cessait de s'appliquer : des transactions échouées dont les charges utiles signées étaient devenues publiques alors que leurs clés uniques restaient inutilisées.

Gala a ensuite modifié les deux systèmes.

La vérification de signature tire désormais ses informations de type de l'opération appelée plutôt que de faire confiance à une définition fournie par l'appelant. Les demandes incluent également des identifiants qui lient les signatures plus étroitement au canal, au contrat et à la méthode autorisés, tandis que les horodatages d'expiration limitent la durée pendant laquelle les charges utiles signées restent valides.

La correction de répétition persiste une clé de transaction unique même si l'opération commerciale sous-jacente échoue, empêchant la même demande historique de rester disponible pour une autre tentative.

Ces correctifs comblent les deux faiblesses décrites dans le rapport d'analyse. Ils ne résolvent pas le problème de temps de réponse qui émerge une fois qu'une attaque ayant l'air valide est déjà en cours.

Le premier transfert non autorisé vérifié a eu lieu à 02:21:54 UTC. Gala a suspendu le pont à 05:09:19 UTC, environ deux heures et 47 minutes plus tard, et a commencé à retirer des rôles de l'adresse du destinataire à 05:22.

L'entreprise n'a pas divulgué quand sa surveillance a d'abord détecté l'activité, donc cet intervalle ne peut pas être considéré comme son temps de réaction. Gala a déclaré que les tentatives de déplacer des actifs par le biais du pont ont été rejetées après la pause.

La chronologie montre néanmoins le décalage auquel sont confrontés les opérateurs une fois que l'exploitation atteint la vitesse machine : les soumissions peuvent arriver toutes les quelques secondes tandis que la détection, l'enquête et l'intervention d'urgence peuvent encore nécessiter des décisions humaines.

Les opérateurs de ponts font face à un problème de défense à vitesse machine

Gala a déclaré qu'elle avait depuis ajouté des limites de taux par identité, une surveillance comportementale pour les comptes de haute valeur et un examen supplémentaire pour les retraits de pont au-dessus de certains seuils.

Ces mesures déplacent les contrôles de sécurité plus tôt dans le processus de règlement, où une activité inhabituelle peut être ralentie avant que les actifs ne quittent le système.

Elles introduisent également des compromis.

Les signatures liées aux opérations, les expirations et les clés de répétition appliquent largement les instructions qu'un utilisateur a réellement signées. Les limites de taux et les déclencheurs comportementaux obligent les opérateurs à décider ce qui constitue une activité anormale, tandis que les retenues de retrait peuvent retarder les utilisateurs légitimes ainsi que les malveillants.

Gala a décrit l'attaquant comme utilisant des outils assistés par l'IA, mais cette évaluation repose sur des preuves internes que l'entreprise n'a pas publiées.

Cette distinction est importante alors que les entreprises de cryptomonnaie encadrent de plus en plus les menaces de sécurité autour de l'intelligence artificielle. Pour les opérateurs de ponts, le problème plus immédiat est de savoir si les attaquants automatisés peuvent exploiter des chemins d'autorisation ayant l'air valides plus rapidement que les systèmes de surveillance peuvent les identifier et les contenir.

Gala a déclaré avoir déposé une plainte auprès du Centre de plaintes pour crimes sur Internet du FBI et envoyé des demandes de préservation et de gel aux plateformes impliquées alors qu'elle suit les produits à travers quatre chaînes.

Le défi à long terme est maintenant susceptible de se déplacer vers la portée de l'audit. Les examens qui testent la vérification de signature, la protection contre la répétition et l'exécution des transactions séparément peuvent manquer des vulnérabilités qui n'apparaissent que lorsque ces systèmes interagissent.

Pour GalaChain, les futurs audits devront établir si des lacunes d'autorisation similaires subsistent ailleurs dans son SDK.

Pour les opérateurs de ponts plus largement, le coût commercial de la dépendance à une pause déclenchée par un humain augmente avec chaque bloc une fois qu'un attaquant arrive avec des signatures récoltées, des soldes cartographiés et un moteur de soumission automatisé.

Ce contenu est fourni à titre informatif uniquement et ne constitue pas un conseil financier, d'investissement, juridique ou fiscal. Les événements, récompenses, promotions en ligne ou informations mentionnées ici ne doivent pas être considérés comme une recommandation, une sollicitation ou une invitation à acheter, vendre, trader ou effectuer toute autre opération sur des actifs crypto. Les actifs crypto sont très volatils et peuvent entraîner des pertes. La disponibilité des services, produits et événements liés à WEEX peut varier selon les régions. Veuillez vous assurer que votre participation respecte les lois et réglementations locales applicables.