Perdu dans la traduction: vulnérabilités de la passerelle de protocole industriel

La barrière de la langue ne se limite pas aux informaticiens et aux utilisateurs. Les usines «intelligentes» et les ordinateurs qui les contrôlent sont également incapables de communiquer entre eux sans traducteurs - passerelles spécialisées de protocoles industriels. Dans cet article, nous explorerons les faiblesses des passerelles de protocole et comment les attaquants peuvent les utiliser pour nuire aux entreprises.



image



Une passerelle de protocole est un petit appareil qui fournit une traduction de commande critique entre les machines-outils, les capteurs, divers actionneurs et ordinateurs exécutant des usines, des barrages, des centrales électriques et des usines industrielles. Ces passerelles ressemblent à des routeurs domestiques: elles ont également plusieurs interfaces connectées à différents réseaux, et sont tout aussi vulnérables à diverses attaques. Si un tel dispositif tombe en panne, la communication entre les systèmes de contrôle et les machines est perdue. Les opérateurs ne verront pas ce qui se passe. En fait, ils ne pourront même pas dire si les machines, les turbines ou les générateurs fonctionnent en toute sécurité. Même si quelque chose ne va clairement pas, une défaillance de la passerelle ne permettra pas à l'opérateur d'émettre une commande pour démarrer ou arrêter les processus.



Une situation similaire devait se produire en décembre 2015 pendantattaques contre le réseau électrique ukrainien : les attaquants ont eu accès au centre de contrôle du réseau électrique et ont désactivé les passerelles de protocole dans les sous-stations en y téléchargeant un micrologiciel endommagé. Cela a bloqué toutes les tentatives des ingénieurs des services publics pour rétablir le service, car les commandes des systèmes de contrôle pour fermer les disjoncteurs ne pouvaient pas être transmises.



Dans un rapport d'incident de SANS ICS (une division de l'organisation américaine d'enseignement et de recherche SANS Institute for the Study of Industrial Control Systems) et du Power Analysis and Information Exchange Center (E-ISAC - une structure qui rassemble des participants du marché nord-américain de l'alimentation électrique), le micrologiciel de la passerelle a été endommagé les protocoles étaient appelés «l'explosion des ponts». Cela décrit très précisément ce qui s'est passé, puisque les attaquants ont détruit le lien clé - les traducteurs, qui agissent simplement comme un pont entre les contrôleurs et les sous-stations.

image

La structure d'interaction entre le réseau de contrôle et le réseau d'exécution. Source (ci-après, sauf indication contraire): Trend Micro



En raison de son emplacement, une passerelle de protocole peut devenir le maillon le plus faible d'une chaîne d'appareils industriels, et un attaquant peut attaquer ces appareils pour deux raisons importantes:



  1. Il est peu probable que les passerelles se retrouvent dans un inventaire d'actifs critiques qui sera surveillé par un agent de sécurité ou un système d'enregistrement. Par conséquent, l'attaque est moins susceptible d'être remarquée.
  2. Les problèmes de traduction sont difficiles à diagnostiquer, de sorte que les failles dans la conception des passerelles de protocole permettent aux attaquants avancés de mener des attaques très secrètes.


Types de passerelles



Selon le mode de fonctionnement, deux familles de passerelles peuvent être distinguées:



  1. Les passerelles en temps réel ( passerelles en temps réel) acheminent le trafic au fur et à mesure qu'ils deviennent disponibles - chaque paquet entrant est immédiatement évalué, traduit et transmis; représentants: Nexcom NIO50, Schneider Link 150, Digi One IA;
  2. Les stations de données - fonctionnent de manière asynchrone à l'aide de la table de mappage d' interface - n'attendez pas une demande de lecture pour recevoir les données de l'automate connecté, mais demandent régulièrement des mises à jour d'état à l'automate et stockent les données reçues dans le cache interne pour une émission à la demande.


La deuxième caractéristique importante des passerelles de protocole est le type de protocoles qu'elles prennent en charge et traduisent. Grâce à cette propriété, les appareils peuvent être regroupés en trois catégories:



  1. , , , Modbus TCP Modbus RTU, — , ;
  2. , , , Modbus RTU → Profibus, — , ;
  3. , , , Modbus TCP → Profibus, — , .


Dans l' étude Lost in Translation: When Industrial Protocol Translation Goes Wrong , nous avons examiné les vulnérabilités du premier groupe de passerelles. Pour cela, nous avons assemblé un banc d'essai composé des composants suivants:



  • fuzzer qui génère du trafic entrant pour la passerelle testée - par exemple, lors du test de la traduction de Modbus TCP vers Modbus RTU, Fuzzer génère des cas de test Modbus TCP,
  • passerelle - appareil étudié,
  • simulateur - un appareil qui simule une station réceptrice, par exemple un automate qui implémente Modbus RTU d'un appareil esclave - il est nécessaire car certaines passerelles de protocole peuvent ne pas fonctionner correctement s'il n'y a pas d'appareil esclave dans la chaîne,
  • un sniffer qui collecte des informations sur le trafic sortant, c'est-à-dire sur le protocole de diffusion,
  • analyseur de trafic entrant et sortant.


image

Schéma fonctionnel du banc de test pour étudier les vulnérabilités des passerelles de protocole



image

Véritable banc de test



Pour modéliser le nœud Modbus principal, nous avons utilisé le logiciel open source QmodMaster, et pour modéliser le dispositif esclave - pyModSlave, en l'adaptant à nos besoins, comme la réception de données de / dev / ttyUSB0.



Nous avons utilisé Wireshark pour Modbus TCP et IONinja pour Modbus RTU pour intercepter le trafic. Nous avons écrit des analyseurs spéciaux pour convertir la sortie de ces deux programmes en une syntaxe commune que notre analyseur peut comprendre.



Nous avons implémenté le fuzzer sur la base de BooFuzz, en ajoutant quelques modules du projet Boofuzz-modbus, distribués sous la licence Apache. Nous avons rendu le fuzzer portable avec divers protocoles ICS et l'avons utilisé pour tester plusieurs implémentations Modbus.



Voici quelques-uns des types d'attaques que nous avons découverts lors de l'examen de diverses passerelles de protocole:



  • attaque contre le traducteur de protocole,
  • réutilisation des identifiants et décryptage de la configuration,
  • amplification du trafic,
  • élévation des privilèges.


Attaque du traducteur de protocole



Les passerelles en temps réel traduisent les paquets d'un protocole à un autre, remplaçant les en-têtes de protocole source par les en-têtes de protocole cible. Les passerelles de différents fournisseurs gèrent différemment les paquets non valides. Certains d'entre eux, par exemple, lors de la réception d'un paquet avec une longueur incorrectement spécifiée, au lieu d'ajuster la longueur ou de le rejeter, le diffusent tel quel. Cette fonction vous permet de concevoir soigneusement un paquet de mauvaise longueur pour Modbus TCP afin qu'il reste correct après la conversion en Modbus RTU. Cependant, si vous le lisez comme un paquet Modbus RTU, il aura une signification complètement différente par rapport à l'équivalent Modbus TCP.



image

Paquet d'attaque: dans Modbus TCP il contient une commande pour lire un registre, mais dans Modbus RTU c'est déjà une commande pour écrire plusieurs cellules de bits



Lors de l'analyse de ce paquet avec la sémantique Modbus TCP, il est interprété comme une commande de lecture du registre d'entrée (code de fonction 04) à partir du bloc avec ID = 3. Mais dans la sémantique de Modbus RTU, il est interprété comme l'écriture de plusieurs cellules de bits (code de fonction 15 et 0F) dans un bloc avec ID = 1.

Cette vulnérabilité est critique car une demande de lecture totalement innocente se transforme en commande d'écriture car la passerelle de protocole ne traite pas correctement le paquet. Un attaquant avancé pourrait exploiter cette vulnérabilité pour contourner un pare-feu industriel spécialisé qui bloque les commandes d'écriture à partir d'adresses IP ne figurant pas sur la liste blanche.



Par conséquent, une seule commande suffit, par exemple, pour désactiver les capteurs de surveillance de la santé et de la sécurité du moteur (capteur de température et compte-tours), tout en laissant le moteur en marche. Si les ingénieurs et les opérateurs ne le remarquent pas, le moteur peut déjà passer en mode critique et tomber en panne, mais personne ne le saura, car le thermomètre et le tachymètre ont été désactivés.



Réutilisation des informations d'identification et décryptage de la configuration



Les passerelles Moxa utilisent un protocole propriétaire lors de la communication avec le programme de contrôle à distance MGate Manager. Lorsque MGate Manager démarre, l'ingénieur est invité à entrer un nom d'utilisateur et un mot de passe pour accéder à la passerelle de protocole, après quoi McGate Manager réinitialise automatiquement la configuration afin que l'utilisateur puisse modifier les paramètres. Lorsque l'ingénieur de terrain termine la configuration de la passerelle de protocole et clique sur le bouton Quitter, la configuration est compressée, chiffrée et téléchargée vers la passerelle.



image

Étapes de configuration de la passerelle Moxa



Il existe deux failles de sécurité dans cette procédure qui peuvent être exploitées.



- Réutilisation



Lorsqu'un ingénieur se connecte, une clé est transmise à MGate Manager pour hacher le mot de passe. Cependant, dans le micrologiciel testé, le mécanisme est implémenté de telle manière qu'un pirate peut intercepter le mot de passe crypté de l'ingénieur pour entrer dans le système, puis l'utiliser pour se connecter avec des privilèges administratifs, même sans connaître le mot de passe sous forme de texte.



-



Décryptage de la configuration La configuration cryptée transmise sur le réseau contient une clé de cryptage qui permet à un pirate de la vider et de la décrypter.



image

La configuration chiffrée contient la clé AES pour la déchiffrer. Très pratique pour le piratage



Pour le décryptage, nous avons utilisé une bibliothèque de décryptage propriétaire extraite du firmware de l'appareil. La configuration contient des fichiers de configuration, des bases de données SQLite et une clé Secure Shell (SSH). Voici un exemple de la configuration décryptée de notre propre passerelle de protocole, que nous avons réussi à intercepter.



image

Fichiers de configuration décryptés Moxa MGate 5105



Amplification du trafic



Étant donné que les stations de données diffusent des protocoles de manière asynchrone les unes aux autres, plusieurs demandes d'écriture d'un bit peuvent être combinées en une seule demande pour mieux utiliser le bus série. Par exemple, un hacker peut appeler la fonction 15 (écrire plusieurs bits), à la station de données, il sera converti en 1 enregistrement pour ID = 2, 1 pour ID = 4, 1 pour ID = 5, 1 pour ID = 6. Ainsi, une entrée Modbus TCP se traduit par quatre entrées Modbus RTU, provoquant une légère congestion sur le bus série.



image

Une commande TCP pour écrire une cellule se transforme en quatre commandes RTU.Notez



que cette amplification ne provoquera pas de déni de service (DoS), mais un bus RS-485 surchargé peut encore conduire à un comportement anormal.



Escalade des privilèges



Sur MGate 5105-MB-EIP, nous avons découvert la vulnérabilité d'escalade de privilèges CVE-2020-885 qui permet à un utilisateur non privilégié d'exécuter des commandes avec des privilèges élevés.



La source du problème est le manque de filtrage des entrées utilisateur dans l'interface Web de l'utilitaire Ping.



image

Interface de l'utilitaire Mgate Ping



Avec un minimum de connaissances techniques, un utilisateur non privilégié peut lancer le démon Telnet dans le contexte de l'utilisateur root avec une simple requête HTTP GET et obtenir un accès à distance complet avec un shell root.



Nos recommandations



Après avoir examiné les spécificités du fonctionnement des différentes passerelles de protocole industriel, nous avons développé un certain nombre de recommandations destinées aux fournisseurs, installateurs ou utilisateurs finaux.



  1. - . . .
  2. — , , . ICS- . Trend Micro — TXOne Networks, OT .
  3. , — /, . , , , MQTT.
  4. OT , .



All Articles