STUXNET : UN EXEMPLE D ATTAQUE CIBLEE

Transcription

1 STUXNET : UN EXEMPLE D ATTAQUE CIBLEE Nicolas Auclert, Pierre Brunetti, Guillaume Camera, Aurélien Chartier, Damien Letellier, Sandjeyaine Marday, Matthieu Martin 29/11/2010 Au cours de ce document, nous reviendrons sur le ver Stuxnet : aspect technique et impacts réels ; et nous essayerons de montrer en quoi il définit une nouvelle ère dans le domaine des attaques ciblées.

2 SOMMAIRE Introduction... 2 Timeline... 3 Analyse technique... 4 Introduction { l analyse technique... 4 Les Vulnérabilités exploitées par Stuxnet... 4 Vulnérabilité des systèmes Siemens... 4 L'exploit LNK... 5 Vulnérabilité Windows Spooler... 6 Héritage de Conficker et Vulnérabilités Reseau : NSF et RPC... 6 Vulnérabilité Win32k.sys... 7 Vulnérabilité 0-Day du Task Scheduler... 8 Fonctionnalités de Stuxnet... 8 Module Principal : User-Mode... 8 Modules complémentaires : Kernel-Mode Configuration et communication du ver Impacts Cibles présumées de Stuxnet Système Scada Les impacts réels Le nucléaire Iranien Signature numérique Conclusion Bibliographie SRS Day Page 1

3 INTRODUCTION Le 16 Juillet 2010, le bulletin de sécurité Microsoft contient l entrée : Microsoft Security Advisory ( ) de la vulnérabilité LNK. La vulnérabilité est exploitable à distance et critique. Dans les semaines qui suivent, les habituels vers opportunistes exploitant cette vulnérabilité de l affichage des icônes des raccourcis sous Windows sont lâchés dans la nature. L exploitation des failles publiées est une pratique courante pour les organisations malveillantes cherchant à prendre le contrôle de machines pour leurs comptes. Cependant la découverte «publique» de la vulnérabilité LNK en entraine une autre courant Juillet : la vulnérabilité a été exploitée bien avant le patch de sécurité. Stuxnet, un malware détecté le 17 Juin 2010 par VirusBlokAda, exploite la vulnérabilité un mois avant la parution du bulletin de sécurité! Les évènements et les découvertes s enchainent : Stuxnet apparait comme le ver le plus avancé jamais repéré, il serait le fruit d une attaque ciblée extrêmement bien préparée restée invisible jusque-là. Espionnage industriel, sabotage du nucléaire Iranien, Stuxnet ne laisse rien au hasard car son objectif n est pas d infecter l ordinateur lambda : il laisse de côté ce genre de machines afin de diminuer ses chances de détection et se focalise sur le système industriel SCADA de Siemens. De plus, contrairement à ce qu on a cru Stuxnet n exploite non pas une mais quatre vulnérabilités différentes de type 0-day! Stuxnet représente une prouesse organisationnelle et technique qui pose de sérieuses questions quand on sait que le nombre d attaques ciblées sur les entreprises est largement sous-estimé. Les victimes de ces attaques peinent à les détecter et plus encore à les reconnaitre publiquement espérant protéger leur image. Symantec produit chaque année ces chiffres et les attaques ciblées étaient encore en forte hausse en Les organisations criminelles et les agences gouvernementales étant ce qu elles sont : persistantes, résilientes et dotées de très gros moyens ; on peut raisonnablement affirmer que le phénomène n est pas prêt de s arrêter. Doit-on s inquiéter de la professionnalisation des attaques ciblées et de leurs proliférations? Quels sont les impacts visibles et discrets de Stuxnet? Quels mécanismes sont mis en œuvre et exploités par Stuxnet afin d arriver { ses fins et se répandre? Nous allons commencer ce document par une analyse technique de Stuxnet. Nous nous pencherons sur ses impacts dans un deuxième temps. On conclura sur les enjeux et la gravité des attaques ciblées passées et futures dont Stuxnet est devenu le dernier étendard médiatique en date. SRS Day Page 2

4 TIMELINE 17 Juin 2010: VirusBlokAda détecte Stuxnet sous forme des composants Trojan-Spy.0485 et Malware-Cryptor.Win32.Inject.gen, et décrit la vulnérabilité LNK. Cependant l industrie de la sécurité et Microsoft ne semblent rien remarquer. 24 Juin 2010: Le vol des certificats de Realtek Semiconductor est découvert. Ces certificats serviront à signer le malware avec des certificats valides et reconnus 15 Juillet 2010: Un ver utilisant la vulnérabilité est repéré «dans la nature». L US-CERT et l ICS-CERT publient des recommandations. 16 Juillet 2010: Microsoft confirme l existence de la vulnérabilité «CVE » sur les icônes des fichiers.lnk. Apparition de proof of concept exploitant la vulnérabilité. 17 Juillet 2010: Les certificats de Realtek sont révoqués et remplacés par un certificat JMicron dans le deuxième driver. 23 Juillet 2010: Les premiers vers grand public sont détectés. 2 Août 2010: Microsoft met à disposition le correctif de sécurité. SRS Day Page 3

5 ANALYSE TECHNIQUE INTRODUCTION A L ANALYSE TECHNIQUE En dehors de sa particularité d'être un virus ciblant les systèmes industriels de type SCADA 1, Stuxnet est également remarquable dans le fait qu il n exploite pas moins de quatre vulnérabilités Windows «0-day» (c'est à dire non corrigées au moment du lancement du virus), parmi lesquelles la fameuse faille LNK, dont l'existence a été particulièrement médiatisée dans la presse technique, mais également généraliste. On notera également que plusieurs de ces vulnérabilités affectent la totalité des versions de Windows, y compris Vista et Seven. L'utilisation de ces vulnérabilités permet à Stuxnet de disposer de plusieurs vecteurs de distribution. Le virus dispose également de plusieurs caractéristiques relativement communes des codes malicieux : code chiffré et offusqué, fonctionnalité contre les anti-virus, architecture modulaire et communication chiffrée. On retrouve également d'autres fonctionnalités moins courantes comme un mécanisme de désinstallation, un compteur d'infection. Enfin, d'autres éléments techniques sont peu communs : taille importante et plusieurs langages de programmation. En examinant les informations d'en-tête des fichiers, on note plusieurs signes montrant que l'attaque via Stuxnet a été préparée de longue date. On retrouve des drivers compilés en janvier 2009 et janvier 2010, tandis que les signatures numériques datent de janvier et février De plus, on trouve des informations montrant que les IDE Visual Studio 2005 et 2008 on été utilisés. Ces éléments pourraient indiquer que des équipes différentes se sont occupées des différents modules du virus, indiquant là aussi un degré de maturité peu commun pour un virus. LES VULNERABILITES EXPLOITEES PAR STUXNET Avant de nous pencher sur le fonctionnement de Stuxnet, établissons un panorama des vulnérabilités qu il a mis, ou remis, au goût du jour. VULNERABILITE DES SYSTEMES SIEMENS La vulnérabilité affectant les logiciels WinCC et Step7 de Siemens provient d'une erreur de génie logiciel dans l'authentification du logiciel auprès de la base de données SQL présente sur le serveur. Cette authentification se fait via un couple identifiant et mot de passe par défaut et qui ne peut être modifié. L emploi de mot de passe codé «en dur» peut s'expliquer par le fait que la sécurité est rarement prise en compte dans les systèmes industriels, qui sont supposés être isolés des autres systèmes. Or, cela est de moins en moins vrai. De plus, non seulement ce mot de passe est directement présent dans le code source des logiciels mais il renseigne également ces identifiants dans la base de données lors de l'installation. Par conséquent, la modification du mot de passe dans cette base de données empêchera les logiciels de Siemens de fonctionner 1 Supervisory Control And Data Acquisition : système de télégestion à grande échelle. SRS Day Page 4

6 Cette stratégie de sécurité par l'obscurité s'est retrouvée mise à mal depuis 2008 et la divulgation de ce couple d'identifiants (WinCCAdmin/2WSXcder) se retrouve maintenant sur de nombreux forums. Il est aujourd'hui possible de retrouver ce couple très facilement sur de nombreux sites répertoriant les mots de passe par défaut. L'exploitation de cette vulnérabilité permet donc un accès à toute donnée stockée dans la base SQL des logiciels Siemens (tel que le code de conceptions des automates par exemple), à partir d'un simple accès local sur la machine concernée. Malheureusement, Siemens ne fournit aucun correctif concernant la vulnérabilité touchant ses logiciels et rien ne permet d'affirmer que cela sera le cas dans le futur. L'EXPLOIT LNK La vulnérabilité LNK, qui a été de loin la plus médiatisée parmi les quatre 0-days utilisés par Stuxnet, permet au virus de se propager via les clés USB et les dossiers réseaux partagés. Les fichiers LNK Windows correspondent à des raccourcis et contiennent le chemin d'un fichier CPL (Control Panel File) qui est l'icône du fichier. Or, en réalité, un fichier CPL est une bibliothèque dynamique de type DLL. L'exploitation de la vulnérabilité consiste donc à renseigner le nom d'un fichier contenant le code viral comme fichier CPL. Lorsque le fichier LNK sera ouvert par l'explorateur Windows, le code malveillant sera ainsi exécuté. Une analyse de la chaine d'appels systèmes effectuée lors de l'ouverture d'un fichier CPL permet de se rendre compte que l'on finit par appeler la fonction LoadLibraryW, qui va charger la bibliothèque dynamique sans vérification supplémentaire. Si la vulnérabilité peut paraître relativement simple, il faut bien comprendre que des équipes nombreuses travaillent sur un projet de l'ampleur de Windows et que par conséquent des erreurs de design au niveau des chaînes d'appels de fonction peuvent apparaître. Microsoft a publié une mise à jour de sécurité le 2 août 2010, permettant de corriger la vulnérabilité LNK. La principale modification de cette mise à jour a été l'introduction d'une fonction _IsRegisteredCPLApplet qui va comparer le nom du fichier CPL à charger avec la liste des fichiers CPL valides, obtenue par un appel à CPLD_GetModules. Cette mise à jour apporte également une fonctionnalité permettant la désactivation complète de l'autorun hors CD et DVD. Une clé USB infectée par Stuxnet contiendra 6 fichiers : 4 raccourcis LNK et deux fichiers binaires ~WTR4141.TMP et ~WTR4132.TMP. Le premier fichier est chargé en tant que fichier CPL par les fichiers LNK et son exécution chargera le second fichier, qui contient le code viral. Les quatre fichiers LNK contiennent des liens symboliques vers des périphériques du type \Device\HarddiskVolumeX qui correspondent aux périphériques de stockage USB sur les systèmes Windows. Stuxnet utilise ces liens symboliques car il est impossible de déterminer à quelle lettre va correspondre la clé USB sur le système à infecter. Enfin, il y a quatre fichiers LNK qui vont cibler des versions différentes de l'os : un pour Seven, un autre pour Vista et les deux derniers pour XP, 2003 et SRS Day Page 5

7 VULNERABILITE WINDOWS SPOOLER Une autre vulnérabilité (bulletin de sécurité MS10-061) exploitée par Stuxnet provient du service Spooler d impression de Windows. Pour mieux la comprendre, voici comment celle-ci fonctionne : A la demande d impression d un client, le processus spoolsv.exe en charge de ce service lance une thread qui appelle la fonction de l API StartDocPrinter() en lui renseignant les paramètres suivants : typedef struct _DOC_INFO_1 { LPTSTR pdocname; LPTSTR poutputfile; LPTSTR pdatatype; } DOC_INFO_1; // Nom du document // Destination // Type de données La vulnérabilité venait du fait que la fonction appelée ne réalisait pas les opérations de vérifications de droit d accès dans le cas où la destination renseignée était un chemin vers un répertoire au lieu d un port de l imprimante. Ainsi il était possible d «imprimer» (comprendre écrire) des fichiers dans des répertoires normalement inaccessibles. L exploit réalisé par Stuxnet consiste { se connecter en tant qu utilisateur Invité (Guest) à une machine non-infectée et écrire par le biais de cette vulnérabilité deux fichiers : Windows\System32\winsta.exe et Windows\System32\wbem\mof\sysnullevnt.mof, opérations normalement non autorisées étant donnés les droits d accès restreints du compte Invité. Les fichiers.mof sont des fichiers permettant normalement de décrire des objets utilisés par le Windows Management Instrumentation (WMI), un système de gestion interne de Windows qui prend en charge la surveillance et le contrôle de ressource système. L exécution de ce fichier sysnullevnt.mof pouvait donc entrainer, sous certaines conditions, l exécution du fichier winsta.exe qui infectait { son tour le système jusqu ici sain avec Stuxnet. HERITAGE DE CONFICKER ET VULNERABILITES RESEAU : NSF ET RPC Stuxnet est aussi capable de se répliquer sur le réseau au travers de deux mécanismes empruntés au non moins fameux ver Conficker. Le premier utilise la vulnérabilité des dossiers partagés sur le réseau pour lesquelles la sécurité est trop légère (mot de passe faibles, retard sur les mises à jour de sécurité, ). Il scanne les partages réseau c$ et admin$ sur les ordinateurs distants, et y installe un fichier nommé DEFRAG<GetTickCount>.TMP, porteur du virus. Il planifie ensuite simplement l exécution de la tâche suivante le jour suivant en se connectant via DCERPC à l'interface \atsvc pour ajouter une nouvelle tâche planifiée via la fonction JobAdd: rundll.exe "C:\addins\DEFRAGdc2d0.TMP", DllGetClassObject. Qui résulte en l infection du nouveau système. SRS Day Page 6

8 L autre mécanisme de Stuxnet emprunté à Conficker est l exploitation de la vulnérabilité MS de Windows. Cette attaque commence par une négociation SMB (Server Message Block) avec une machine cible sur le port 445/TCP. Une fois la négociation terminée, le système attaquant lie le pipe SRVSVC et fait une requête NetPathCanonicalize qui embarque un shellcode, qui contraint la cible { se connecter { l attaquant et à télécharger la DLL infectée de Stuxnet. Le shellcode en question en profite bien évident pour lier la DLL au service système svchost.exe, et la rendre ainsi auto-exécutable. VULNERABILITE WIN32K.SYS Cette autre vulnérabilité «0 day» exploitée par Stuxnet (maintenant établie dans le bulletin de sécurité MS et corrigée), qui se trouvait dans le module win32k.sys était particulièrement dangereuse, puisqu elle lui permettait, s il n avait pas assez de privilèges pour s installer dans le système, de réaliser une importante élévation de privilège. Celle-ci se trouvait plus particulièrement dans le service système NtUserSendInput en charge du dispatch des entrées clavier. Effectivement, ce dernier exécute le code suivant : On voit qu il charge dans ecx une valeur située dans une structure pointée par eax (ligne 4) puis appelle une fonction (call, ligne 8) qui se trouve dans la table _anlsvkfproc à un index dépendant de ecx. En réalité, la structure pointée par eax est une structure située dans le keyboard layout file, un fichier en charge de déterminer la façon dont sont dispatchées les entrées clavier, et qui est modifiable par l utilisateur. Regardons de plus près la table _anlsvkfproc : On voit que celle-ci est constituée de trois entrées (en vert), et qu elle est suivie d une autre structure, _avknumpad, dont la troisième entrée (en rouge) peut être interprétée comme un pointeur vers 0x h en userland. SRS Day Page 7

9 La vulnérabilité venait du fait qu il n y avait pas de vérification sur la valeur chargée dans ecx (comme on peut le voir ici). Il était donc possible, en spécifiant une valeur appropriée, à savoir 5, de réaliser un call en userland { l adresse 0x h. Pour exploiter cette vulnérabilité, Stuxnet place dans un premier temps un shellcode chargé de l infection { l adresse 0x h dans son espace mémoire. Puis, exploitant MS10-073, il charge son propre keyboard layout file via la fonction NtUserLoadKeyboardLayoutEx, qui spécifie, pour certaines entrées clavier, un indice dans la table de dispatch (_anlsvkfproc) de 5. Rappelons que NtUserSendInput étant un service système, les fonctions qu il appelle sont exécutées en tant que SYSTEM, soit avec les privilèges les plus élevés. Le traitement des entrées clavier en question entraine donc l exécution du shellcode en mode SYSTEM, soit une infection inéluctable. VULNERABILITE 0-DAY DU TASK SCHEDULER La dernière vulnérabilité identifiée qui est exploitée par Stuxnet concerne le Planificateur de Tâches (Task Scheduler). Elle concerne les validations d accès et est liée au fait que le Planificateur n empêche pas les utilisateurs de manipuler certains champs dans les fichiers XML via les Component Object Model (COM), ce qui leur permettrait de contourner la protection CRC32 et d exécuter également du code arbitraire avec les privilèges SYSTEM. Cependant, peu d informations sont disponibles à ce jour sur cette vulnérabilité. Celles-ci sont effectivement gardées secrètes étant donné que la faille n a pas encore été rectifiée par Microsoft. FONCTIONNALITES DE STUXNET MODULE PRINCIPAL : USER-MODE Le module principal du ver se présente sous la forme d une bibliothèque dynamique (DLL) packée avec UPX, d une taille de 1,20Mo. Injection de code Stuxnet a la possibilité d injecter du code dans l espace d adressage d un processus et d exécuter ses fonctions exportées de deux manières différentes : dans un processus existant ou dans un nouveau processus. Dans le cas d un processus existant, pour éviter la détection par un anti-virus, le malware commence par allouer un buffer mémoire dans le processus existant afin d y stocker ses fonctions exportées, puis il change la dll système ntdll.dll pour modifier les fonctions utilisées par le noyau pour charger les drivers (ZwOpenFile, ZwCreateSection, ), pour les faire rediriger vers son code. Ainsi, lors d un appel { ces fonctions, c est le code placé par le ver dans l espace d adressage du processus qui sera appelé. Le ver fini donc par appeler ces fonctions avec une bibliothèque non existante, afin de réduire les chances de se faire repérer par un anti-virus. SRS Day Page 8

10 Dans le cas d un nouveau processus, le ver crée d abord un processus hôte, remplace l image de ce processus par son code et l exécute. Stuxnet choisit son processus hôte parmi une liste de processus prédéfinis : lsass.exe, avp.exe, mcshield.exe, avguard.exe, Installation Lors de l exploitation de la vulnérabilité LNK (CVE ), le ver modifie les fonctions suivantes afin de cacher ses fichiers sur une clé USB : dans kernel32.dll, FindFisrtFileW, FindNextFileW, FindFirstFileExW et dans ntdll.dll, NtQueryDirectoryFile et ZwQueryDirectoryFile. Les modifications de ces fonctions permettent au ver de masquer les fichiers.lnk d une taille exacte de 1471 octets et les fichiers.tmp dont le nom fait 12 caractères (de la forme ~WTRXXXX.tmp). Enfin, le ver charge son module principal (grâce aux méthodes expliquées dans la section précédente) et s exécute. Voici les détails de l installation du ver : Installation des drivers en kernel-mode (MrxNet.sys et MrxCls.sys) Installation de la bibliothèque principale (%SystemRoot%\inf\oem7a.pnf) Installation de la configuration du ver (%SystemRoot%\inf\mdmcpq3.pnf) Création de fichier de tracing (%SystemRoot%\inf\oem6c.pnf) Installation de fichier de données (%SystemRoot%\inf\mdmeric3.pnf) Injection de la bibliothèque principale dans services.exe et démarrage du serveur RPC Stuxnet. Injection de la bibliothèque principale dans s7tgtopx.exe et exécution de la 2 e fonction exportée (voir section suivante). Fonctions exportées Le ver Stuxnet exporte une trentaine de fonctions lui permettant de compromettre un système. Les fonctions 1 et 32 permettent de créer et de démarrer un serveur RPC Stuxnet. La fonction 2 modifie des fonctions exportées par kernel32.dll et ole32.dll. Les fonctions 4 et 18 nettoient entièrement la présence de Stuxnet d un système : elle restaure les dll modifiées, prévient l utilisateur de redémarrer afin de compléter la restauration de ces dernières, supprime les fichiers de configuration du ver et arrête les services installés par le ver. Les fonctions 6 et 7 indiquent la version de Stuxnet installée sur le système. Les fonctions 9, 10, 15, 16 et 31 lancent l installation du ver. La fonction 19 permet au ver de se propager via clé USB. La fonction 22 permet au ver de se propager via le réseau. Les fonctions 28 et 29 permettent au ver de communiquer avec des serveurs de configuration distants. Serveur RPC Stuxnet implémente un serveur RPC pour communiquer avec les autres instances du ver sur le réseau. Il est utilisé pour recevoir des mises à jour depuis les serveurs de configuration distants ainsi que depuis les autres instances du ver. Cela permet au ver de rester à jour même s il ne peut communiquer avec les serveurs de configuration. Le serveur RPC est séparé en deux composants : le premier pour recevoir les appels RPC depuis la machine locale (depuis les modules injectés dans les processus locaux), et l autre pour les appels distants (depuis le réseau). Ces deux composants exportent les mêmes fonctions : version du ver, chargement de modules, exécution d applications, suppression de fichiers, La mise { jour depuis les serveurs de configuration est détaillée dans la dernière section. SRS Day Page 9

11 Ressources Voici les ressources contenues dans le module principal de Stuxnet. ID Description 201 driver en Kernel-mode (MrxCls.sys) responsable de l injection de code dans les processus 202 Dll proxy 203 Fichier.cab contenant la dll principale 205 Données de configuration pour MrxCls.sys 208 Fausse s7otbldx.dll (module Siemens SCADA) 209 Fichier de données chiffré à stocker dans %WINDIR%\help\winmic.fts 210 Fichier PE de template servant à la construction du module d installation du ver (~WTR4132.TMP) 221 Module utilisé pour la distribution du ver par RPC 222 Module utilisé pour la distribution du ver par la vulnérabilité MS Fichier.LNK de template utilisé pour créer les fichiers exploitant la vulnérabilité LNK 241 ~WTR4141.TMP dll utilisée pour charger ~WTR4132.TMP et infecter le système 242 Driver en Kernel-mode (MrxNet.sys) responsable de l exploitation de la vulnérabilité LNK et de l infection du système 250 Module utilisé pour l élévation de privilèges (0-day de Win32k.sys) MODULES COMPLEMENTAIRES : KERNEL-MODE Le ver Stuxnet possède également les fonctionnalités d un rootkit : les deux drivers installés en kernel-mode (non packés et non protégés) lui permettent de masquer des fichiers et d injecter du code dans les processus du système. Ils sont signés numériquement (par Realtek et JMicron) ; ces certificats ont désormais été révoqués. MRXCLS.sys Ce driver a pour but d injecter du code dans l espace d adressage des processus du système, et se lance au démarrage de ce dernier. Certaines de ses données sont chiffrées grâce à un algorithme personnalisé. Ce driver enregistre une fonction appelée { chaque fois qu un module est chargé dans l espace d adressage d un processus. Le driver charge ses données de configuration depuis le registre, ou depuis un fichier s il n arrive pas { accéder au registre. Ces données spécifient quels modules doivent être injectés dans les processus du système, ainsi que les fonctions à appeler en fonction du processus compromis. Si le processus est en mode debug, l injection sera annulée. Lors du chargement en mémoire d un processus, le driver vérifie dans ses fichiers de configuration quels modules il doit lui injecter, et réserve deux buffers dans ce processus : l un pour le module, et l autre pour du code supplémentaire. Le driver remplace ensuite le point d entrée du processus par un autre pointant sur le code supplémentaire injecté. Le code supplémentaire redirige enfin le flot d exécution vers le module Stuxnet injecté, et le driver SRS Day Page 10

12 s occupe de restaurer l ancienne valeur du point d entrée du processus pour ne pas se faire repérer. MRXNET.sys Ce driver a pour but de masquer les fichiers utilisés pour propager le ver via clé USB et agit comme un driver «filtre» de systèmes de fichiers. Il s attache tout d abord { tous les types de systèmes de fichiers (ntfs, fat et cdfs) ; ainsi, lorsqu un nouveau système de fichiers est monté, le driver reçoit une notification et se place en haut de la pile des drivers, lui permettant ainsi de surveiller chaque requête adressée au système de fichiers. Cela lui permet de masquer certains fichiers.lnk et.tmp (voir section Installation) utilisés pour sa configuration, ainsi que sa propagation, en supprimant certaines entrées des résultats des requêtes aux différents systèmes de fichiers. CONFIGURATION ET COMMUNICATION DU VER Stuxnet conserve ses données de configuration chiffrées dans %SystemRoot%\inf\mdmcpq3.pnf. Elles contiennent les URL des serveurs de configuration, le temps d activation du ver, le temps de désactivation, sa version, ainsi que d autres informations concernant son fonctionnement et sa propagation. Les URL contenues dans ces données de configuration sont les suivantes : Les deux premières sont utilisées pour vérifier que le système est bien connecté à Internet, les deux dernières sont les adresses de serveurs de configuration. Une fois la connexion internet vérifiée, le ver envoie des requêtes par http sous la forme URL/index.php?data=données_chiffrées. Les données sont chiffrées suivant un algorithme personnalisé { l aide d une clé unique de 31 octets, et envoyées au serveur en Unicode. Ces données comprennent des informations sur les connexions réseau du système infecté (adresse MAC, adresses des DNS, ), sur la version du système d exploitation, ainsi que sur la configuration du ver. Certains octets sont réservés afin d indiquer si un logiciel Siemens est installé sur le système. Le serveur de configuration répond ensuite au ver en lui envoyant une image exécutable d une DLL, que le ver enregistrera et exécutera soit par RPC, soit par injection dans un processus (en fonction des flags envoyés dans la réponse du serveur de configuration). SRS Day Page 11

13 IMPACTS CIBLES PRESUMEES DE STUXNET Au cours des études approfondies de Stuxnet, les experts se sont mis d accord sur un point. Ce ver a été conçu dans le but de soutirer des informations aux entreprises utilisant les systèmes SCADA, particulièrement la suite logicielle proposée par Siemens WinCC. Les analyses ont montré que la découverte du mot de passe écrit en dur dans le code est utilisée pour récupérer des informations en base de données, qui peuvent être renvoyées n importe où. De plus, il apparaît que le ver est capable de fournir à l attaquant des moyens d injecter du code malveillant afin de détourner le comportement normal des processus effectués par les systèmes SCADA. Une fois en place sur un système SCADA, Stuxnet cherche { savoir s il a atteint sa cible. Si ce n est pas le cas, il reste latent sur le système. SYSTEME SCADA Supervisory Control and Data Acquisition est un système de contrôle et d acquisition permettant la gestion en temps réel à grande échelle des appareils de mesure et de contrôle à distance, d appareils et de machines industrielles. Cela permet concrètement de maîtriser et de superviser les outils métiers à distance. Aujourd hui ce genre de systèmes est utilisé entre autre pour : Les systèmes de gestion d eau L énergie électrique Les feux de signalisation Les systèmes de transit de masse Le contrôle des systèmes de fabrication Les enjeux du bon fonctionnement des systèmes SCADA est donc un point sensible puisque utilisés par des grosses industries telles que des centrales nucléaires. Ces systèmes sont responsables du transit d informations très sensibles pour certaines entreprises. Autant dire que la compromission de ces systèmes est d une criticité élevée. De par la définition même des systèmes visés par Stuxnet, il est relativement facile de penser que le développement de cette attaque permettrait de faire de l espionnage industriel et une démonstration de force de la part de ses auteurs. SRS Day Page 12

14 LES IMPACTS REELS Après un certain temps d exposition { ce virus, il apparaît que l Iran est le pays le plus touché avec plus de postes infectés. Dans les déclarations officielles du gouvernement relayées par plusieurs médias (lemondeinformatique.fr, The Jerusalem Post ), les impacts finaux du virus restent très maitrisés malgré la criticité des systèmes touchés. Aujourd hui, d après plusieurs analyses, la presse spécialisée ainsi que d autres médias ont abondamment diffusé que la véritable cible de Stuxnet était la centrale Iranienne d enrichissement d uranium de Bushehr. Ainsi ces attaques pourraient viser { ralentir la course de l'iran { l armement nucléaire. Pour l instant aucune preuve tangible n a pu être établie à ce sujet. LE NUCLEAIRE IRANIEN Plusieurs théories se croisent dont l une est qu Israël serait à l origine de l attaque. Le code malveillant est apparu dans de nombreux pays, notamment la Chine, l'inde, l'indonésie et l'iran. Mais il y a d importants soupçons du fait que le programme nucléaire de l'iran était la cible principale. Les officiels aux États-Unis et en Israël n'ont fait aucun secret sur le fait que saboter les systèmes informatiques qui contrôlent l'usine Iranienne d'enrichissement de Natanz était d une grande priorité. Le fait que Stuxnet semble conçu pour attaquer un certain type d'ordinateur de contrôle industriel Siemens, largement utilisé pour gérer les oléoducs, les réseaux électriques et de nombreux types de centrales nucléaires, peut être affirmé. L'an dernier à Dubaï a été saisi une importante cargaison de ces contrôleurs (connus sous le nom Simatic S-7). Les agences de renseignement occidentales ont dit que l'expédition était en partance pour l'iran et serait probablement utilisée dans son programme nucléaire. Ainsi, à partir de l'été 2009, les Iraniens ont commencé à avoir énormément de difficultés à gérer leurs centrifugeuses, les grandes machines argentées qui tournent à une vitesse supersonique pour enrichir l'uranium, et qui peuvent exploser de façon spectaculaire si elles deviennent instables. Pourtant, quelque chose (peut-être le ver ou une autre forme de sabotage : des pièces défectueuses ou une pénurie de techniciens qualifiés) pourrait en effet ralentir l'avance de l'iran. Les rapports sur l'iran montrent une baisse assez régulière du nombre de centrifugeuses utilisées pour enrichir de l'uranium à l'usine principale de Natanz. Cela représenterait une baisse de 23%. Dans le même temps, la production d'uranium faiblement enrichi est restée assez constante, ce qui indique que les Iraniens ont appris à mieux utiliser leurs machines de travail. Ces événements ajoutent une masse de soupçons, mais aucune preuve. Pour les agences de renseignement, l attaque informatique est une arme presque irrésistible, libre d empreintes digitales. Israël a versé d'énormes ressources dans l'unité 8200, son unité secrète de renseignement pour la guerre électronique. Les États-Unis ont renforcé leurs effectifs à l'intérieur de la National Security Agency et à l'intérieur de l'armée, qui vient d'ouvrir l unité Cyber Command chargée de la sécurité de l'information pour l'armée. SRS Day Page 13

15 SIGNATURE NUMERIQUE Mais finalement, d autres préoccupations naissent à partir de ce nouveau virus. Tout d abord, l usurpation de l identité de Realtek pour la signature numérique. Le système de signature électronique n est peut-être pas à remettre en cause. Certains principes de précaution devraient par contre être pris en compte. Le principe de signature numérique de Realtek est basé sur de la cryptographie asymétrique. C'est-à-dire que le constructeur dispose d une paire de clés, l une publique et l autre privée. En tant que constructeur, il est le seul { connaître cette dernière. La première, au contraire, doit, par définition, pouvoir être connue de tous. Pour cela, le constructeur demande un certificat numérique auprès d une autorité de certification (Verisign), qui publie ce document liant la clé publique { l identité du constructeur. Le principe de cette cryptographie asymétrique est que ce que l on chiffre avec une des clés de la paire doit être déchiffré avec l autre. Sachant qu il est impossible (c'est-à-dire irréalisable de manière pratique) de découvrir la clé privée à partir de la seule connaissance de la clé publique. Pour réaliser une signature, le constructeur fait une empreinte du pilote qu il chiffre avec sa clé privée. Ainsi, pour vérifier qu'un driver vient bien de chez le constructeur, il faut d'une part en calculer le hash et parallèlement, déchiffrer la signature avec la clé publique. Si les deux résultats (hash du driver et déchiffrement de la signature) sont égaux, c'est que le driver n a pas été modifié et qu'il vient bien du constructeur. En volant la clé privée, ou en trompant le constructeur pour s immiscer dans son processus de signature, ou encore en découvrant la clé privée si sa longueur est trop faible, il est possible donc de produire une vraie fausse signature. C est ce que Stuxnet a fait en utilisant son propre pilote de périphérique, technique classique donc, mais cette fois ci signée par Realtek. L élément qui inquiète le plus est la finalité des attaques provoquées par le virus. En effet, ce virus rentre clairement dans la catégorie de l espionnage industriel, par le fait de la récupération des informations confidentielles de l entreprise victime. De plus, des aspects de ce virus permettent le détournement du comportement natif de certains systèmes, ce qui est clairement indicatif d une volonté de détruire. A la vue de l ampleur du champ d attaque, l inquiétude grandit dans les esprits concernant les méthodes d attaques et d infection futures qu inspireraient Stuxnet. Les programmeurs de ce virus ont démontré une capacité { s en prendre à des plateformes industrielles et à pouvoir les détruire. Malgré un impact maitrisé, les inquiétudes se portent aujourd hui sur les attaques de demain. SRS Day Page 14

16 CONCLUSION L intelligence économique a été définie en France par le rapport Marte en 1994 : «L intelligence économique peut être définie comme l'ensemble des actions coordonnées de recherche, de traitement et de distribution, en vue de son exploitation, de l'information utile aux acteurs économiques». Cette notion est trop souvent confondue avec l espionnage industriel auquel elle emprunte un certain nombre de démarches et effraie encore certaines entreprises. Les experts s accordent pour dire qu elle regroupe trois axes principaux : la veille (acquisition de l information brute), la protection des informations (dissimulation des actifs critiques) et l influence (propagation volontaire et stratégique d informations). L axe le plus critique, surtout dans le cadre de notre article est la veille. Son but étant de surveiller tous les flux d informations accessibles légalement, dans l optique de récupérer de l information brute puis d en extraire les informations pertinentes sur lesquelles pourront se baser la stratégie de l entreprise. Le «problème» qui résulte de rester dans le cadre de la légalité est que les uniques informations accessibles sont celles considérées comme blanche (publiée par les canaux classiques et accessible directement par les moteurs de recherche) ou grise (publiée dans les articles de recherche, papiers techniques et accessible via des canaux spécialisés). Cependant ces deux catégories représentent respectivement 80% et 15% de l information mondiale et suffisent généralement pour aider l entreprise dans sa prise de décisions. Enfin l information noire est protégée par des secrets. Pour la consulter, il est devient donc obligatoire d enfreindre la loi, on passe alors dans le registre de l espionnage industriel. L accès { une grande majorité des informations est cependant possible sans en arriver { violer des règles, le veilleur se servant principalement de l information grise pour obtenir une bonne image globale. Plusieurs solutions sont possibles pour atteindre ces fameux 5%. Directement issu des méthodes pré-ère informatique, on trouve le social engineering qui consiste à exploiter l aspect humain de l entité visée, en utilisant notamment le fait que l utilisateur lambda sousestime totalement la criticité du système d information. A l opposé, la solution la plus technique est l attaque ciblée. L attaque ciblée est un type de cybercrime utilisant différentes techniques voire un malware dans l objectif de s attaquer { une entité bien précise. L idée derrière étant de limiter la propagation de l attaque pour diminuer les chances de détection, notamment par les honey pot des sociétés de protection. L attaque ciblée la plus courante { l heure actuelle est l attaque par déni de service distribuée (DDOS). Son objectif est la mise hors service d une partie du système d information de l organisation ciblée en dépassant ses capacités. Les chiffres tirés du dernier dossier de McAffee «In the Crossfire: Critical Infrastructure in the Age of Cyber War» sont assez alarmants. En France par exemple, 80% des entreprises interrogées reconnaissent en avoir subies dans l année passée, et 10% d entre elles en sont { plusieurs par jour. Tous les Etats sont bien entendus concernés par ces problèmes. Le coût moyen qu entrainerait une journée complète de coupure des services est estimé par les entreprises interrogées à 6.3 millions de dollars. L attaque par DDOS est d autant plus utilisée qu elle est extrêmement facile à mettre en place, difficile à retracer et impossible à prévenir. SRS Day Page 15

17 On passe { un autre niveau quand le but n est plus de mettre hors service ou de déranger le fonctionnement de l entité ciblée, mais la récupération des fameuses informations noires. Les techniques qui s attaquent { la partie externe du système d information fonctionnent très bien (scan des ports, empoisonnement du DNS ) et permettent d intercepter les données lors d un transfert. Mais il devient parfois nécessaire de s infiltrer { l intérieur du réseau. Dans ce cas, il est nécessaire d exploiter une faille de sécurité. La plupart des grosses entreprises appliquent les patchs et bloquent les menaces en suspens dès qu elles sont découvertes, c est pour ça que la notion de faille 0-day est si importante. Malgré que la découverte d une nouvelle faille de sécurité exploitable soit extrêmement difficile, les menaces qui entourent ces attaques sont bien réelles et chaque année quelques cas permettent de le rappeler. Ce fut bien entendu le cas avec Stuxnet cet été 2010, mais l exemple de Google en décembre dernier est aussi un excellent représentant de ce risque. L attaque sur Google a commencé mi-décembre et la société a rapidement reconnu qu elle avait en partie réussie. Elle utilisait une faille 0-day d Adobe Reader, exploitée par un PDF corrompu envoyé par mail. L objectif était double : la récupération de code appartenant à Google ainsi que le contenu d un certain nombre de boîte Gmail. Au final, une partie du code a bien été volée mais seules les informations non confidentielles de deux boîtes mails ont été récupérées. Il s est avéré que l attaque était bien plus violente que prévue, avec 34 sociétés ciblées. L attaque a rapidement fait débat puisqu il a été prouvé qu elle venait de Chine. Cela a pu être confirmé par Google qui a annoncé que les deux comptes attaqués appartenaient { des activistes chinois. Il n a cependant jamais pu être prouvé que l Etat était impliqué dans l attaque. Il n est pas étonnant que le gouvernement ait été soupçonné, c est une autre constatation que l on retire du document de McAffee : 60% des sociétés interrogées estiment qu un gouvernement étranger a été { l origine d une ou plusieurs attaques ciblées sur eux. Cependant Stuxnet est bien supérieur { la menace qu a subie Google. C est un ver d une taille extrêmement importante qui a nécessité plusieurs développeurs, une longue période de développement et plus d un langage de programmation. On parle donc ici d une attaque préparée depuis longtemps, et qui est certainement due { l action de plusieurs entités distinctes. Stuxnet utilise en plus 4 failles 0-day différentes, ce qui est une grande première, ce qui a assuré le bon fonctionnement de son attaque et qui lui promet dès aujourd hui de marquer une étape dans l historique des malwares. Effectivement, et c est sans doute la principale particularité de ce malware, c est qu il a redéfini et prouvé que l utilisation d un ver pouvait fortement réussir à condition qu on lui attribue les moyens d un vrai projet. Pour les sociétés et leurs responsables sécurité, c est donc une menace bien plus inquiétante qu il faudra prendre en compte dorénavant. SRS Day Page 16

18 BIBLIOGRAPHIE Article d Eset sur Stuxnet : «Stuxnet under the microscope» Article de McAffee sur le danger des attaques ciblées : «In the Crossfire: Critical Infrastructure in the Age of Cyber War» (nécessite une inscription) Article du CERT LEXSI sur la correction de la vulnérabilité LNK par Windows Articles du New York Times concernant Stuxnet index.html Article de Craig Shrimpton concernant la perte de confiance dans les signatures électroniques Article publié sur le blog de Google concernant l attaque ciblée subie en Décembre SRS Day Page 17