Prendre le contrôle (Pwn) d’un poste électrique à haute tension ?!

Introduction

DISCLAIMER :

⚠️ Pour des raisons évidentes de confidentialité, nous ne citerons ni le client, ni le lieu et nous n’utiliserons (presque) pas de photo dans cet article. ⚠️

Notre Squad ZenSec a eu l’opportunité de challenger la sécurité d’un lieu un peu atypique mais on ne peut plus intéressant: un poste à électrique à haute tension.

L’objectif principal du client était de répondre à la question suivante :

Est-ce qu’un attaquant, avec plus ou moins de compétences en matière de cybersécurité, en capacité de s’introduire temporairement dans les locaux pourrait occasionner comme dégâts sur un tel type d’infrastructure ?

Vous allez voir qu’il n’y a pas forcément besoin d’être un crack en cybersécurité pour causer de sérieux problèmes.

Scénarios d’attaque

Au vu de la sensibilité de ce type d’infrastructure, les scénarios envisageables sont multiples :

• Un prestataire qui aurait accès au site qui profiterait d’un moment d’inattention pour déposer une backdoor
• Un groupe de hacktivistes qui souhaiterait plonger la ville dans le noir en guise de protestation et qui parviendrait à mettre un pied dans le périmètre
• Pourquoi pas, un adolescent un peu curieux qui aurait terminé le visionnage de la dernière saison de Mr Robot et qui souhaiterait se frotter à la réalité
• Une APT (Advanced Persistent Threat) qui chercherait à mettre à mal une infrastructure vitale pour la France

Contexte de la mission

Après différents échanges avec notre commanditaire nous avons choisi l’approche suivante :

• La mission impliquera la totalité de la Squad sur une durée de 5j soit 4 personnes avec des compétences en matière de test d’intrusion, d’intrusion physique mais peu de compétences en systèmes industriels.
• Le périmètre sera le poste de contrôle dédié aux opérateurs techniques qui comprend :
  • les armoires intégrant les différents équipements réseau et électriques
  • ainsi que tous les ordinateurs et serveurs présents sur le site.
• Il y aura également un opérateur présent avec nous qui nous laissera en autonomie en premier temps, puis qui sera en mesure de répondre à nos questions par la suite.
• Le contournement des sécurités extérieures (murs avec barbelés, caméras de surveillance) ne fera pas partie de l’intervention.
• Aucunes informations ne seront fournies à propos du site et de son infrastructure technique. Celles-ci nous seront distillées au fur et à mesure de l’avancement de la mission.
• Pour des raisons évidentes, notre poste électrique est isolé du réseau électrique de la ville pour que nos actions n’aient pas de conséquences malencontreuses. Il fonctionne cependant normalement, comme s’il était connecté à celui-ci.

Show time

Pour la Squad, l’objectif premier est relativement simple : comprendre au maximum dans quelle  ̶g̶a̶l̶è̶r̶e̶ ̶ contexte nous sommes ici, comment s’articule ce poste de contrôle, qu’est-ce qui se passe sur le réseau et surtout comment nous allons pouvoir interagir avec tout cela !

Une fois le poste de contrôle exploré, nous identifions plusieurs “tranches” (une armoire en somme) comprenant des équipements nécessaires au bon fonctionnement du réseau électrique qui ne nous parlent pas franchement. Par contre, nous reconnaissons tout ce qui semble constituer de quoi construire un réseau classique sur TCP/IP, à savoir des switchs et ce qui ressemble à des routeurs / firewall.

Il y a également une baie qui semble contenir des PC fixes ainsi qu’une baie de brassage fermée à clé.

Ouf ! Il semblerait que nous allons nous frotter à un réseau TCP/IP on ne peut plus classique.

Ni une ni deux, on se lance : l’armoire principale étant ouverte pour le bon déroulement de nos tests (vous verrez plus bas que même si elles étaient verrouillées ça n’aurait pas été un problème 😉), on identifie des switchs et des routeurs. On finit par trouver quelques prises libres qui ne semblent pas brassées et/ou verrouillées… Et oui, un réseau industriel n’est pas vraiment conçu pour recevoir de nouveaux dispositifs sur le réseau sans que ce soit “prévu”. Il va donc falloir débrancher un équipement et prendre sa place sur le switch. Nous avions anticipé cette possibilité et c’est avec un simple commutateur que le tour est joué !

Heureusement pour nous, il semblerait qu’il n’y ait pas vraiment d’authentification sur le switch. Pas de 802.1x ou autre mécanisme.

Comme vous l’imaginez, il n’y a pas non plus de DHCP qui tourne. C’est donc à nous d’identifier et de comprendre l’adressage en place.

Ici, c’est avec Wireshark, en écoutant ce qu’il se passe sur le broadcast, que nous avons pu découvrir plusieurs choses: il semblerait qu’il y ait un protocole qui flood le réseau “GOOSE” mais également quelques paquets avec une étiquette pour un VLAN.

Le protocole GOOSE est un protocole que l’on retrouve fréquemment dans les réseaux industriels et il sert ici à alimenter l’IHM utilisée par les ingénieurs avec les informations remontées par les automates.

À ce moment-là, notre premier objectif est rempli : nous nous attribuons une adresse IP, nous créons ensuite notre interface virtuelle dans le bon VLAN, puis nous paramétrons notre passerelle réseau et … miracle, ça fonctionne.

Cette étape clé nous permet de dérouler notre test d’intrusion de manière un peu plus “traditionnelle”. On dégaine les “nmap” et on commence à cartographier notre réseau, qui s’avère contenir un paquet d’équipements et de services :

Des interfaces WEB de configuration d’équipements, un serveur NTP mais aucune trace des PC fixes que nous avions aperçus dans une baie. Nous savions également que ceux-ci étaient sur Windows et permettaient aux opérateurs de surveiller le réseau et de mettre en œuvre les actions nécessaires.

À ce stade, nous nous répartissons les tâches. Certains vont s’atteler à l’attaque du réseau découvert et découvrir pas mal de vulnérabilités : des mots de passe de configuration par défaut, des dénis de services, des absences de contrôle d’accès, etc. D’autres vont tenter de comprendre où se cachent les ordinateurs Windows utilisés par les opérateurs !

Nous prenons conscience de beaucoup de choses tandis que nous explorons un peu plus le site. En effet, les grosses armoires qui contiennent les équipements (les fameuses “tranches”) sont protégées par une clé, sauf que malheureusement l’empreinte de la clé est générique et un passe-partout fera l’affaire…

Le constat est le même en ce qui concerne les accès aux disques durs des PCs opérateurs : la protection est une serrure très basique que l’on crochète en quelques secondes pour la démonstration. Après quelques discussions avec l’opérateur présent pendant notre intervention, il nous confirme bien que les disques durs ne sont pas chiffrés.

D’ailleurs, tiens, nous n’avions pas remarqué qu’il y avait des étiquettes dans cette armoire avec des… adresses IP !

Bigre, celles-ci ne semblent pas du tout correspondre avec le réseau que nous avions précédemment découvert en 192.168.X.X et celui-ci est en 10.X.X.X. Ceci explique cela : il y a bien deux réseaux distincts qui sont utilisés dans cette architecture.

Bon et bien, on va suivre le câble qui est branché et identifier un autre switch. Nous nous branchons donc dessus, nous nous attribuons une adresse dans le dit réseau… Je crois que vous connaissez la suite ! Non ? Vous ne l’avez pas ? Eh bien il s’avère qu’on se retrouve sur le fameux réseau en 10.X.X.X

D’ailleurs, on découvrira plus tard que ces deux réseaux communiquent bien entre eux (logique me direz-vous). On ajoute une route vers celui-ci sur nos machines afin de pouvoir directement interagir avec lui sans avoir besoin de se brancher au switch.

Les jours passent, notre connaissance du lieu s’accroît et nous nous y sentons de plus en plus à l’aise. Notre cartographie est prête et nous consacrons davantage de temps à notre réseau de postes Windows.

• On commence à MiTM (Man In The Middle, autrement dit on se positionne entre le routeur et la cible),
• et avec notre “Responder” (Si si vous savez, ce magnifique outil en python qui permet de faire du LLMNR, NBT-NS et MDNS poisoning 😉. Entre d’autres termes vous allez répondre à toutes ces requêtes en disant “coucou c’est moi”) (*), on arrive à capturer des hashs NTLM (New Technology LAN Manager).
• Malheureusement pour nous, le SMB (Server Message Block) signing est activé : on ne va pas pouvoir aller beaucoup plus loin puisque cette protection ne nous permettra pas de rejouer les hashs…

(*) Si vous n’avez pas compris la totalité de ces termes, découvrez nos formations Zenika 😉

On va également tenter un MiTM sur un équipement de protection électrique pour voir comment il discute avec le réseau. Au-delà du fait qu’il n’a pas vraiment apprécié l’exercice, puisqu’il a tout bonnement crash (hop, une vulnérabilité supplémentaire !) nous avons pu confirmer ses échanges en GOOSE et comprendre qu’il s’agit d’un protocole industriel permettant aux équipements de remonter les informations vers les postes des opérateurs.

Pour y voir plus clair, je vous propose un résumé des informations dont nous disposons :

• Il existe deux réseaux, mais ils communiquent entre eux donc rien de bien contraignant.
• Chaque armoire représente une “tranche” et contient des équipements électriques ainsi qu’un switch.
• Il y a une armoire “master” qui contient nos PCs opérateurs, sous Windows, mais également les switchs qui distribuent le réseau auprès des tranches sur lesquelles nous sommes branchés, ainsi qu’un routeur qui orchestre tout cela.
• Les équipements remontent leurs données aux postes opérateurs à travers un protocole “GOOSE” qui d’ailleurs n’est pas du tout chiffré.

Nous sommes quasiment au bout de notre aventure. L’objectif pour nous est désormais de prendre le contrôle d’un équipement électrique et de pouvoir manipuler son paramétrage et ses valeurs.

En nous documentant peu sur le modèle en question, nous découvrons qu’il existe un logiciel permettant de discuter avec les équipements électriques (il y avait d’ailleurs une référence à ce logiciel sur une des interfaces web mais nous n’y avions pas prêté attention jusque-là) et qu’il est capable de discuter avec nos équipements à travers le réseau, et pas uniquement avec un port série.

Parfait ! On dégaine alors notre machine virtuelle Windows, on installe le logiciel en question, on ajoute notre licence d’essai et on se lance !

Bon… Il s’avère que c’était bien plus compliqué que prévu. Nous finissons par comprendre qu’il faut installer des drivers supplémentaires ainsi que les firmwares correspondant aux modèles de nos équipements.

Une fois toutes ces étapes réalisées, on entre l’IP d’un de nos équipements et BINGO, sa configuration nous est renvoyée et nous avons la possibilité de la modifier ! Seule barrière : un mot de passe qui s’avérera malheureusement être celui par défaut disponible dans la documentation technique du constructeur. 🤷

Et … TADAAAA

À noter qu’il est théoriquement possible de faire la même chose depuis l’interface web mais nous n’avons pas tenté.

En l’occurrence, d’après le format du mot de passe même si celui-ci n’avait pas été par défaut, nous aurions probablement pu nous appuyer sur l’interface web pour réaliser une attaque par force brute sur celui-ci.

Il est temps pour nous d’entamer notre phase de rapport et d’exposer toutes ces informations à notre client qui l’attend avec impatience.

Résultats

Voici un résumé de ce que nous avons pu découvrir :

• Il n’y a pas de protection contre le MiTM et il n’existe aucun dispositif de monitoring du réseau qui pourrait permettre de détecter un changement sur celui-ci.
• Les mots de passe des interfaces d’administration de certains équipements sensibles sont ceux par défaut.
• Certains équipements sont vulnérables à des dénis de services dont un via une interface web.
• Le protocole industriel “GOOSE” n’est pas chiffré.
• Les armoires sont physiquement protégées par une clé à empreinte générique.
• Les disques durs des PCs des opérateurs sont protégés par une serrure facilement crochetable et ne sont pas chiffrés.

Pour être plus pragmatique : un hacker qui découvrirait le site et qui ne serait pas rapidement appréhendé, pourrait compromettre la sécurité du réseau électrique.

Le scénario le plus critique (à notre sens) serait un hacker qui, suite à une première découverte du lieu, pourrait préparer son attaque. Il aurait tout le loisir de monter un dispositif de maintien d’accès équipé d’une puce 4G et de le déposer dans une armoire ou encore de le dissimuler dans le faux sol, puis de réaliser son attaque à distance.

Conclusion

Suite à notre audit, nous avons longuement échangé avec notre client afin de bien qualifier les risques et, surtout, pour aider à identifier les actions à réaliser rapidement dans le but que le niveau de risque diminue au maximum.

Heureusement, il va pouvoir s’appuyer sur le constructeur qui a imaginé et déployé l’infrastructure pour lui et qui devrait prendre en charge la correction de la majorité des vulnérabilités remontées par notre intervention.

Côté Squad, nous avons pris beaucoup de plaisir pendant cette mission. Nous avons découvert plein de nouvelles choses. Surtout, nous sommes fiers d’avoir mis nos compétences à contribution pour améliorer la sécurité de quelque chose de très concret.

Cela permet également de constater que même un système relativement récent, combinant un réseau purement industriel et un réseau sur TCP/IP, reste toujours vulnérable.

Enfin, si vous voulez en savoir plus sur la cybersécurité chez Zenika, cliquez ici 😁