Introduction à la sécurité SCADA

Hack in Paris c’est pour bientôt, histoire de vous remettre à jours avec certaines des conf présentées, je vous fait de nouveau profiter des articles ecrits par mes amis de Sysdream

Par Jean-Christophe Baptiste

Cet article a pour auteur Jean-Christophe Baptiste, consultant et formateur en sécurité informatique chez Sysdream. Sysdream est un centre de formation ainsi qu’un cabinet d’audit et de conseil en sécurité informatique. Jean-Christophe a aussi été responsable de la sécurité informatique d’une infrastructure industrielle, mais c’est avant tout un passionné que vous pouvez retrouver sur son blog.

Introduction

Scada, Stuxnet… Des mots qui ont largement fait le « buzz » depuis 2010, et continuent à faire froid dans le dos puisqu’ils font écho aux menaces sur les environnements informatiques industriels.

Mais au-delà du bruit médiatique, de quoi s’agit-il exactement ?

Au-delà du buzz

Tout d’abord, SCADA, pour Supervisory Control and Data Acquisition, est un terme utilisé abusivement pour désigner les équipements industriels.

Il ne s’agit que d’une brique fonctionnelle parmi d’autres, qui constituent une infrastructure industrielle. Bien d’autres acronymes pourraient être cités : PLC, DCS, RTU, DACQ, etc. Décrire chaque équipement dépasse le cadre de cet article, mais en gros à chaque équipement sa fonction : sonde de mesure, programmation et pilotage de robots, stockage et traitement des données, supervision, etc.

Nous retiendrons à ce stade le terme le plus approprié pour les désigner tous : ICS, pour Industrial Control Systems.

Les environnements industriels utilisent également des protocoles spécifiques, aux côtés d’autres, tout à fait standards : Modbus, OPC, Profibus, PI, etc.

Bref historique

Bon, cette petite mise au point faite, on n’est pas plus avancé. À quoi tout cela sert-il ? L’histoire est ici semblable à celle de bien d’autres activités humaines ayant connu l’avènement de l’informatique.

Autrefois, les usines étaient pilotées manuellement. On ouvrait des vannes par ici, on activait des interrupteurs par là, à la seule force des bras. Les mesures et les contrôles se faisaient à l’œil et reposaient sur le savoir-faire et l’expérience des opérateurs. L’avènement de l’électricité, puis de l’électronique, a amené un peu plus de confort et de précision : électrovannes, sondes de mesures, systèmes d’alerte, etc.

Ensuite, le développement de la micro-informatique a amené sa petite révolution. On a pu commencer à automatiser les chaînes de production tout en centralisant leur pilotage au sein de l’usine. Les différents équipements sont alors inter-connectés grâce à des réseaux primitifs, de type Bus ou série.

Enfin, le monde merveilleux du TCP/IP est passé par là. D’abord sous l’impulsion des intranets dans les entreprises, ensuite avec Internet et son ouverture sur le monde. Les opportunités sont énormes : rendre autonomes et intelligentes les chaînes de production, les optimiser à l’extrême, gérer les approvisionnements, remonter les informations commerciales, etc. Toutes ces données issues de la production alimentent les logiciels métiers et autres plateformes de gestion intégrée.

Les avantages surpassant les risques, de nos jours, la plupart des chaînes industrielles sont automatisées par des outils informatiques connectés au réseau. Cette évolution est certainement irrémédiable.

Technologies et vulnérabilités

Évoquons un peu les technologies sous-jacentes : vous croyez que ces systèmes sont complexes, spécialisés et complètement ésotériques ? Détrompez-vous ! En fait, vous allez probablement être un peu déçus. De nombreux systèmes sont de vulgaires ordinateurs d’architecture x86, fonctionnant avec un système d’exploitation de la famille Windows (XP, ou plus récent, ou plus ancien comme NT4 !). D’autres utilisent des systèmes Unix, comme Solaris par exemple. Pour les équipements plus limités en ressources, on retrouve même des systèmes tels que Windows XP Embedded ou autres versions mobiles.

En fait, tout dépend généralement du constructeur. Dans ce milieu, les contrats de support lient étroitement la partie matérielle et la partie logicielle.

D’autre part, il est rarement envisageable d’interrompre, ou risquer de perturber, une chaîne de production pour appliquer des correctifs de sécurité. Ainsi, au fil des mois puis des années, certains équipements sensibles se retrouvent complètement vulnérables, voire obsolètes.

Il y a aussi une part de vulnérabilités intrinsèques. Rappelez-vous, le monde de l’informatique industrielle appartient à une autre culture que la micro-informatique telle que nous la connaissons au quotidien, ouverte sur le monde et rompue aux problèmes de sécurité. Le milieu industriel est historiquement fermé et, avant tout, empreint d’une forte culture électrotechnique. Des problèmes, des priorités et des manières de penser différentes. Dès lors que les deux mondes se rencontrent et fusionnent, les mauvaises pratiques de sécurité et les failles applicatives jusque là tolérables prennent une autre dimension.

La défense

Ce qu’il faut retenir, c’est que l’axe offensif contre ces infrastructures n’a rien de « high tech ». Exploitant des vulnérabilités bien connues, les techniques d’attaque classique et les outils de hacking disponibles publiquement vont généralement fonctionner à merveille.

Que reste-t-il donc à la défense ? Il faut reconnaître que la tâche est ingrate face à des systèmes fragiles et quasiment intouchables. Là encore, les remèdes classiques ayant fait leurs preuves sont préconisés : sécurité périmétrique et filtrage, isolation maximum, sensibilisation du personnel, etc.

Le cas d’école : Stuxnet

Stuxnet est le premier logiciel malveillant connu du grand public, dont la cible était spécifiquement des installations industrielles. Une littérature abondante et très détaillée existe sur le sujet, mais essayons de résumer ce véritable fait de cyberguerre en quelques lignes. Dans un contexte géopolitique tendu, certains états occidentaux, États-Unis et Israël en tête, veulent à tout prix éviter que l’Iran développe ses capacités nucléaires dans le domaine militaire.

Une guerre conventionnelle n’étant pas envisageable, une attaque numérique va être lancée. Dans ce but, les États-Unis commencent probablement le développement de Stuxnet bien avant sa détection en 2010 (Symantec a retrouvé des versions primitives remontant à 2005). Le logiciel, après s’être installé sur des systèmes industriels à vocation de contrôle et de supervision, s’attache à perturber le fonctionnement des centrifugeuses chargées d’enrichir l’uranium (éventuellement pour un usage militaire).

En schématisant, Stuxnet provoque un emballement aléatoire des centrifugeuses, sans que rien n’y paraisse sur les écrans de supervision. Alors que les opérateurs ne soupçonnent rien, les tensions mécaniques ainsi provoquées induisent un taux de panne bien plus élevé que la normale. L’impact est important, mais contrôlé : la production d’uranium enrichi est ralentie. Le coût de production explose aussi : il faut remplacer les centrifugeuses, les démultiplier pour avoir un taux de production acceptable, et des heures de recherche ont probablement été dépensées en perte pour tenter d’améliorer leur fiabilité. Ainsi, Stuxnet est semble-t-il resté inaperçu pendant longtemps.

On imagine cependant que les installations de ces centres d’enrichissement étaient un minimum sécurisé et isolé des réseaux externes. Comment donc les services secrets ont-ils réussi à insérer la charge malveillante ?

Concernant le vecteur d’infection , rien de plus banal : une clé USB et un agent infiltré pour l’insérer dans un poste. Ensuite, tout est automatique. Le ver exploite certaines vulnérabilités alors inconnues de Windows (vulnérabilité dite « 0-day ») et d’équipements de contrôle Siemens.

Ce point amène des conclusions essentielles. Ainsi, les attaquants, très bien préparés, ont probablement passé de nombreux mois à construire et peaufiner leur attaque, en adéquation parfaite avec le matériel employé par leur cible. D’autre part, il est intéressant d’évaluer le coût global de l’opération. Les attaquants, une équipe de plusieurs personnes mobilisées pendant des mois, disposaient de moyens importants. Ils connaissaient les vulnérabilités des systèmes SCADA de Siemens et possédaient probablement du matériel de test. Ils ont été en mesure de réaliser des pilotes signés, se faisant passer pour leurs éditeurs légitimes (pilotes Realtek).

Enfin, considérez qu’une vulnérabilité « 0-day », surtout sur Windows, est un atout très précieux. Rare et difficile à découvrir ou obtenir, elle offre un gain important en l’absence de mesures correctives. Ainsi, certaines de ces vulnérabilités ont une très grande valeur, qui peut se monnayer en dizaines, voire centaines de milliers d’euros sur le marché noir.

Il ne fait aucun doute qu’une équipe disposant de trois de ces vulnérabilités sur Windows a non seulement des moyens très importants, mais des objectifs élevés pour les utiliser dans le cadre d’une seule opération – tout en les perdant à terme, car elles ne peuvent être utilisées qu’une seule fois.

En 2010 tout s’accélère. Stuxnet, dans sa forme actuelle, échappant à tout contrôle, se répand en plusieurs points du globe. Il est rapidement détecté puis analysé, et devient alors connu du grand public. Que s’est-il passé ?

Rien d’officiel, ni de complètement sûr, mais plusieurs analystes ont déduit de l’analyse du code de Stuxnet que les services secrets israéliens se sont probablement impliqués dans l’affaire. En ajoutant, un peu à la va-vite, des fonctionnalités offensives, certaines disparités sont apparues dans le code de Stuxnet : niveau de qualité, organisation, méthodes de programmation, présence de certains mots en hébreu, etc. Il est probable qu’à cette époque Israël ait souhaité des effets plus rapides et radicaux. La fréquence de stress des centrifugeuses est augmentée, provoquant des effets plus visibles en terme de panne. Mais cela signe aussi l’arrêt de mort de Stuxnet : analysé, décortiqué, il peut finalement être contenu puis éradiqué. Il est estimé que Stuxnet aura provoqué la destruction de 1000 centrifugeuses sur les 9000 que compte le site nucléaire de Natanz en Iran.

Un peu de mise en pratique

Il n’est pas facile de se procurer du matériel de test, surtout à moindre coût. À ce titre, un projet libre plutôt amusant a été publié récemment : Virtuaplant. Il s’agit d’un petit framework Python de simulation d’ICS (Industrial Control System). Développé en Python et dans une architecture modulaire, il ne demande qu’à être utilisé et complété. Pour l’instant, l’auteur fournit le modèle d’une chaîne de remplissage de bouteilles, avec une petite interface de supervision et de contrôle.

L’outil peut se télécharger à cette adresse : https://github.com/jseidl/virtuaplant.

Je vous conseille de le récupérer avec git :

git clone https://github.com/jseidl/virtuaplant.git

Avant de lancer l’outil, assurez-vous d’avoir bien installé les pré-requis tels que détaillés sur le site. Ensuite, à partir du répertoire d’installation, déplacez-vous dans le répertoire bottle-filling et exécutez le script permettant de lancer la chaîne de production :

cd ./virtuaplant/plants/bottle-filling

./start.sh

Si tout va bien, vous devriez obtenir quelque chose qui ressemble à cela :

Voilà, vous pouvez vous amuser à piloter votre usine. Observez les indicateurs de production, ils seront intéressants pour la suite.

Plaçons-nous du point de vue de l’attaquant. Ouvrez un analyseur de trafic comme Wireshark, qui intègre des dissecteurs adaptés à de nombreux protocoles. Ces dissecteurs permettent de décoder les trames brutes du réseau afin de présenter les informations des protocoles dans un format humainement lisible.

Rendez-vous dans le menu Edit > Preferences > Protocols > Modbus/TCP pour modifier la valeur du port TCP par défaut. Nous allons changer la valeur 502 par 5020, qui correspond au port utilisé par Virtuaplant (vous pouvez aussi éditer les scripts pour changer la valeur).

À présent, vous pouvez démarrer la capture du trafic sur l’interface lo0 (loopback) et observer le trafic Modbus correctement décodé :

En étudiant les trames Modbus, vous constaterez qu’il n’y a aucun mécanisme de chiffrement ou d’authentification. Comme cela fonctionne-t-il concrètement ?

Tout se passe dans le script hmi.py. Par exemple, le bouton Start provoque l’appel de la méthode setProcess :

runButton.connect(« clicked », self.setProcess, 1)

Dont voici le contenu :

def setProcess(self, widget, data=None):

try:

self.modbusClient.write_register(0x10, data)

except:

pass

La construction de la trame Modbus est ici gérée par la librairie Python éponyme. En gros, notre client Modbus (interface de pilotage) demande au serveur (robot de pilotage) d’écrire la valeur 1 dans le registre n°16 (0x10 en hexadécimal).

En utilisant le filtre Wireshark suivant, vous pouvez visualiser la concrétisation de ces ordres sur le réseau :

modbus.reference_num == 16

Résultat décodé dans Wireshark :

L’attaque est triviale : il suffit de rejouer la trame ou l’ordre vers le serveur pour interférer avec la production en cours.Voici un petit bout de code simplifié à l’extrême :

#!/usr/bin/env python

from pymodbus.client.sync import ModbusTcpClient as ModbusClient

client = ModbusClient(‘localhost’, port=5020) client.connect() client.write_register(0x10, 0)

On importe les librairies nécessaires, on se connecte sur le serveur et on écrit le registre 16 avec la valeur 0. Comme vous l’aurez sans doute deviné, la valeur 0 provoque l’arrêt de la chaîne.

Virtuaplant vient avec d’autres scripts de démonstration plus complets et, surtout, amusez-vous à développer les vôtres. Si vous le pouvez, je pense que l’auteur serait content de recevoir des contributions.

Conséquence d’une attaque « remplissage perpétuel » :

Voici pour finir une petite vidéo de démonstration pour la route :

Concernant Modbus, la protection n’est pas évidente. Sur des environnements maîtrisés, il sera envisageable de l’encapsuler dans un tunnel TLS (avec des outils similaires à stunnel), mais la plupart du temps l’environnement n’est pas facilement modifiable. Il faudra être donc très rigoureux sur l’isolation de ces dispositifs dans différents sous-réseaux et avec un empilement d’équipements filtrants (pare-feu, routeurs).