- Un groupe de hackers ukrainiens, en coopération avec les services de renseignement militaires, a paralysé l’infrastructure IT de Gaskar Integration, l’un des principaux fabricants russes de drones
- Plus de 47 To de données critiques et de sauvegardes ont été supprimés, interrompant les opérations clés de l’entreprise
- Les systèmes internes de l’usine, ainsi que les programmes de comptabilité et de production, sont tous devenus inopérants
- Jusqu’aux portes d’accès de l’usine ont été bloquées, obligeant les employés à utiliser les issues de secours pour entrer et sortir
- Les données exfiltrées comprennent des informations personnelles sur les employés ainsi que de la documentation technique sur les drones, et ont été remises au ministère ukrainien de la Défense
Points clés
- Des cyberactivistes ukrainiens, en coopération avec les services de renseignement militaires, ont attaqué le réseau et l’infrastructure de serveurs de Gaskar Integration, l’un des plus grands fabricants fournissant des drones à l’armée russe
- Cette attaque a détruit plus de 47 To d’informations techniques ainsi que 10 To de sauvegardes, et ces données contenaient également des éléments montrant une coopération étroite entre la Russie et la Chine
- À cause du piratage, tous les systèmes de l’entreprise — Internet, programmes de production et logiciels de comptabilité — ont été paralysés, rendant également impossible le fonctionnement normal du centre de R&D de Gaskar
- Toutes les portes d’accès des usines de production de drones ont été bloquées, forçant les employés à quitter les lieux et à se déplacer via les issues de secours
- Les informations exfiltrées comprennent des questionnaires confidentiels d’employés et des documents techniques sur la production de drones, et ont été transmises à des experts relevant du ministère ukrainien de la Défense
Contexte supplémentaire
- Des experts cyber du renseignement militaire avaient déjà désactivé auparavant le site web des chemins de fer russes au moyen d’une attaque d’ampleur
- Ils avaient aussi mené avec succès par le passé une attaque contre la société russe Regiontransservice, interrompant l’ensemble de ses services
1 commentaires
Réactions sur Hacker News
J’exploite un petit labo à la maison, avec une trentaine de services.
Un jour, en remplaçant le disque principal, j’ai tout reconstruit depuis zéro à partir des sauvegardes, et tout était de nouveau en ligne en une heure.
Mais ensuite, j’ai passé une semaine à corriger des détails un peu partout et à me débattre avec des choix de configuration dont je ne me rappelais même plus la raison.
C’est un labo simple, géré par une seule personne, basé sur Docker, et je travaille moi-même dans l’IT.
Mais reconstruire depuis zéro toute une infrastructure gérée pendant des années par plusieurs personnes, c’est une tâche énorme.
J’ai aidé bénévolement à remettre en état un hôpital touché par un ransomware, et les deux employés IT sur place n’avaient absolument aucune idée de quoi faire ; le support officiel était très en dessous des attentes.
J’ai aussi aidé sur des incidents de ransomware dans de grandes entreprises, et une énorme partie du travail consistait simplement à comprendre pourquoi les systèmes avaient été configurés comme ça.
Il y avait bien de la documentation et des tests, mais dans la réalité on se heurte vite au mur du terrain.
La police a déjà perquisitionné chez nous et emporté pour 10 000 dollars d’équipement : desktop, laptop, NAS, disques durs, etc.
Comme je gérais les sauvegardes et les plans de reprise après sinistre dans mon ancien travail, j’avais pris mes précautions.
En un ou deux jours, j’avais récupéré l’essentiel, avec environ deux jours de perte de données ; heureusement, c’était pour un usage domestique, donc rien de critique.
Cette expérience m’a poussé à faire plusieurs améliorations structurelles, ce qui réduirait encore les dégâts si cela se reproduisait.
(Et huit mois plus tard, la police a conclu que j’étais innocent et a ordonné la restitution de mon matériel, mais les enfants en ont gardé un traumatisme.)
Voilà pourquoi la documentation est si importante, y compris au niveau de l’architecture logicielle.
Après quelques mois, il est très facile d’oublier pourquoi on a pris telle ou telle décision.
Par exemple : « pourquoi j’ai choisi Kysely comme outil ORM/SQL », « pourquoi on utilise Deno/Bun », « pourquoi l’arborescence est organisée par fonctionnalités », « pourquoi on a forké telle bibliothèque et comment on la maintient », « pourquoi AWS/GCP/Azure/Docker », « pourquoi cette distribution Kubernetes », « pourquoi ce projet a été lancé et quels sont ses objectifs », etc.
Du coup, j’ai créé une section # Decisions dans le README.md pour tout documenter.
Ça m’a évité de remettre en doute en permanence mes propres choix et de fouiller sans fin dans la documentation.
Les mainframes des années 1990 étaient tellement stables et redondants qu’il arrivait qu’on ne les redémarre pas pendant plus de dix ans, avec même des upgrades du kernel sans interruption.
Mais dans une entreprise, il y a eu une coupure de courant, puis une panne du générateur de secours ; quand l’alimentation est revenue, il a fallu des mois pour comprendre ce que cette machine faisait réellement et comment la redémarrer.
Après ça, la plupart des entreprises se sont mises à redémarrer volontairement leurs mainframes tous les six mois pour tester la remise en route.
Dans les pratiques IT modernes, la reprise après sinistre est à peine prise en compte.
Même les organisations très rigoureuses sur les sauvegardes testent rarement la restauration en conditions réelles.
Faute de personnel, on se contente souvent d’empiler rapidement ce qui fonctionne.
Concevoir une infrastructure facile à reconstruire demande facilement deux fois plus d’efforts que de simplement l’installer.
Le témoignage sur le bénévolat après le ransomware à l’hôpital m’intéresse.
En IT de santé, les droits d’accès sont généralement gérés de manière extrêmement stricte ; auparavant, on ne pouvait pas accéder aux systèmes sans formation PHI ni vérification d’antécédents. Je me demande donc si, vu l’urgence, une procédure d’onboarding temporaire accélérée a été mise en place, ou si ce bénévolat a été possible via des contacts internes à l’hôpital.
Je travaille dans une entreprise allemande.
La planification de la production fonctionne actuellement à partir d’impressions Excel établies trois mois à l’avance.
La migration du système ERP a échoué, et personne ne sait comment la résoudre.
La direction de production cache la situation et n’en parle même pas au département d’ingénierie.
Cette situation pourrait durer des années ; pour les consultants, c’est un système qui les fait vivre.
C’est la preuve que l’infrastructure IT n’est pas indispensable à la production manufacturière : on peut s’en passer, c’est juste agréable de l’avoir.
Fin des années 1990 et début 2000, le ministère danois de la Défense a voulu déployer DeMars, un nouveau système d’approvisionnement construit sur SAP.
Un ami à moi qui travaillait aux achats a commandé en énorme quantité tous les articles dont il avait la charge juste avant le lancement de DeMars ; il a même été convoqué pour suspicion de fraude.
Il n’avait tout simplement aucune confiance dans DeMars et estimait qu’il fallait constituer des stocks.
Et de fait, une fois DeMars déployé, les achats se sont quasiment arrêtés pendant un an.
Au final, seuls les articles gérés par mon ami sont restés disponibles pendant toute la transition vers le nouveau système.
J’ai travaillé comme développeur firmware dans l’industrie à la fin des années 1990.
À l’époque, tout se faisait encore sur papier.
L’entreprise a réussi à déployer un ERP basé sur Oracle et tout le monde s’en réjouissait, mais six mois plus tard, quelqu’un a percuté le mur de la salle des machines avec un chariot élévateur, provoquant un incendie dans l’UPS ; trois racks d’équipements, dont le serveur Oracle, ont été entièrement détruits.
Comme personne ne faisait vraiment confiance au système et que tout continuait à être noté sur papier, on a continué à travailler avec papier + rapports Excel jusqu’à mon départ, six ans plus tard.
En fin de compte, la méthode papier s’est révélée résistante aux chariots élévateurs.
Excel a l’avantage que beaucoup d’employés de bureau peuvent le comprendre et le modifier intuitivement.
Si la plupart des infrastructures IT intégraient ce genre de fonctions accessibles, elles seraient probablement bien plus pratiques.
À l’inverse, quand l’automatisation IT est totalement ancrée dans la production et qu’il ne reste plus personne habitué à l’ancien mode manuel, revenir au travail à la main peut devenir très difficile.
Après, ça dépend aussi de la complexité des commandes et des workflows.
Sans logiciel, les drones ne servent pas à grand-chose.
Si on connaît encore l’inventaire par cœur, on peut peut-être assembler à la main quelques quadricoptères télépilotés, mais la production de pièces imprimées en 3D, le vol stable, l’autonomie, la surveillance et les autres usages avancés deviennent impossibles.
Même le pilotage à distance serait compliqué.
La cyberguerre en Ukraine atteint un nouveau palier, on est au-delà de la simple cyberattaque.
Les drones ont profondément transformé cette guerre, comme le montre cette installation russe de fabrication de drones visée cette fois-ci.
Les drones ont apporté des innovations en reconnaissance, brouillage, interception de munitions, etc.
Leur capacité de destruction par rapport aux matériaux engagés est élevée, et grâce aux progrès de la vision par ordinateur, certains continuent de fonctionner malgré le brouillage du signal.
On est en train de vivre une réalité digne d’un film d’espionnage.
Cela montre à quel point l’Ukraine maîtrise la guerre asymétrique.
Avec la destruction de bombardiers à long rayon d’action et la mise à l’arrêt de sites de production de drones, elle ébranle des capacités centrales de la Russie.
On ne sait pas comment la guerre se terminera, mais il est clair que la résistance ukrainienne va continuer.
Dans le roman Ministry of the Future, les drones deviennent si avancés qu’on finit dans un monde où plus personne n’est en sécurité et où la guerre traditionnelle perd son sens.
Même de petits groupes peuvent assassiner n’importe qui, n’importe où dans le monde.
L’idée est intéressante, mais l’histoire est faible, donc je ne recommanderais pas vraiment le livre.
À propos des « drones qui fonctionnent malgré le brouillage électronique », il existe maintenant des drones contrôlés non pas par ondes radio, mais via des câbles à fibre optique ; c’est une réalité encore plus inquiétante.
Il reste à voir si l’importance des drones dans cette guerre s’appliquera aussi aux conflits futurs.
Le fait que la Russie accepte d’énormes pertes humaines pour progresser petit à petit est une situation particulière qui augmente la valeur des drones FPV.
La plupart des pays n’accepteraient pas de telles pertes, donc je ne pense pas que cette forme devienne le standard de la guerre.
Des drones à réaction longue portée et bon marché pourraient au contraire jouer un rôle plus important.
Les informations de l’article reposent sur beaucoup d’hypothèses.
On n’entend qu’une seule version des faits, qui peut être exagérée pour sa valeur de propagande.
En général, la gestion de versions est correctement en place, et chaque développeur garde des copies locales du code et des fichiers CAD.
Des e-mails et des fichiers bureautiques ont peut-être été perdus, mais ce n’est probablement pas une perte critique.
Le site web fonctionne toujours tel quel.
L’entreprise attaquée cette fois n’est pas particulièrement connue dans la communauté drone, donc il ne s’agit sans doute pas d’un arrêt massif de production de grands modèles.
Ils ne peuvent tout de même pas ignorer des bases comme le versioning ; et le style de certains commentaires donne presque l’impression d’avoir été écrit par ChatGPT.
Je travaille dans une entreprise suisse de taille intermédiaire.
On développe notre propre ERP, et la stack est un véritable cauchemar.
On appelle ça entre nous la « sécurité par le chaos ».
Même si un attaquant entrait dans le système, il ne pourrait probablement plus en sortir.
Si 90 % du code était détruit, le service ne serait pas affecté, parce que 95 % du code est déjà inutile.
J’ai déjà développé moi-même un système MRP pour grande entreprise, donc je me demande comment cette approche va évoluer.
En général, j’ajoute même une couche d’authentification par clé basée sur hash OTP en plus des pratiques recommandées de sécurité et de reprise après sinistre.
Je pensais être plutôt extrême, mais là on dirait presque un scénario de survie de fin du monde.
On a l’impression d’une forme de résilience née de l’évolution.
C’est hilarant, on dirait une véritable barrière ICE du monde réel.
C’est à la fois terrifiant et assez admirable.
La plupart des entreprises ne se préparent pas clairement à un scénario où presque tous les dépôts de données internes seraient complètement effacés et où il faudrait tout redéployer depuis zéro.
Si on n’a jamais réellement pratiqué une reconstruction complète depuis zéro, il y a de fortes chances que les dépendances de déploiement contiennent des boucles.
On déploie un config pusher avec Jenkins/Puppet/Ansible, puis à un moment Jenkins lui-même finit par dépendre du config pusher ; on ne peut alors plus reconstruire simplement dans l’ordre, et il faut remonter tout l’historique des changements.
En IT, il existe des dépendances circulaires à peu près partout.
Le SSO devient une dépendance de presque tous les systèmes, et on retrouve ensuite des boucles dans le réseau du SSO et dans la gestion des différents systèmes.
Un redémarrage totalement à blanc est toujours difficile et très chronophage.
À moins de construire une double infrastructure complètement séparée, il est pratiquement impossible de résoudre parfaitement ce problème.
Une entreprise que je connais a vécu ça il y a un an.
Le cluster de stockage principal dont tout dépendait est tombé.
Au final, ils ont tout redéployé et restauré depuis des laptops de dev.
Le black start est un problème extrêmement difficile.
Même Facebook a déjà dû percer les serrures d’un datacenter à la perceuse pour rétablir la situation.
Je me demande comment on peut restaurer dans une telle situation.
S’il reste au moins une documentation papier, est-ce que cela suffit pour amorcer la reconstruction, ou faut-il supposer qu’elle a elle aussi disparu ?
Le secteur de la construction a un problème similaire.
La durée de vie des produits dépasse 50 ans, parfois plusieurs siècles, mais il arrive souvent qu’on ne puisse plus ouvrir aujourd’hui des fichiers de conception créés il y a 30 ans à cause de problèmes de compatibilité de format.
On parle de numérisation depuis des décennies, mais au bout du compte les vieux plans 2D — ou, de nos jours, les PDF qu’on appelle parfois du « papier numérique » — pourraient encore s’avérer utiles à l’avenir.
L’usage du vrai papier diminue, mais les problèmes de compatibilité de fichiers pourraient bien finir par le rendre de nouveau précieux.
Dans le titre de l’article, les auteurs de l’attaque sont qualifiés de « cyberactivistes », alors que dans le corps du texte ils deviennent des « cybercriminels ».
Cela fait penser à ces figures de frontière comme les corsaires semi-officiels de l’époque de la marine à voile, ou aux lettres de marque.
La théorie de la guerre de quatrième génération insistait justement sur l’effacement de la frontière entre civils et militaires.
Les règles d’engagement deviennent de plus en plus floues.
La Russie tue des civils chaque jour avec des drones.
On n’est pas dans une prétendue zone grise de guerre hybride ambiguë ; il s’agit simplement de gens qui essaient d’empêcher que leurs voisins soient tués par des drones.
Ça ressemble à un problème de traduction.
Le site en question est très favorable à l’Ukraine, donc il a peut-être employé « cyber criminal » au simple sens de « hacker » pour éviter de présenter ces acteurs sous un jour trop négatif.
En pratique, l’hypothèse la plus plausible est qu’il s’agit d’une action organisée de l’armée ukrainienne.
Dans ce cas, il ne serait pas juste de les considérer comme des criminels.
C’est un peu une situation à la Robin des Bois.
Héros pour les uns, criminels pour les autres.
L’article est probablement un assemblage de plusieurs sources, ce qui expliquerait le mélange de termes.
Ce serait bien d’avoir un vocabulaire distinct pour parler des camps en cyberguerre.
« Cyberactiviste » fait surtout penser à des manifestants en ligne ; au lieu de ce terme banal qu’on entend dans les films, j’aimerais voir des mots comme « cybersoldat » ou « milice réseau ».
Je me suis amusé tout seul en remarquant que la date sur la photo de l’article diffère d’un jour du début de l’époque Unix.
Ce site web est vraiment particulier.
Le gouvernement russe le bloque, ce qui provoque une erreur TLS ; et même en contournant ça, on tombe sur la page « bloqué » de Cloudflare ; il faut utiliser un VPN pour accéder jusqu’à l’article original en russe.
La page liée est en anglais, mais il se peut que la version russe du site ne visait pas spécialement les habitants de Russie.
En Russie, la question de la langue est sensible, mais en Ukraine le russe reste largement utilisé et des articles en russe y sont effectivement publiés.
Je recommande vivement d’utiliser des sites d’archive comme archive.today ou archive.org (Internet Archive).
Quelqu’un a d’ailleurs récemment sauvegardé un lien d’archive.
Le problème ne vient peut-être pas du site lui-même, mais du blocage gouvernemental, ou éventuellement de CloudFlare.
Cloudflare pourrait bloquer l’accès à cause de la cause profonde de l’erreur TLS.
Je me demande si les deux camps s’inquiètent du firmware des drones.
Injecter discrètement un firmware modifié dans les drones ennemis semblerait avoir une vraie valeur stratégique.
C’est intéressant, mais le risque est élevé (on peut se faire repérer facilement et compromettre toute l’opération).
Au bout du compte, l’approche brutale reste probablement la plus rationnelle.
En général, le firmware des drones est flashé juste avant la mission.
En pratique, il serait peut-être plus efficace que de fermer l’usine de faire en sorte que les drones se comportent discrètement autrement — par exemple attaquer leur propre base au lancement ou passer sous contrôle distant.
Une stratégie amusante consiste, paraît-il, à infecter la carte SD d’un drone avec un virus, de sorte que si le drone tombe en territoire ennemi et que l’adversaire la branche sur un ordinateur, cet ordinateur soit infecté.
« Des cyberactivistes ukrainiens en coopération avec les services de renseignement militaire… »
Donc, en gros, cela signifierait que des services de renseignement étrangers se contentent de donner le signal, et qu’on n’est pas dans une cyberguerre directe.
À propos de l’idée selon laquelle « des services étrangers donnent seulement le signal, donc ce n’est pas une cyberguerre directe » :
les services russes attaquent déjà directement les pays de l’OTAN, donc il n’y a quasiment plus de place pour ce genre de justification.
Comme l’Ukraine et la Russie sont déjà en guerre depuis des années, elles n’ont pas vraiment besoin de préserver une quelconque plausibilité de dénégation.
Je me demande ce que recouvre exactement l’expression « services de renseignement étrangers » ; de toute façon, à l’échelle mondiale, les attaques sont permanentes, donc il ne faut pas être naïf.
L’article ne mentionne pas de « services de renseignement étrangers ».
Il parle explicitement des services de renseignement militaire ukrainiens.