Une blockchain peut utiliser des primitives cryptographiques robustes et disposer de contrats audités tout en restant vulnérable parce qu’un service interne écoute sur la mauvaise interface réseau.
La mise à jour publiée par SKALE le 6 octobre 2026 au sujet de l’incident IMA Bridge rappelle que la configuration de l’infrastructure fait partie intégrante de la sécurité d’un protocole.
Selon SKALE, des prestataires d’infrastructure exploitant des nœuds validateurs avaient été compromis fin août. L’enquête a identifié des ports accessibles depuis l’extérieur sur une partie des validateurs affectés. Des services internes, censés rester confinés à un environnement de confiance, pouvaient être joints depuis l’extérieur.
Cette exposition a permis d’interagir avec des fonctions privilégiées des nœuds et a contribué à l’exploitation du bridge IMA.
Ce que SKALE a communiqué
Dans son premier avis, SKALE a indiqué que des prestataires hébergeant des nœuds validateurs avaient été compromis et que l’attaquant avait retiré des actifs ERC-20 détenus dans l’infrastructure de bridge concernée.
La mise à jour d’octobre a fourni davantage de détails.
L’enquête a mis en évidence des restrictions réseau insuffisantes autour de plusieurs services internes. Certaines interfaces privilégiées étaient accessibles depuis Internet alors qu’elles auraient dû rester réservées à des réseaux ou des machines de confiance.
SKALE a également signalé des activités non autorisées impliquant des wallets de nœuds sur les machines touchées, suggérant un chemin d’attaque parallèle à l’exposition des services internes.
L’enquête restait en cours et SKALE a choisi de ne pas annoncer de bilan financier définitif avant la fin des vérifications.
Cette retenue compte : une communication de crise reste plus crédible lorsqu’elle présente clairement ce qui n’est pas encore établi.
Une règle de firewall peut devenir un contrôle de sécurité protocolaire
Les équipes d’infrastructure rangent parfois les règles de pare-feu dans la catégorie de l’administration système courante.
Pour un environnement de validation ou de bridge, cette approche est insuffisante.
Une API interne peut être conçue en supposant qu’elle n’est accessible que depuis localhost, un VLAN privé ou un réseau overlay de confiance. Cette hypothèse influence souvent le niveau d’authentification intégré à l’application.
Si la frontière réseau disparaît, l’API peut soudain devenir accessible à des attaquants contre lesquels elle n’a jamais été conçue pour résister.
Le scénario typique est le suivant :
- un service privilégié est considéré comme « interne » ;
- son authentification est limitée parce que le réseau est censé le protéger ;
- une erreur de pare-feu, de routage ou d’exposition de conteneur le rend public ;
- l’attaquant obtient une capacité ayant un impact sur le protocole sans casser aucune primitive cryptographique.
La sécurité d’un validateur dépasse largement son client consensus
Un environnement de validation en production ne se limite pas à un client de consensus.
Il comprend fréquemment :
- des agents d’orchestration ;
- des exporters de métriques ;
- des composants de gestion des clés ;
- des services de bridge ;
- des endpoints RPC internes ;
- des outils de déploiement ;
- des collecteurs de logs ;
- des systèmes de sauvegarde et de snapshots ;
- des wallets de nœud utilisés pour les opérations courantes.
Chacun de ces composants augmente la surface d’attaque.
La question pertinente n’est donc pas seulement « quel port utilise le validateur ? », mais quelles interfaces pourraient modifier le comportement du nœud, accéder à un secret ou influencer l’état du bridge si une machine non autorisée pouvait les joindre ?
La valeur d’une véritable séparation architecturale
SKALE indique que son déploiement SKALE on Base n’a pas été touché, parce qu’il repose sur une architecture et une infrastructure séparées.
C’est un exemple important de limitation du périmètre des dommages.
L’indépendance a un coût : davantage d’infrastructure, de monitoring et de complexité opérationnelle.
Mais une infrastructure partagée crée un risque de défaillance corrélée.
Deux environnements peuvent sembler indépendants tout en dépendant du même plan d’administration, des mêmes identifiants, de la même zone réseau ou du même pipeline de déploiement. Dans ce cas, ils peuvent être compromis ensemble.
Une architecture de sécurité doit donc distinguer la séparation logique de la séparation opérationnelle réelle.
Préserver les preuves avant de reconstruire
SKALE a demandé aux opérateurs de nœuds potentiellement concernés de conserver les logs et les éléments utiles aux investigations avant toute opération de nettoyage ou de redémarrage.
C’est une étape que l’urgence pousse facilement à oublier.
Le réflexe naturel est de corriger, redémarrer et redéployer le plus vite possible. Mais un serveur remis à zéro peut effacer les traces nécessaires pour répondre à des questions cruciales :
- comment l’attaquant est-il entré ?
- quels identifiants ont été consultés ou utilisés ?
- depuis combien de temps était-il présent ?
- quelles commandes ou requêtes ont été exécutées ?
- quels autres systèmes faut-il considérer comme exposés ?
La réponse à incident doit conjuguer confinement et investigation.
Ce que les opérateurs devraient changer
Refuser par défaut l’accès aux services internes
Un service sensible ne devrait pas devenir public à cause d’une unique règle de firewall oubliée. Plusieurs couches indépendantes doivent faire respecter la frontière.
Examiner l’exposition depuis Internet
Les équipes doivent régulièrement scanner leur propre surface d’attaque depuis l’extérieur. Lire les fichiers de configuration internes ne suffit pas.
Séparer les wallets de nœuds des comptes d’administration
Les fonds opérationnels et les wallets privilégiés doivent être soumis à des limites et à une surveillance explicites.
Détecter les changements d’exposition
L’ouverture d’un port, une modification d’infrastructure-as-code ou un changement de pare-feu doivent pouvoir être détectés comme des événements de sécurité.
Préparer la conservation des preuves
Les journaux doivent survivre à la machine qui les a produits. Une centralisation des logs avec protection contre l’altération facilite la reconstruction de l’incident.
Pourquoi cet incident concerne Snow-Fall
Snow-Fall intervient précisément à l’endroit où l’administration système devient de la sécurité protocolaire.
Un hébergeur de validateurs n’est pas seulement responsable de la disponibilité. Il doit maîtriser les frontières réseau, les secrets, les chemins de déploiement et les interfaces d’exploitation autour des nœuds.
L’incident SKALE montre pourquoi un service professionnel d’hébergement de nœuds devrait être évalué sur son architecture et ses procédures, pas seulement sur la quantité de CPU, de RAM ou un taux de disponibilité annoncé.
Pour les projets qui souhaitent revoir leur infrastructure, GLOV Consulting et les audits GLOV Secure peuvent aider à analyser les interfaces exposées, les frontières de confiance et les dépendances de réponse à incident.