Figure 1: Architecture de travail
Cet article relate l'étude de sécurité que nous avons menée sur des technologies SCADA récentes. Nous mettrons en particulier l'accent sur la méthodologie employée pour arriver à nos ns et les diverses méthodes utilisées : rétro conception en boîte noire, en boîte blanche et fuzzing. Nous aborderons à la fois la rétro-conception du protocole industriel, d'une partie de la pile d'un client du protocole et du rmware du PLC.
Cette étude a permis de mettre en évidence plusieurs failles dans les technologies concernées et de dévoiler une bonne partie du cryptosystème d'un protocole propriétaire. Nous présenterons d'ailleurs une attaque tirant parti d'une des failles mises en lumière.
Disclaimer : Les termes utilisés pour désigner les technologies sont volontairement imprécis. Nous sommes actuellement en contact avec le constructeur concerné pour corriger les vulnérabilités identi ées.
En écho à de récentes attaques sur des systèmes critiques (on citera Stuxnet[8] qui avait réussi à mettre hors service des centrifugeuses à uranium en Iran, ou plus récemment Havex, un RAT ciblant des systèmes SCADA), certains constructeurs ont fait, et font encore, des e orts très conséquents pour élever la sécurité de leurs produits au même niveau que celle des systèmes traditionnels.
Le lourd passé des systèmes SCADA en matière de sécurité rend l'analyse de ces nouveaux systèmes sécurisés d'autant plus intéressante.
Avant de rentrer dans le c ur du sujet, ce paragraphe présente rapidement ce que sont les systèmes SCADA et le rôle des composants que nous allons étudier dans ce document.
L'acronyme SCADA désigne une sous-partie d'un tout plus grand, appelé systèmes industriels (ICS, pour Industrial Control System en anglais).
Le terme systèmes industriels désigne ici des systèmes informatiques s'interfaçant avec des systèmes physiques : vannes, moteurs, capteurs de températures, de pression... On retrouve ce type de système notamment dans les centrales nucléaires, les circuits de distribution d'eau, les systèmes d'alarme, de contrôle d'accès ou de vidéosurveillance et bien d'autres. En réalité, beaucoup de systèmes rentrent dans cette dé nition.
La partie SCADA désigne la partie supervision et contrôle du processus physique. Le dossier paru dans MISC 74 [6] présente ce type de systèmes bien plus en détail.
La partie SCADA d'un ICS est composée (principalement) de trois éléments :
Les équipements industriels, et particulièrement les PLCs, ont tendance à être très pérennes : jusqu'à une trentaine d'années de durée de vie pour certains. Ils sont également très coûteux et délicats à remplacer : les PLCs en eux-mêmes peuvent être onéreux, mais il faut aussi compter toute la phase de programmation et d'intégration d'un nouveau modèle dans un système existant. L'une des conséquences de ce phénomène est de retrouver beaucoup de vieux équipements dans les milieux industriels.
Lorsqu'ils sont en fonctionnement, certains systèmes industriels (notamment les systèmes critiques) sont délicats à mettre à jour. Lorsqu'il n'y a pas une redondance complète du système, il faut pouvoir l'arrêter le temps de la mise à jour. Lorsque le degré de redondance du système permet d'en retirer des éléments pour les mettre à jour sans l'arrêter, il faut toujours s'assurer que la mise à jour ne nuit pas au système. Réaliser une simple mise à jour sur ce type de système est souvent un problème complexe, il n'est par conséquent pas rare de rencontrer des systèmes industriels ne béné ciant pas des derniers correctifs de sécurité.
Du fait de leur rôle critique, même un déni de service sur un PLC est une situation qu'il faut à tout prix éviter. En règle générale, on cherchera à éviter toute situation modi ant le comportement de l'appareil ; les notions d'authenticité et d'intégrité sont souvent plus importantes que la con dentialité des données ou des communications dans ce genre de réseau. Ces exigences en matière de stabilité et de sécurité contrastent avec la réalité du terrain : ce sont souvent des équipements anciens et peu à jour. Le lecteur saisira donc toute l'importance de concevoir des équipements stables et proposant des mécanismes de sécurité robustes.
Nous avons choisi de nous concentrer sur une grande marque d'équipements industriels, sélectionnée essentiellement en raison de sa grande part de marché en Europe et de ses e orts pour améliorer la sécurité de ses équipements.
Nous avons étudié un de leurs PLCs récents, leur logiciel de supervision (appelé IHM dans la suite) ainsi que deux versions d'un de leurs protocoles propriétaires. La gure 1 montre comment ces éléments sont agencés.
Une première cartographie du PLC révèle qu'il n'y a que deux services accessibles : un serveur web (en HTTP et en HTTPS, con gurable et désactivable via le logiciel de programmation de PLC) et un serveur TCP pour le protocole métier. Ce type de protocole permet à la supervision (client du protocole) et au PLC (serveur du protocole) d'échanger des informations, ainsi que de reprogrammer le PLC. Ils peuvent être transportés sur Ethernet via TCP/IP, mais aussi sur diverses liaisons série.
Si de nombreuses vulnérabilités concernant les serveurs Web embarqués de PLCs ont été publiées, très peu concernent directement les protocoles métier, et encore moins lorsqu'ils sont propriétaires. L'avantage de s'intéresser directement au protocole métier est qu'il est très improbable de fermer le serveur de communications métier : sans cela, le PLC devient beaucoup moins utile. Le serveur Web est en revanche totalement optionnel (bien que pratique) et peut être désactivé. Il est d'ailleurs désactivé par défaut.
Nous avons donc choisi de nous intéresser au protocole métier, ici porté sur TCP/IP. Il en existe deux versions : la plus ancienne ne comportait pas (ou peu) de mécanismes de sécurité et est assez bien connue de la communauté. La seconde, sur laquelle nous avons concentré plus d'e orts, implémente un certain nombre de mécanismes de sécurité, mais il n'existe que très peu de travaux publics dessus.
A n de nous familiariser avec l'environnement SCADA du constructeur que nous avons choisi, nous avons décidé de commencer par implémenter une partie du protocole le moins récent, puis de fuzzer l'IHM avec en écrivant un faux PLC qui communique avec ce protocole. Celui-ci a l'intérêt d'être relativement bien connu de la communauté, ce qui facilite grandement son implémentation.
Comme dit plus haut, le but est de se faire passer pour un PLC auprès de la supervision, puis de la fuzzer, c'est-à-dire de lui envoyer des paquets malformés en espérant provoquer un comportement imprévu.
IHM
IHM
IHM
IHM Project
IHM Project
IHM Project
Shared Memory
TCP Broker
Fuzzer worker
Fuzzer worker
Fuzzer worker
RadamsaTCP/IP
Fuzzes
valid
packets
with
L'architecture de fuzzing en elle-même (présentée en gure 2) reste assez classique :
En revanche, il y a une particularité : les IHMs ne communiquent pas directement avec le fuzzer. Si cela n'empêche pas d'analyser les crashes produits, il est beaucoup plus compliqué de retrouver la capture réseau qui en a causé un : le TCP Broker n'o re pas de moyen documenté de savoir quelle instance d'IHM utilise quelle connexion TCP.
Pour résoudre ce problème, il faut arriver à associer une communication réseau à un PID d'IHM. Il n'est pas possible d'agir sur le port TCP de destination de la communication, et le port source ne donne pas d'indication sur le PID qui utilise la connexion TCP (à cause du Broker).
Une astuce à base d'IP aliasing a été utilisée : chaque projet est con guré pour se connecter à une adresse IP di érente 2 , et les workers du fuzzers sont con gurés pour écouter sur toutes ces adresses IP. Ainsi, le script lançant les IHMs du côté client est capable d'associer le PID d'un processus ayant crashé avec l'adresse IP du projet qui lui a été passé en argument, et demande au fuzzer la dernière capture associée à cette adresse IP. Cette capture est nécessairement celle qui a fait crasher le processus côté client, puisque toutes les IHMs lancées à un moment donné se connectent à des IP di érentes.
Ainsi, nous avons pu mettre en place une architecture de fuzzing où les ressources de chaque VM sont utilisées au maximum, et où il est possible de lancer k VMs contenant i IHMs et n VMs faisant tourner chacune un fuzzer à j workers, pour tous k, n, i et j tels que k i = n j.
Après très peu de temps (environ 5 minutes de fuzzing sur un seul processus), le premier crash a eu lieu.
Il s'agit essentiellement d'une mauvaise véri cation sur une valeur permettant d'accéder à un indice arbitraire dans une table de handlers. Le crash se produit lors de la phase de négociation du protocole, sur les premiers paquets.
L'exploitabilité de ce bug n'a pas été con rmée, mais il présente au moins l'intérêt de pouvoir faire crasher une IHM en 3 paquets, sans authenti cation nécessaire. Dans ce protocole, la supervision joue le rôle de client, et le PLC de serveur. Pour réaliser cette attaque, il faut arriver à intercepter un établissement de connexion TCP, puis répondre à la place du PLC avec les paquets frauduleux. Cependant, une autre manipulation permet de facilement faire un reset de la connexion TCP, facilitant beaucoup les choses.
Une fois l'architecture prise en main, nous avons choisi de commencer l'étude de la nouvelle version du protocole. Celle-ci propose notamment une authenti cation par mot de passe, donnant accès à di érents niveaux de privilèges sur le PLC (grossièrement lecture et écriture). Très peu de travaux publics existent sur ce protocole ; or, il nous semble intéressant de véri er qu'il est aussi sécurisé qu'il souhaite l'être.
Le protocole que nous étudions n'est pas basé sur du texte. Face à un protocole presque inconnu et plusieurs dizaines de mégaoctets de DLLs, nous avons choisi de commencer par une analyse en boîte noire. En pratique, il s'agit de regarder le contenu de captures réseau générées astucieusement en utilisant le logiciel d'IHM et le PLC du constructeur.
L'approche que nous avons employée est celle d'une analyse par di érence (inspirée par [7] et [2]). Grâce à un outil permettant d'aligner les hexdumps des paquets (hexlighter [4]) et de mettre en surbrillance les di érences entre deux paquets consécutifs, on en apprend beaucoup sur la structure du protocole.
Prenons un exemple de jeu de test où la supervision est censée lire tous les bits d'entrée et de sortie du PLC, pendant que nous les faisons varier en changeant les tensions d'entrée. Nous nous intéresserons ici uniquement aux réponses du PLC à la supervision.
Hexlighter permet (entre autres) de colorer des hexdumps de manière à faire apparaître les di érences entre eux. Le résultat étant peu lisible sur les pages de ce livre, une représentation graphique remplaçant chaque octet par un carré de couleur a été proposée. La gure 3) montre le résultat en ltrant uniquement les réponses venant du PLC :
Avec cette représentation, plusieurs choses sautent aux yeux :
En y regardant de plus près et en comparant les paquets de manière di érente (par exemple le cinquième paquet de plusieurs connexions di érentes), on peut déduire le sens de nombreux champs. Chaque changement de paramètre (écriture au lieu de lecture, changement de valeur des variables, nouvelle session...) a tendance à révéler son impact dans les di s de paquets. La clé du succès de cette méthode est toujours de pouvoir facilement associer un changement de paramètre à sa répercussion dans le tra c réseau.
L'analyse en boîte noire a ses limites. Après avoir mis en évidence beaucoup de champs intéressants du protocole, il reste certains problèmes qu'il n'est pas facile de résoudre sans une phase de rétro conception sur les binaires des clients implémentant le protocole. C'est notamment le cas du champ de 32 octets à forte entropie (à ce stade, un fort soupçon de HMAC ou de hash pèse sur cette partie du paquet), dont nous voulons connaître la signi cation précise.
La solution de facilité est de regarder le logiciel de supervision, car il s'exécute sur un ordinateur de bureau classique, en x86. Contrairement au PLC, son instrumentation est triviale.
Le premier problème auquel on se heurte est celui de la complexité de ce programme : plusieurs processus communiquent au travers de pages mémoires partagées, tous multithreadés, asynchrones et anqués de plusieurs dizaines de DLLs, aux noms pas toujours très évocateurs.
La première approche, naïve, a été de tracer la remontée des données depuis l'appel système recv jusqu'à la véri cation du champ qui nous intéresse. Les nombreuses copies du bu er lu, sa migration entre les processus via une mémoire partagée et leur nature asynchrone ne facilitent ni l'analyse statique, ni l'analyse dynamique. La conclusion est simple : nous avons mis un terme à cette traque avant qu'elle ne porte ses fruits. En revanche, elle a permis de découvrir beaucoup de code intéressant et d'identi er le processus faisant réellement la véri cation de ce champ, mais pas la fonction précise appelée.
Une approche intéressante serait de travailler sur une trace complète du programme, puis de tracer la destination des données avec du tainting. Ce n'est cependant pas l'approche que nous avons utilisée, notamment à cause de sa di culté de mise en place sur ce type de programme.
En réalité, nous avons une vague idée de ce que nous cherchons : les 32 octets qui nous intéressent impliquent assez probablement un hash. On peut imaginer qu'il s'agit soit d'un hash pour assurer l'intégrité du message (mais une taille de 32 octets semblerait disproportionnée pour cela), soit un HMAC ou équivalent. Si une implémentation d'un algorithme de hash produisant 32 octets (par exemple SHA 256) était présente dans une dll utilisée par l'IHM, il ne serait pas très coûteux de véri er s'il est impliqué dans la génération de ces données ou non.
La méthode classique pour retrouver ce genre d'algorithme est de rechercher des constantes qui les caractérisent dans les binaires. La méthode employée consiste donc à lancer signsrch[5] sur toutes les DLLs utilisées par l'IHM lorsqu'elle est connectée au PLC, a n trouver une ou plusieurs DLLs présentant des algorithmes intéressants. Sur l'une d'elles (appelons-la hmi_core.dll), signsrch produit une sortie particulièrement intéressante :
On y retrouve le SHA 256 suspecté, ainsi que d'autres algorithmes de hash et de chi rement (dont AES, qui nous intéressera plus tard).
En plaçant un breakpoint sur la partie sha2_process de SHA 256 dans hmi_core.dll, on peut véri er que cette fonction est bien appelée pendant la communication, et semble être appelée plusieurs fois à chaque paquet reçu ou envoyé.
Un peu d'analyse statique permet de déterminer que les fonctions de SHA 256 servent à réaliser un HMAC. En déboguant le programme, on peut bien constater que le payload du paquet est passé en paramètre au HMAC avec une sorte de clé de session de 24 octets. La sortie du HMAC SHA 256 correspond bien aux 32 octets de forte entropie à la n du paquet dont le payload a été passé en paramètre au HMAC.
Cette méthode peut permettre d'assurer l'authenticité de chaque paquet émis, dans la mesure où la clé est unique à la session et échangée de manière con dentielle. C'est une belle avancée, mais une question importante est maintenant en suspens. D'où vient cette clé, et comment est-elle échangée ?
Il se trouve que tracer la génération de la clé de session a été beaucoup plus facile, ce ne fut l'a aire que de quelques breakpoints en écriture sur les données intéressantes.
L'identi cation de l'origine de la clé de session, générée par un PRNG, a permis de mettre en évidence un premier problème : la sortie du PRNG n'a rien d'aléatoire. En e et, aucun aléa ne lui est fourni (il est toujours réinitialisé de la même façon, avec un bu er constant). Ceci est con rmé par le fait que la séquence de clé de sessions générée est toujours la même lors d'une exécution du logiciel de supervision. Il est ainsi possible de bruteforcer cette clé en un temps très court (en générant la même séquence de clé que la supervision), puis de voler une session déjà authenti ée en outrepassant l'authenti cation par mot de passe normalement proposée par le protocole. Une attaque exploitant cette vulnérabilité sera présentée dans la section 4.
Cette attaque sur l'usage biaisé du PRNG est intéressante, mais il serait dommage de s'arrêter à cette étape : il s'agit d'une erreur d'implémentation relativement facile à corriger. Nous cherchons maintenant à savoir comment l'IHM fournit cette clé de session au PLC.
Un rapide retour à de l'analyse en boîte noire nous permet d'identi er le paquet portant a priori la clé de session. Le raisonnement est le suivant :
Il semble donc évident que le passage de la clé de session se fait dans le deuxième paquet envoyé par le client au serveur.
Rappelons qu'une implémentation d'AES est présente dans la bibliothèque hmi_core.dll. Aucun algorithme de chi rement asymétrique n'étant détecté dans la dll (à première vue), AES devient un bon candidat pour ce qui est de l'échange d'un secret. En déboguant le processus de l'IHM, on peut constater que les fonctions utilisées par AES sont bien appelées au moment de forger le paquet qui nous intéresse.
Après une analyse statique de cette implémentation, nous avons pu reconstituer l'algorithme complet qui est une forme d'AES 128 en mode GCM, qui est très proche du mode CTR. Pour rappel, le principe du mode CTR est de xor-er le texte clair avec un keystream. Ce keystream est généré en dérivant l'IV pour obtenir une suite d'octets de longueur arbitraire et en chi rant chacun de ces IVs dérivés par bloc de 128 bits (pour AES 128).
En connaissant l'algorithme et la clé (elle peut être récupérée en débuggant l'IHM pour une session donnée), nous pouvons maintenant déchi rer la clé de session utilisée pour une communication donnée. Nous véri ons ainsi que la clé de session est bien chi rée avec AES 128 GCM (avec quelques autres données) et que cela représente les 72 derniers octets du bu er de 132 octets précédemment identi é.
Il se trouve cependant que cette clé AES change lors de chaque session (bien que la séquence générée lors d'une exécution du processus soit toujours la même, à cause du PRNG biaisé). Nous repartons donc pour une nouvelle itération : comment cette clé AES est-elle générée et communiquée au PLC ?
Résumons la situation :
Nous réitérons avec la même méthode que précédemment : équipés des dernières informations obtenues, un peu d'analyse en boîte nous permet d'isoler la partie du protocole qui pourrait être responsable de cet échange : il s'agit des 60 premiers octets du bu er de 132 octets précédemment mentionné.
En corrélant ces données avec celles traitées par le processus en amont du chi rement AES précédemment identi é, nous retrouvons une partie du code qui semble chi rer la clé.
À notre grande surprise, le code réalisant cette opération semble obfusqué, et à l'heure où ces lignes sont écrites, nous n'avons pas pu identi er l'algorithme utilisé.
La gure 4 résume le système cryptographique que nous avons découvert. La fonction obf_enc représente le chi rement obfusqué que nous n'avons pas identi é. Le mode d'authenti cation par mot de passe n'a pas été examiné au moment de la rédaction de cet article.
Les briques du cryptosystème que nous avons pu identi er semblent standard et solides. Cependant, plus de temps sera nécessaire pour nous prononcer sur la solidité du système complet et en particulier de l'algorithme obfusqué. Il reste encore des zones d'ombres dans le système cryptographique et la façon dont les données sont échangées peut laisser penser que ces algorithmes s'appuient sur des secrets xés dans le rmware ou le hardware du PLC. Ces secrets pourraient être communs à tous les PLCs d'un même modèle et ayant la même version de rmware.
À ce stade, il nous a semblé intéressant d'aller voir du côté du rmware, notamment pour véri er si le pendant de la routine à identi er était également obfusqué côté PLC. Cet équipement ayant des ressources plus limitées, il ne serait pas étonnant d'avoir (au moins) une obfuscation plus légère.
Dans le cas où le code du côté PLC serait plus simple, cela permettrait sûrement d'identi er plus facilement l'algorithme utilisé. C'est ce que nous traitons dans la section 5. Mais avant de présenter cette étude, nous décrirons l'attaque permettant de voler une session authenti ée de ce protocole.
Comme montré dans la section 3.3, un manque d'entropie en entrée du PRNG utilisé rend ses sorties prévisibles : il s'agit toujours de la même séquence, à chaque exécution du client. Cette partie décrit les étapes qui ont permis d'écrire un code démontrant la possibilité de cette attaque.
Toute la sécurité d'une session repose sur le fait que seuls le client et le serveur connaissent un secret partagé, que nous appelons clé de session. Il se trouve que la suite des valeurs retournée par le PRNG est parfaitement prévisible, en raison d'un défaut d'usage : le PRNG est toujours initialisé avec des chaînes constantes. Il est par conséquent possible d'énumérer toutes les clés de session dans l'ordre où elles sont générées.
À partir d'un seul paquet authenti é, il est possible de véri er si une clé de session donnée a été utilisée pour générer le HMAC authenti ant le paquet. Étant donné qu'il est possible d'énumérer les clés de session générées par l'IHM dans l'ordre, une attaque consistant à générer puis tester les clés une par une prend un temps très raisonnable. Cette attaque permet de retrouver la clé de session qui a servi à authenti er le paquet capturé ; cette clé de session permettra d'authenti er n'importe quel autre paquet, permettant de réaliser des actions avec les privilèges de la session volée.
Le premier objectif sera de modi er les réponses aux requêtes de lecture du client pour modi er l'état qu'il perçoit du PLC. Le second sera d'écrire des valeurs arbitraires sur le PLC avec les droits de la session sans que celle-ci s'en aperçoive. La gure 5 montre les LEDs indiquant les entrées (LEDs du haut) et sorties (LEDs du bas) du PLC, ainsi qu'une portion de l'interface de supervision (haut de la gure). On note que les pastilles vertes et rouges de la supervision représentent les LEDs du PLC, et que leurs états sont synchronisés.
Cette attaque nécessite d'avoir un accès en lecture au réseau. Il est envisageable d'arriver à des résultats intéressants sans man-in-the-middle, à condition de pouvoir au moins capturer un paquet authenti é, bien que cet angle d'attaque ne soit pas étudié ici.
A n de pouvoir intercepter et modi er les paquets échangés par le client et le serveur via TCP, la première étape consiste à faire transiter tous ces paquets par la station de l'attaquant. En pratique, cela peut être par exemple réalisé avec de l'ARP spoo ng.
Le man-in-the-middle est basé sur l'usage des NFQueues pour faire remonter les paquets en espace utilisateur, les modi er et les renvoyer. La commande pour envoyer les paquets routés dans une nfqueue est :
Un binding python pour l'API de nfqueue a été utilisé. Ce binding n'implémente pas la fonction set_payload, pour pouvoir quand même réaliser l'attaque, les paquets modi és sont droppés par la nfqueue et renvoyés en raw socket après modi cation.
Comme nous le verrons dans la suite, certaines modi cations de paquets changent également leur taille, désynchronisant les seq et ack des deux parties de la connexion TCP. Ne s'agissant que d'une preuve de concept, la gestion de cette désynchronisation dans le man-in-the-middle n'a pas été implémentée, causant le reset de la connexion TCP dans certains cas.
Cette partie est relativement simple : il su t d'isoler le HMAC (le bloc de 32 octets de forte entropie vu précédemment) d'un paquet, de générer toutes les clés de session dans l'ordre où l'IHM les génère et de les tester une par une. Le nombre de sessions établies par l'IHM depuis son démarrage étant raisonnablement faible, cette attaque aboutit très vite.
Connaissant la clé de session, il est possible d'authenti er des paquets arbitraires. Le plus simple est de partir d'un paquet légitime, de le modi er, puis de l'authenti er en recalculant le HMAC. Une méthode de véri cation est de relancer le bruteforce sur le nouveau paquet authenti é et de véri er que la clé retrouvée est bien celle utilisée pour authenti er le paquet.
Pour simpli er, nous construirons l'attaque en fonction d'un projet d'IHM en particulier. Il est possible de faire quelque chose de plus générique, mais cela demande plus de temps et n'apporte rien à la preuve de concept.
Pour un projet donné, les requêtes de lecture et les réponses associées ont toujours le même payload. Pour contrôler les valeurs reçues par la supervision (le client), il su t de repérer, dans le paquet de réponse les o sets des valeurs des variables du PLC, puis de les mettre à la valeur voulue. On rajoute ensuite les données d'authenti cation avec la méthode décrite précédemment, puis on envoie le paquet à la supervision.
Cette méthode permet d'atteindre le premier but : contrôler ce que reçoit la supervision, et donc ce que percevrait un opérateur sur une IHM dans un vrai site industriel. Un exemple de mise en oeuvre de cette attaque est visible sur la gure 6 : l'état de l'interface de supervision (en haut) n'est plus cohérent avec l'état réel des LEDs du PLC.
Cette partie est un peu plus complexe. Pour la mener à bien, le plus simple est de substituer une requête de lecture par une requête d'écriture, qui devra être presque intégralement forgée. Se substituer à une requête existante évite de devoir forger la partie TCP du paquet.
Il s'agit ensuite de générer une requête d'écriture qui soit bien acceptée par le PLC. Pour cela, nous partons d'une requête d'écriture légitime générée par le logiciel de supervision et préalablement capturée. Pour déterminer quels champs changer pour arriver à une requête valide dans le contexte d'une session quelconque, il su t de regarder les di érences entre deux paquets d'écriture légitimes ou entre un paquet forgé invalide et un paquet valide. La plupart de ces champs sont simples à reconstruire, car ils dépendent soit du payload du paquet courant, soit du précédent paquet envoyé par la supervision, quel qu'il soit.
Un champ, en revanche, est plus complexe à forger : il s'agit d'un numéro de séquence propre aux requêtes d'écritures. S'il n'est pas cohérent, le PLC refusera la requête. Pour récupérer ce numéro de séquence, il y a trois méthodes :
Par un procédé d'essai-erreur itératif, nous avons ni par réussir à générer des requêtes d'écriture valides pour une variable arbitraire d'un projet donné (seule la modi cation des variables de sortie a été implémentée).
Si cet exemple se cantonne aux sessions de supervision, il peut aussi s'étendre aux sessions d'administration, permettant par exemple à un attaquant de voler une session de reprogrammation de PLC pour télécharger un programme arbitraire. Toute communication établie par un client vulnérable utilisant ce protocole peut être compromise par cette attaque.
Un correctif pour cette vulnérabilité a depuis été proposé par le constructeur.
Cette attaque est relativement réaliste : en pratique, il est souvent possible d'arriver à accéder à un réseau industriel. Certains d'entre eux sont connectés à des réseaux d'entreprise, voir directement à internet. Quand ce n'est pas le cas, ils utilisent parfois des réseaux sans l (WiFi, GSM) pour fonctionner. Même lorsque ces vecteurs d'attaque ne sont pas disponibles, il y aura souvent un moment où un ordinateur portable d'un agent de maintenance nira par être relié au réseau industriel, rendant possible cette attaque. Les réseaux étant souvent "à plat", sans routage, cela rend l'attaque d'autant plus réalisable.
Les rmwares sont téléchargeables sur le site de l'éditeur. Un compte est nécessaire pour accéder aux téléchargements.
Le dernier rmware disponible pour ce modèle de PLC au moment de l'étude était celui déjà installé sur le PLC.
Le format du rmware est propre à l'éditeur. Il est composé principalement d'un en-tête comprenant une table de sections, suivi du contenu de chaque section. Un CRC-32 du contenu de chaque section est présent dans cet en-tête. Une section, nommée A00000, contient l'intégralité du code du rmware. La dernière section, FW_SIG, contient la signature.
La section A00000 est entièrement compressée. L'algorithme de compression est a priori inconnu, le code de décompression n'étant accessible qu'après décompression... Lors d'une mise à jour, le PLC véri e la signature du rmware, décompresse le code de la section A00000 et l'écrit sur une mémoire Flash.
La compression a donc dû être étudiée en boîte noire.
Certains blocs ont été particulièrement intéressants pour l'étude, car ils débutaient par des données dont la version décompressée était connue : il s'agissait principalement de pages du serveur Web ( chiers HTML ou CSS).
On remarque tout d'abord que certaines parties, notamment des morceaux de pages Web, apparaissent en clair. Toutefois, un caractère nul est inséré tous les 9 octets :
Les données semblent donc être stockées par blocs de 9 octets. Parfois, le texte est partiellement en clair. Ce n'est alors pas un caractère nul qui est inséré, mais par exemple 41 ou 10 aux lignes 2 et 4 de l'exemple suivant :
Le texte en clair est facile à deviner : il s'agit de la chaîne de caractères :
On remarque donc que ces octets ont été remplacés par leur longueur !
Les lignes où des octets ont été remplacés ne démarrent pas par un octet nul, mais par 0x41 et 0x10. Cet octet est en fait un masque : le ième bit de cet octet indique si le ième octet du bloc doit être recopié, ou s'il s'agit d'une longueur. Ainsi, un octet de masque à 0x41 = (1 << 6) + (1 << 0) signi e que les octets 2 = 8 6 et 8 = 8 0 contiennent des longueurs.
On peut donc déterminer la longueur de n'importe quel bloc compressé, et également décompresser une partie des données. Par exemple, on sait que l'exemple suivant :
sera décompressé pour obtenir un texte de la forme : sXXXXXXXXXhandheld, only screXXXXXXXXXax, où les octets à X sont inconnus.
Ceci fait très fortement penser à une compression de type LZ, où un dictionnaire est construit au fur et à mesure de la décompression.
Comment retrouver les octets manquants en fonction de leur longueur uniquement ? Les algorithmes LZ classiques encodent une longueur et une distance par rapport au bloc à recopier. Ici, seule une longueur est présente.
Une analyse manuelle assez fastidieuse a permis de deviner que les 4 octets précédant l'encodage d'une longueur étaient déjà présents dans les données précédemment décompressées. Ainsi, la précédente occurrence de "scre" était déjà suivie par une chaîne de longueur 9 correspondant au texte clair media="handheld, only screen and (max-width: 767px).
Les données décompressées seront alors :
Ceci a permis de bien avancer. Toutefois, certaines données décompressées étaient incohérentes. Nous avons supposé que, pour des raisons de performance, l'algorithme de décompression ne faisait pas des recherches de 4 octets sur les données déjà décompressées pour obtenir les tokens à écrire, mais qu'une table de hachage était construite au fur et à mesure de la décompression. Cette hypothèse s'est avérée exacte. Le problème est que, pour des raisons d'occupation mémoire, la table de hachage est de petite taille. Des collisions se créent donc dans les entrées, ce qui fausse la décompression. Les erreurs s'enchaînent alors en cascade, et les données de sortie deviennent très vite complètement fausses.
La manière de construire la table de hachage étant inconnue, nous étions face à un mur. La solution est nalement apparue en étudiant les divers algorithmes LZ publics. La page de WikiBooks sur la compression [9] a été d'une grande utilité : elle mentionne l'algorithme LZP. C'est exactement cet algorithme, plus précisément LZP3, qui est utilisé dans le rmware.
La description de l'algorithme est détaillée dans [3]. Une implémentation a été développée, permettant l'accès en clair au rmware.
L'accès au code complet de ce rmware a été essentiel pour comprendre le mécanisme de signatures utilisé. Une analyse statique a montré qu'ECDSA-256 était utilisé. A n d'éviter des problèmes de parsing, notamment sur la table d'en-têtes, une solution simple a été mise en uvre : tout le rmware est signé, excepté les 78 derniers octets, lesquels contiennent une signature de taille xe. Les données présentes dans l'en-tête de la section FW_SIG ne sont donc en réalité pas prise en compte pour véri er la signature.
La courbe et le générateur utilisés sont standard (ANSI X9.62 P-256). La fonction de hachage est SHA256.
Le mécanisme de véri cation d'intégrité de chaque section, reposant sur CRC-32, n'est pas sûr d'un point de vue cryptographique, mais aucune exploitation n'est possible si le mécanisme de signature global du rmware n'a pas été contourné. La mise en uvre de la véri cation de signature a été analysée en détail. Aucune vulnérabilité n'a été trouvée sur ce mécanisme.
Le mware obtenu n'est pas dans un format connu (type ELF ou bFLT), et semble consister en un seul et unique exécutable. Pour explorer correctement ce rmware, l'idéal est d'avoir une idée du mapping mémoire du binaire.
En explorant le binaire, nous avons ni par retrouver une table des sections, dont le format est relativement simple. Elle peut être retrouvée en cherchant, par exemple, la chaîne de caractère .text, qui est présente dans la table des sections. En voici une traduction lisible :
Le champ Unknown est toujours à zéro, mais est présent pour chaque entrée de la table. La permission i signi e est initialisé quand chargé en mémoire , ce sont des données qui correspondent à des parties du binaire directement chargées en mémoire. Cette information est purement empirique, et il se trouve que la première section ne correspond pas à cette dé nition, puisqu'elle correspond à du code du rmware chargé en mémoire, mais n'a pas la permission i. La signi cation de la permission ? est inconnue, il semblerait qu'elle autorise un certain type de lecture lorsque i n'est pas présent. Elle pourrait être interprétée comme autorisation en lecture d'une donnée non initialisée .
Voici comment le rmware est chargé en mémoire :
Toutes les autres sont a priori non initialisées. La section .bss sera par exemple initialisée au boot par le code situé dans la section .th_initial.
Certaines de ces sections correspondent peut-être à des périphériques physiques. On notera d'ailleurs que le rmware déréférence régulièrement des adresses non mappées d'après la table des sections, faisant penser à un accès à des composants hardware, par exemple des accès proches de l'adresse 0xffffffff. Le début des données est un en-tête décrivant l'organisation de la mémoire du PLC. Il est suivi par le code. On peut donc maintenant procéder à une analyse statique du code complet du PLC.
Malheureusement, les algorithmes obfusqués dans le logiciel de supervision le sont également sur le PLC.
Dans cet article, nous avons exposé notre démarche dans la rétro conception d'un système industriel. La première phase de fuzzing nous a permis de nous familiariser avec l'architecture et a permis d'identi er des points d'intérêt dans les technologies manipulées.
La rétro conception en boîte noire nous a rapidement apporté tout ce qu'il nous fallait pour faire une analyse en boîte blanche ciblée de la sécurité du protocole. Cette dernière phase a permis de découvrir une bonne partie du cryptosystème mis en place, de découvrir une vulnérabilité et de monter une attaque opérationnelle l'exploitant. L'analyse du rmware nous a ouvert de nouveaux horizons en ce qui concerne la recherche de vulnérabilités sur le PLC.
Ces informations nous permettront par la suite d'aller plus loin dans la compréhension de ces technologies, permettant par exemple de faire du fuzzing plus ciblé en connaissant tous les formats de données utilisés par le protocole, ou d'essayer de compiler des programmes utilisateurs arbitraires.
Contrairement à ce qui a pu se voir précédemment, ce constructeur a fait un e ort très conséquent en ce qui concerne la sécurité de ses équipements, et même s'il reste du chemin avant d'arriver à un niveau de con ance proche de ce que l'on peut retrouver dans des systèmes d'information classiques, les choses évoluent dans le bon sens.
Les auteurs tiennent à remercier Pierre Capillon et Florent Marceau pour leurs précieux conseils lors de la rédaction de ce document.
1. Aki Helin. Radamsa. https://code.google.com/p/ouspg/wiki/Radamsa.
2. Aleksandr Timorin. SCADA deep inside : protocols and security mechanisms. http://fr.slideshare.net/AlexanderTimorin/scada-_deep-_inside-_protocols-_and-_security-_mechanisms-_40672525, 2014.
3. Charles Bloom. Lzp : A new data compression algorithm. In James A. Storer and Martin Cohn, editors, Data Compression Conference, page 425. IEEE Computer Society, 1996.
4. Florent Monjalet. Hexlighter. https://github.com/fmonjalet/hexlighter.
5. Luigi Auriemma. signsrch. http://aluigi.altervista.org/mytoolz/signsrch.zip.
6. Orion Ragozin. Introduction à la cybersécurité des systèmes d'information industriels : Méthodes de classi cation et mesures principales. Misc, (74) :27 33, July 2014.
7. Rob Savoye. Reverse Engineering of Proprietary Protocols, Tools and Techniques. In FOSDEM, 2009.
8. Symantec. W32Stuxnet. http://www.symantec.com/security_response/writeup.jsp?docid=2010-_071400-_3123-_99, 2010.
9. WikiBooks. Data compression/dictionary compression. http://en.wikibooks.org/wiki/Data_Compression/Dictionary_compression, 2014.
