Stuxnet : un ver qui cible les systèmes SCADA

Stuxnet est le premier exemple connu d'un virus spécifiquement conçu pour attaquer les systèmes industriels (les systèmes SCADA). Son niveau de sophistication a étonné la communauté des experts, et le fait que ces techniques soient employées pour viser les systèmes industriels est inquiétant.

Au travers de cet article nous présentons une synthèse des analyses qui ont été publiées sur le fonctionnement de Stuxnet (et en particulier les analyses faites par Symantec et par Industrial Defender que nous listons en fin d'article), l'impact qu'il a eu et les motivations potentielles de ses auteurs.

 

1. Le fonctionnement de Stuxnet

Stuxnet a été découvert le 17 juin 2010 par la société biélorusse VirusBlokAda (société qui développe des produits antivirus). A cette date ce qui intéresse surtout les analystes c'est que ce ver utilise une vulnérabilité jusque là inconnue dans Windows (une faille "0-day") : la faille ".LNK" qui donnera lieu à la publication par Microsoft début août du correctif hors cycle MS10-046. Ce n'est que plus tard que l'on découvrira que le ver vise les systèmes SCADA.

 

Infection par clé USB

Le ver Stuxnet se propage par clé USB. Lorsqu'une clé USB infectée est branchée sur un PC, le simple fait de visualiser le contenu de cette clé avec l'explorateur de fichiers de Windows déclenche l'infection. Ce mécanisme d'infection (qui utilise la vulnérabilité .LNK) fonctionne sur toutes les machines Windows (de Windows NT4 à Windows 7) si les correctifs MS10-046 (qui sont disponibles depuis le 02/08/2010) n'ont pas été appliqués. Dès qu'il est activé, Stuxnet dissimule les fichiers infectés présents sur la clé USB. Il active pour cela un rootkit "userland" qui rend invisibles tous les fichiers de suffixe “.lnk” et les fichiers qui débutent par “~WTR” et se terminent par “.tmp”

Nota : Symantec indique que Stuxnet disposerait de 2 autres mécanismes de propagation : le dépôt d'un fichier infecté sur les partages réseaux auxquels le poste infecté  a accès (cf. [SYM-03]) et la propagation de machine en machine en utilisant la vulnérabilité MS08-067 (cf. [SYM.05]). Cette vulnérabilité est celle qui avait été utilisée par le ver Conficker.

 

Installation d'un rootkit

Le ver poursuit son installation en déposant différents fichiers dans des espaces systèmes, et en particulier :

• Un rootkit "noyau" (les fichiers drivers mrxcls.sys et mrxnet.sys) qui rend invisible les fichiers qui ont été utilisés lors de l'infection. Ce second rootkit, (connu sous le nom de « TmpHider ») a le même effet que le rootkit "userland" qui a été lancé dès le début de l'infection mais rend cette altération permanente. Il semblerait (mais les analyses publiées ne sont pas très précises sur ce point) que ce rootkit dissimule également des processus.
• Deux  services (MRXCLS et MRXNET) qui sont eux aussi invisibles dans la liste des services de Windows.

 Nota : Cette partie de l'installation ne fonctionne correctement que si l'utilisateur qui a branché la clé USB infecté utilise un compte ayant les droits administrateurs.

 Le rootkit installé par Stuxnet n‘est pas totalement furtif. En particulier, les fichiers suivants restent visibles depuis l'explorateur de fichiers sur un système infecté (cf. [IND]) :

%SystemRoot%system32driversmrxcls.sys
%SystemRoot%system32driversmrxnet.sys
%SystemRoot%infoem6c.pnf
%SystemRoot%infoem7a.pnf

 

Dialogue avec Internet

Une fois installé, le Stuxnet tente de contacter deux sites web sur Internet (cf. [SYM.03]), en utilisant des requêtes HTTP envoyées sur le port TCP 80 :

www . mypremierfutbol . com
www . todaysfutbol . com

Il envoie notamment à ces sites un message indiquant quelles sont les caractéristiques de la machine infectée (version de Windows, adresse IP, etc.) et peut recevoir en réponse des ordres tels que :

• Lire, écrire ou effacer des fichiers sur le PC infecté
• Télécharger un fichier DLL supplémentaire depuis Internet (download) et l’exécuter
• Etc.

On peut penser que lorsqu'un système SCADA est infecté, il y a peu de chance que ce système soit autorisé à dialoguer avec Internet. Cependant les pratiques à ce niveau sont très variables et dépendent fortement du niveau de protection de ce système. Il est donc possible que certains systèmes SCADA n'interdisent pas les communications sortantes ce qui rend possible le dialogue d'un système SCADA infecté par Stuxnet avec ces machines sur Internet. 

 

2. Les actions malveillantes vis-à-vis des systèmes SCADA

Stuxnet est conçu spécifiquement pour s'attaquer au produit SCADA Siemens SIMATIC PCS 7, et plus particulièrement au composant Siemens SIMATIC WinCC de ce produit.

Nota : WinCC est utilisé par plusieurs produits de Siemens, mais selon le constructeur, seuls les environnements PCS7 seraient visés par Stuxnet. Certaines sources (par exemple [ICS-01]) indiquent que le  produit STEP 7 de Siemens est également affecté mais la communication officielle de Siemens (cf. [SIE]) ne mentionne pas ce produit.

Il a été noté tout d'abord que certaines sections de code de Stuxnet lui permettaient d'interroger la base de données Microsoft SQL de WinCC. Il utilise pour cela un mot de passe SQL codé en dur dans WinCC et qui a été diffusé depuis plusieurs années sur un forum russe de hacking. Le but exact de ces requêtes SQL n'est pas connu. Il se pourrait que ces requêtes permettent à Stuxnet d'identifier d'autres machines sur le même réseau qui utiliseraient elles aussi WinCC (cf. [IND]).

Ensuite, Stuxnet recherche des fichiers particuliers sur le poste infecté comme par exemple des fichiers « *.s7p », « *.mcp », etc. (cf. [SYM-01]). Ces fichiers décrivent typiquement les équipements industriels  « PLC » (Programmable Logic Controllers), pilotés depuis le système PCS7 et les programmes de contrôle installés sur ces équipements.

Enfin, Stuxnet installe une DLL qui lui permet de contrôler tous les échanges que WinCC fait  avec les équipements industriels. Celle-ci intercepte tous les appels à la DLL Siemens “s7otbxdx.dll” qui est utilisée pour dialoguer avec les PLC afin de masquer les altérations qui auraient été apportées dans le code installé sur les équipements industriels. Il s'agit donc du premier cas de "rootkit" visant à dissimuler du code malveillant installé sur les PLC.

 

3. L'ampleur de l'infection

Siemens a indiqué qu'il avait connaissance en date du 24 août 2010, de 12 systèmes Siemens qui avaient été infectés par Stuxnet, mais qu'aucun de ces cas n'aurait eu de conséquences négatives (cf. [SIE]).

Plusieurs autres sources ont publié des estimations sur le nombre d'infections probables. Ils utilisent différentes méthodes de comptage telles que :

• Le nombre de tentatives d'infection bloquées par l'antivirus, une fois l'antivirus mis à jour pour détecter Stuxnet (ESET, Microsoft, Symantec).
• Le nombre de postes qui ont été désinfectés (Microsoft).
• Le nombre de machines infectées qui ont tenté de se connecter sur les machines C&C (Command and Control) sur Internet (Symantec).

Ces données ne sont pas totalement cohérentes entre elles (parce que les méthodes de comptage sont différentes et ont chacune leurs imperfections) mais convergent vers les constats suivants :

• Le nombre d'infections rapportées est de l'ordre de plusieurs dizaines de milliers de machines (par exemple 14 000 pour Symantec, 50 000 pour Microsoft). Il est très difficile de savoir combien parmi ces machines sont réellement des systèmes SCADA (car n'importe quel PC sur lequel une clé infectée est branchée sera infecté par Stuxnet) ni combien de systèmes SCADA isolés (ne pouvant pas communiquer avec Internet) ont été touchés.
• Les pays les plus touchés par les infections (en pourcentage de postes infectés, mais pas en nombre absolu d'infections) seraient l'Iran, l'Indonésie et l'Inde.

Il est curieux de constater un nombre aussi grand d'infections si l'on prend en compte les deux éléments suivants :

• Stuxnet est supposé se propager principalement par clé USB.
• Certains chercheurs (cf. [SYM-05] et [IND]) indiquent qu'il existe un compteur d'infection dans Stuxnet qui l'empêche de se répliquer au-delà d'une profondeur de 3 (le compteur serait décrémenté à chaque fois que Stuxnet  passe d'un ordinateur à l'autre, ou d'une clé USB à l’autre).

Donc soit le mécanisme visant à limiter la propagation de Stuxnet ne fonctionne pas correctement, soit le ver existe depuis longtemps et a été disséminé par le pirate à de nombreux endroits du globe.

Pour ce qui est de savoir depuis combien de temps Stuxnet existe, les éléments suivants montrent que le ver existe déjà depuis quelque temps :

• Certaines sections du code de Stuxnet sont datées de juin 2009 (cf. [SYM-04]). Le ver est donc en développement au moins depuis cette date.
• Plusieurs variantes de Stuxnet ont été trouvées, ce qui montre que le pirate a fait évoluer au cours du temps ce ver.  Par exemple dans certains exemplaires de Stuxnet les drivers sont signés par "Realtek Semiconductor Corp" alors que dans d’autres ils sont signés par "JMicron Technology Corp" (cf. cette annonce de ESET, qui donne cependant peu d'éléments démontrant qu'il s'agit effectivement d'une variante de Stuxnet). Il a également été trouvé des variantes de Stuxnet (probablement plus anciennes) qui n'utilisent pas la vulnérabilité .LNK pour se propager (cf. [SYM-04]). 

 

4. Les motivations des attaquants

Sur ce chapitre, on ne peut que spéculer ou émettre des hypothèses difficilement vérifiables.

Il parait certain que Stuxnet n'est pas le travail d'un individu isolé. Trop de composants ont en effet été réunis :

• Une connaissance pointue de l'environnement SCADA Siemens PCS 7.
• L'utilisation d'une faille 0-day permettant l'infection par clé USB.
• L'utilisation de certificats numériques volés à des sociétés légitimes.
• L'utilisation de techniques de piratage avancées (rootkit, interception de DLL,  communication via un serveur C&C, etc.).

Par contre ces différents éléments ont pu être achetés auprès de différents pirates (c'est une pratique courante).

 

Un second aspect est de savoir à quoi Stuxnet peut servir pour un attaquant. Les analyses qui ont été publiées font penser que potentiellement Stuxnet est capable :

• de voler des documents décrivant la nature de l'installation SCADA infectée et son fonctionnement interne,
• ou même de modifier le code installé sur les automates industriels à l'insu des propriétaires.

Cependant, il n’a pas été formellement démontré que les fonctionnalités de Stuxnet étaient parfaitement opérationnelles. Les éléments trouvés dans le code de Stuxnet sont peut-être simplement des embryons de fonctions ou des librairies non encore utilisés.

 

Enfin, pour ce qui est d'identifier le type d'attaquants qui serait responsable de la conception et de la diffusion de Stuxnet, les pistes suivantes ont été avancées ([cf. l'article Stuxnet: Dissecting the Worm publié par TechNewsWorld.com) :

• Un organisme gouvernemental menant une opération ciblée contre certains sites industriels. Dans ce cas la propagation massive de Stuxnet est une erreur.
• Un groupe terroriste
• Un groupe cyber-mercenaire cherchant à collecter des informations ou à prendre le contrôle de systèmes industriels pour ensuite revendre ces éléments.

 

 

5. Conclusions

La découverte de Stuxnet est un événement majeur pour les personnes s'occupant de la sécurité des systèmes industriels. Elle transforme un risque théorique connu depuis longtemps en une réalité technique indéniable. Le niveau de sophistication de l'attaque étonne et montre que le niveau de maturité des attaquants est aussi élevé dans le domaine SCADA que ce qu'il est dans l'informatique conventionnelle.

Il est certain que l'exemple de l'attaque Stuxnet va être examiné de façon approfondie par le monde de l'informatique industrielle afin d'identifier les moyens de protection contre ce type de menaces. Ces moyens de protection incluent des mesures de défense de premier niveau comme :

• Le contrôle des clés USB
• La suppression des comptes et des mots de passe par défaut

Mais elle nécessite aussi des mesures de défense en profondeur comme  :

• Le renforcement du niveau de sécurité des ordinateurs (le "hardening")
• Le filtrage des connections réseaux sortantes

Certaines sources (par exemple DigitalBond ou [IND])  recommandent également de mettre en place des mécanismes de type "Liste blanche" (permettant de définir de façon exhaustive la liste des exécutables autorisés à s'exécuter sur un système SCADA) ou de type HIDS (Host Intrusion Detection System). Le scellement des configurations avec des solutions de type Tripwire est probablement également une possibilité dans ce domaine.

 

Si les systèmes SCADA ont des contraintes bien différentes des systèmes IT conventionnels (par exemple en termes de durée de vie ou de fiabilité) ils ont cependant tout intérêt à tirer parti des efforts de sécurisation qui ont été faits dans le monde IT au cours de ces dix dernières années (comme par exemple le cloisonnement des réseaux, la sécurisation en profondeur, ou plus généralement la prise en compte plus systématique de la sécurité). Dans le cas de Stuxnet par exemple, le fait que Siemens utilise dans ses produits un mot de passe en dur et non modifiable (voir cet article sur la recommandation de Siemens de ne pas changer le mot de passe par défaut) montre que le niveau de maturité en sécurité des solutions proposées est encore trop faible. Parce que l'impact potentiel d'une cyber-attaque est majeure, les systèmes SCADA ont un besoin crucial de sécurité, ce qui implique des règles strictes de sécurité (en termes de conception aussi bien que d'exploitation) et une grande rigueur dans la mise en œuvre de ces règles. 

 

6. Pour plus d'information :

Page web officielle de Siemens à propos de Stuxnet:
[SIE] http://support.automation.siemens.com/WW/view/en/43876783

Document "The Stuxnet Worm and Options for Remediation" publié par Industrial Defender :
[IND] http://findingsfromthefield.com/?p=516

Analyses publiées par Symantec sur Stuxnet :
[SYM.01] http://www.symantec.com/connect/fr/blogs/w32stuxnet-installation-details
[SYM.02] http://www.symantec.com/connect/fr/blogs/distilling-w32stuxnet-components
[SYM.03] http://www.symantec.com/connect/fr/blogs/w32stuxnet-network-operations
[SYM.04] http://www.symantec.com/connect/fr/blogs/w32stuxnet-variants
[SYM.05] http://www.symantec.com/connect/fr/blogs/stuxnet-introduces-first-known-rootkit-scada-devices

 

Documents de l'ICS-CERT décrivant Stuxnet et les moyens de médiation
[ICS-01] http://www.us-cert.gov/control_systems/pdf/ICSA-10-238-01%20-%20Stuxnet%20Mitigation.pdf
[ICS-02] http://www.us-cert.gov/control_systems/pdf/ICSA-10-201-01C%20-%20USB%20Malware%20Targeting%20Siemens%20Control%20Software%20-%20Update%20C.pdf