La menace Stuxnet

Difficile d’imaginer un blog sur la cyber-sécurité industrielle sans son chapitre « Stuxnet », non pas seulement parce que c’est un sujet très à la mode en cyber-sécurité (ce qui est vrai), mais surtout parce que cela a de nombreux et importants impacts dans le domaine de la protection des installations industrielles.

Stuxnet sera décrit en détails plus bas, mais rappelons déjà en quelques lignes qu’il s’agit d’un logiciel malveillant particulièrement impressionnant à plusieurs points de vue  : sa cible présumée (installations nucléaires iraniennes), le nombre de failles logicielles qu’il peut exploiter pour aboutir à ses objectifs, le vol de deux certificats d’autorités de sécurité, la connaissance fine sur les installations cibles, et la capacité à reprogrammer, et à détourner de leur fonction des automates industriels Siemens, en cachant sa présence : c’est à la fois un « rootkit[1] » Windows et API, un virus, et un cheval de troie…

Des impacts multiples

Ce « mega-virus » oblige à repenser plusieurs choses :

  • La possibilité d’attaquer des automates via un simple accès au réseau de production, voire à un employé y ayant accès, afin de provoquer des dégâts conséquents[2].
  • La veille : Stuxnet a « réveillé » les différents acteurs de la sécurité (fournisseurs, sociétés de services, hackers white et black) qui s’intéressent à présent au sujet, comme en attestent le nombre croissant de failles publiées au printemps 2011 sur les SCADAs, et d’« exploits » commençant déjà à être intégrés dans les boîtes à outils standards des hackers (Metasploit, Immunity Canvas). Il est à présent nécessaire d’effectuer une veille de ces menaces, car il est devenu impossible d’ignorer un risque croissant rapidement.
  • La visibilité nouvellement donnée à ce sujet a des implications sur ce qui était acceptable et ne l’est plus aujourd’hui. Plus aucun directeur d’installation industrielle ne peut ignorer ce risque. En cas de cyber-incident avéré on ne comprendrait plus aujourd’hui qu’il n’y ait pas eu une réflexion menée pour au moins évaluer le risque, sinon prendre des mesures correctives.
  • Et enfin, bien sûr, la possibilité (probabilité disent les analystes) que des organisations d’état soient à l’origine de ce qui serait donc un acte de «cyber-guerre » visant un autre état. Rappelons que deux états[3] ont reconnu avoir une doctrine en la matière, et une organisation correspondante : les Etats-Unis (soupçonnés d’être les co-auteurs avec Israël , de Stuxnet) et la Chine avec sa « Blue Army ».

Historique rapide

L’essentiel de cet historique est reconstitué à partir d’une publication dédiée à Stuxnet de la société XMCO – je vous invite à récupérer leur document (gratuit) si vous souhaitez approfondir le sujet, c’est de loin le meilleur document disponible en Français.

  • Stuxnet aurait commencé à se répandre mi 2009
  • Il a été détecté le 17 Juin 2010 par la société bielorusse « Virusblokada » (!), qui a publié un rapport sur une nouvelle faille de sécurité relative à l’affichage dans Windows Explorer du contenu d’un répertoire infecté (faille liée aux icônes des raccourcis)
  • Dans les deux mois qui suivent, les révélations se multiplient : d’autres failles sont exploitées par ce virus pas encore nommé Stuxnet, on constate l’utilisation d’un certificat de sécurité (de Realtek Semiconductor Corp) pour signer des pilotes vérolés installés, puis un autre certificat (de JMicron technology)
  • Symantec renomme le virus « Stuxnet », et des échanges avec Siemens permettent d’identifier l’exploitation de failles dans le logiciel SCADA de Siemens WinCC (supervision) et PC7 (développement du code automates) – de type élévation de privilège (permettant de reprogrammer des APIs.)
  • Durant l’automne 2010, les éditeurs d’anti-virus incluent les signatures dans leurs produits, Microsoft et Siemens livrent les différents correctifs, et… metasploit reçoit différents « exploit » permettant d’utiliser les failles Windows et SCADA mises en évidence grâce à Stuxnet
  • En Novembre, Ralph Langer publie le résultat de ses analyses : Stuxnet ciblait particulièrement des installations nucléaires iraniennes – du moins, c’est dans la centrale Nucléaire en construction de Buscher et sur le site d’enrichissement d’uranium de Natanz que les dégâts auraient été significatifs, et nulle par ailleurs. Il décrit la complexité du produit :
    • informations confidentielles sur les installations iraniennes (matériel, capteurs, APIs etc.)
    • capacité à connaître et développer des « exploits » de 4 failles « 0-day »
    • code complexe (1,5Mib) embarquant de quoi exploiter 20 failles
    • plusieurs cheminements de réplication différents (USB, réseau, disques partagés, spooleurs d’impression
    • vols (non détectés) de deux certificats (X.509) à des industriels Taiwan
    • capacité à se connecter à un serveur « command&control » pour se mettre à jour
    • capacité à développer des sections de codes pour des automates Siemens, pour deux cibles très différentes (turbines à vapeur de centrales nucléaires et centrifugeuses d’enrichissement d’uranium) – ce qui nécessite de disposer de copies des code existant (adresses des variables etc..)
  • Ralph Langer en déduit qu’il s’agit nécessairement d’une organisation d’envergure, et il pointe les USA, Israël, et la Russie, comme les auteurs présumés de ce qui apparaît à présent comme une attaque ciblée. En effet les conditions d’activation et le code injecté dans les APIs étaient très spécifiques – Stuxnet reconnaissait ces conditions pour s’activer uniquement sur ses cibles.
  • Le New York Times appuie ces analyses dans un article de Janvier 2011
  • Des thèses contradictoires ont également été développées, soit pour infirmer que des états sont à la source, soit pour désigner la Chine
  • L’impact peut difficilement être confirmé, mais différentes sources font état de dégâts majeurs au niveau des centrifugeuses de Natanz. Ces équipements, tournant à très haute vitesse et en fonctionnement continu (réellement continu pendant des années), sont sensibles : les amener dans des domaines de résonnance (vibrations) diminue significativement leur espérance de vie.
  • Un an après sa publication initiale, Ralph Langer a fait une contribution courte, mais qui a déjà fait le tour de la blogosphère : la preuve de la possibilité pour tout un chacun d’utiliser des bouts de codes de Stuxnet pour se faire sa propre attaque « déni de service » sur un automate sans aucune connaissance de la supervision WinCC, des automates S7 et sans utilisation de logiciels Siemens, par simple « replay » réseau.

Conclusion

Siemens a développé un programme adapté au niveau de risque : contact avec les différentes administrations, disponibilité d’un « guichet » pour rapporter et traiter les failles, ressources dédiées, participation à des conférences de sécurité. Néanmoins, les dernières nouvelles comme la « time bomb in 14 bytes », et d’autres alertes provenant d’acteurs de la sécurité concernant de nouvelles failles , montrent que le problème mis en évidence par Stuxnet est loin de sa conclusion.

Il n’est pas rare dans le domaine de la cyber-sécurité, de devoir suivre de près l’actualité. Je crois que c’est parfaitement justifié dans le cas présent. Depuis l’an dernier, les événements et publications se multiplient. On pourrait croire que dans ces conditions il y aurait également dans l’industrie  un branle-bas de combat, mais le cycle de vie des projets industriels n’a rien à voir avec celui des hackers. Il est difficile de créer un sentiment d’urgence dans des environnements où un projet standard s’étale sur plusieurs années, et où les installations sont destinées à fonctionner un demi-siècle.

C’est je crois la principale, et très concrète, difficulté en cyber-sécurité industrielle.


[1] Logiciel malveillant modifiant des fichiers du système d’exploitation avant de devenir indétectable, par exemple en modifiant l’explorateur de fichiers Windows pour masquer ses proches fichiers, ou le gestionnaire de tâches pour masquer son processus actif

[2] En réalité cette démonstration a déjà été faite en 2007 par les Idaho National Labs pour le compte du DHS, dans l’expérience « Aurora » visant à détruire à distance un générateur diesel d’une valeur de 1M$ via une intrusion informatique. Mais l’échelle des dégâts est sans commune mesure, et il manquait sans doute la dimension géopolitique pour que cela soit repris par la presse comme l’a été Stuxnet. 

[3] Rassurez-vous, en Europe également les armées créent des services « cyber-guerre », un article récent de La Republica fait référence à une équipe créée en Italie, et nous savons qu’en France une telle division existe – c’est probablement le cas également chez nos autres voisins !

Tags: , ,

2 Commentaires sur “La menace Stuxnet”

  1. Patrice Bock dit :

    Eclairage intéressant dans un article de l’Informaticien d’avril 2012, qui reprend une analyse d’ISS : « Stuxnet : un agent double aurait accéléré l’infection ».
    Lien : http://www.linformaticien.com/actualites/id/24470/stuxnet-un-agent-double-aurait-accelere-l-infection.aspx

  2. Patrice Bock dit :

    Depuis cet article, d’autres études ont été réalisées et Stuxnet est à présent intégralement déchiffré / désassemblé. En particulier, Ralph Langer a fait une conférence expliquant le fonctionnement détaillé du code malveillant injecté dans les automates Siemens S7-300 pilotant les centrifugeuses, voir cet article : http://securid.novaclic.com/?p=755

Ajouter un commentaire

Note: Vous êtes responsable de vos commentaires, veillez à rester courtois et factuel. En postant votre commentaire, vous accordez de fait un droit de diffusion à Secur'id.