Un rapport du consultant Digital Bond affirme qu'un bout de code du logiciel CoDeSys tournant sur des automates programmables industriels (API) de plus de 200 vendeurs comporte une vulnérabilité qui permet à des pirates potentiels d'exécuter des commandes sensibles sans avoir à s'authentifier. La vulnérabilité a été découverte par Reid Wightman, un ancien chercheur de Digital Bond, qui travaille pour le projet de recherche Basecamp sur la sécurité des systèmes de contrôle lancé par Digital Bond l'an dernier. La vulnérabilité, qui, selon le chercheur, serait due à un problème de conception, se trouve dans le runtime CoDeSys, une application qui tourne sur les contrôleurs à logique programmable (PLC) des appareils. Les PLC sont des ordinateurs numériques qui contrôlent et automatisent des processus électromécaniques dans les centrales électriques, les raffineries de pétrole et de gaz, les usines et autres installations industrielles ou militaires. Le runtime CoDeSys permet aux PLC de charger et d'exécuter des fichiers dits d'instructions « ladder » créés à l'aide du kit de développement CoDeSys sur un ordinateur courant. Ces fichiers contiennent des instructions qui modifient les processus contrôlés par ces automates. Selon le rapport de Digital Bond, le runtime CoDeSys ouvre un port d'écoute TCP qui permet d'accéder à une interface de commande en ligne sans avoir besoin d'authentification.

Deux scripts développés pour exploiter la faille

Le consultant a mis au point et publié deux scripts écrits en langage Python. L'un peut être utilisé pour accéder à l'interface de commande en ligne et l'autre est capable de lire ou d'écrire des fichiers sur un automate exécutant le runtime CoDeSys. Digital Bond prévoit de convertir ces scripts en modules pour Metasploit, un framework utilisé couramment pour effectuer des tests de pénétration. Selon le modèle de contrôleur à logique programmable, l'interface de commande en ligne permet à un attaquant potentiel de démarrer, d'arrêter et de réinitialiser les programmes PLC ; de vider la mémoire de l'automate, ou d'obtenir des informations sur les tâches et les programmes en cours d'exécution sur l'automate ; de copier, de renommer, de supprimer des fichiers sur le système de fichiers de l'automate ; de définir ou de supprimer les mots de passe d'accès en ligne et plus encore. CoDeSys est développé par 3S-Smart Software Solutions, un éditeur basé à Kempten, en Allemagne. Selon le site web de l'entreprise, leur logiciel est utilisé par les systèmes d'automatisation de plus de 200 fabricants.

Comme l'a déclaré dans un blog Dale Peterson, fondateur et CEO de Digital Bond, « la vulnérabilité et les scripts ont été testés sur une dizaine de matériels parmi les produits de 261 fournisseurs susceptibles d'être concernés ». L'un des contrôleurs à logique programmable testé tournait sous Linux sur un processeur x86, tandis qu'un autre tournait sous Windows CE sur un processeur ARM. « L'attaque peut être utilisée non seulement pour contrôler le PLC, mais aussi pour transformer l'automate en « vecteur » pour attaquer d'autres appareils sur le réseau », a déclaré par courriel Ruben Santamarta, consultant en sécurité pour IOActive. Dans le passé, également dans le cadre du projet Basecamp, celui-ci avait déjà identifié des vulnérabilités dans les systèmes de contrôle industriels. « Nous sommes conscients de ce problème de sécurité », a déclaré par courriel Edwin Schwellinger, responsable du support technique de 3S-Smart Software. « Un patch est en cours de développement, mais nous ne l'avons pas encore livré. Nous sommes très impliqués pour résoudre ces problèmes au plus tôt ».

Une attaque interne uniquement

Selon lui, « la vulnérabilité n'est exploitable que par un attaquant ayant déjà accès au réseau sur lequel tourne le runtime PLC » et que « les runtime ne devraient pas être accessibles depuis Internet si on a ajouté une protection additionnelle ». Reid Wightman, qui travaille actuellement comme consultant pour IOActive, a confirmé via Twitter que « seul un petit nombre de systèmes CoDeSys étaient exposés à Internet. Certains pouvaient être trouvés via le moteur de recherche Shodan et d'autres en faisant un scan personnalisé ». Mais selon lui, « en aucun cas un PLC ne devrait être accessible via Internet ». Cependant, « de nombreux réseaux sont compromis par des menaces persistantes avancées - des logiciels malveillants qui permettent aux attaquants d'avoir accès au réseau local - et dans ces cas-là, le périmètre n'a plus d'importance », a-t-il dit. « Autant que possible, il faut éviter d'exposer les PLC et les réseaux PLC à des réseaux publics et à Internet », a insisté le responsable technique de 3S-Smart Software. « Les clients doivent utiliser des couches de sécurité supplémentaires comme des réseaux privés virtuels (VPN) pour l'accès à distance, ils doivent installer des pare-feux et restreindre l'accès aux réseaux sensibles aux personnes autorisées », a-t-il encore recommandé.

« Tout ce qui touche au système SCADA est très sérieux », a déclaré pour sa part par courriel Luigi Auriemma, chercheur pour l'entreprise de sécurité ReVuln, qui a déjà trouvé et révélé des vulnérabilités sur les systèmes de télésurveillance et d'acquisition de données SCADA utilisés pour le contrôle à distance d'installations techniques. « Si vous pouvez contrôler le PLC, vous pouvez contrôler l'infrastructure ». Par exemple, c'est en infectant les contrôleurs à logique programmable de l'usine d'enrichissement nucléaire iranienne de Natanz, que le malware Stuxnet a réussi à modifier leur programmation et à détruire environ 1000 centrifugeuses d'enrichissement d'uranium. Selon certains, l'attaque aurait retardé le programme nucléaire iranien de deux ans.

Heureusement, les vendeurs peuvent mettre en oeuvre des solutions de contournement en attendant un patch officiel. « Les scripts d'attaque ne fonctionnent pas sur le produit d'un vendeur au moins, qui souhaite rester anonyme », a indiqué Dale Peterson. « Celui-ci a adopté un cycle de développement SDL pour la réduction des vulnérabilités logicielles et l'atténuation des menaces. Il a identifié la menace que pouvait représenter le chargement d'une instruction « ladder » malveillante et celle d'autres malware, et a constaté qu'elle n'était pas bloquée par le runtime CoDeSys. Il a donc ajouté une « couche de sécurité » autour du runtime. Par conséquent, l'utilisateur ou l'attaquant doit obligatoirement s'authentifier pour accéder au port sur lequel tourne CoDeSys ». Pour ce qui est des autres produits affectés, « les utilisateurs peuvent procéder à une segmentation du réseau, ajouter des listes de contrôle d'accès, des pare-feu et des systèmes de prévention des intrusions », a déclaré Ruben Santamarta.