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.
  • Un article de ce blog revient sur cette information

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.