URL: https://linuxfr.org/news/etat-des-lieux-de-la-securite-industrielle Title: État des lieux de la sécurité industrielle Authors: RbN Nils Ratusznik, baud123, Benoît Sibaud, Nÿco et patrick_g Date: 2012年08月06日T14:44:32+02:00 License: CC By-SA Tags: scada, stuxnet et sécurité Score: 63 Depuis la découverte de Stuxnet en juin 2010 et son analyse, les experts se sont aperçu que certaines des failles utilisées par le malware étaient inconnues (0-day) et de très haut niveau, et que certaines autres étaient au contraire connues et relativement triviales, cette dernière catégorie est majoritairement représentée parmi celles affectant les systèmes [SCADA](http://fr.wikipedia.org/wiki/SCADA "Définition Wikipédia") Siemens WinCC (_Supervisory Control And Data Acquisition_, télésurveillance et acquisition de données). Depuis, beaucoup de personnes se sont intéressées à la sécurité des systèmes de contrôle industriel au sens large. Les systèmes SCADA sont dorénavant bien connus pour être vulnérables mais ils ne sont pas les seuls. Le monde de la sécurité informatique découvre depuis peu ce que beaucoup de gens savent déjà, les systèmes de contrôle industriel sont de vraies passoires et la mise en péril d'un processus industriel est relativement simple. ---- [Blog Securid](http://securid.novaclic.com) [Blog de Luigi Alummi](http://aluigi.org) [Référentiels de sécurité qui vont bien](http://securid.novaclic.com/securite-internet/referentiels-securite-si.html?utm_source=rss&utm_medium=rss&utm_campaign=referentiels-securite-si) ---- #Systèmes de contrôle industriel Par systèmes de contrôle industriel (en anglais ICS pour Industrial Control System), on désigne les systèmes qui dans l'industrie permettent de contrôler certains processus industriels, ces systèmes permettent par exemple de contrôler les actionneurs sur une ligne de fabrication, de piloter des installations ou de réguler des procédés... Ces systèmes doivent répondre à un certain nombre de contraintes liées à leur nature telles que la sûreté de fonctionnement, le temps réel, la disponibilité 24/7, un environnement contraignant, des utilisateurs non spécialisés en informatique... Les motivations pour un attaquant de s'attaquer à un système de contrôle industriels peuvent être multiples : - éroder la sûreté de fonctionnement de la ligne de fabrication afin de ralentir ou saboter un processus ; - voler le programme d'un système de contrôle à des fins d'espionnage. ##Bases Les systèmes de contrôle industriels répondent bien évidement à une certaine théorie. À l'instar du modèle OSI pour les réseaux informatiques, les concepteurs de ces systèmes ont leur propre pseudo-modèle : ``` +---+-----------------+ | 3 | Supervision | +---+-----------------+ | 2 | Automatisme | +---+-----------------+ | 1 | Terrain/bus | +---+-----------------+ ``` La couche terrain désigne la couche physique, là où les divers bus industriels se situent, on y retrouve notamment des technologies telles que [ModBus](http://fr.wikipedia.org/wiki/Modbus)1, [Ethercat](http://en.wikipedia.org/wiki/EtherCAT)1, [CAN](http://fr.wikipedia.org/wiki/Controller_Area_Network)... C'est sur ces réseaux que sont connectés les divers actionneurs d'une chaîne de fabrication. La couche automatisme est la couche où s'exerce la pseudo-intelligence de ces réseaux ; les automates, connectés aux réseaux sus-cités sont les chefs d'orchestre, ils commandent les actionneurs suivant un ordre bien défini et suivant diverses conditions. La couche supervision est quant à elle celle qui est la plus liée à l'informatique, elle permet, via un ordinateur connecté sur le réseau de terrain ou sur l'automate de récolter diverses informations sur l’exécution du processus, ces informations remontent alors via des protocoles tels que OPC1 ou SCADA1 vers des logiciels de supervision dédiés tels que PcVue1 ou Panorama1. On est donc loin de la supervision classique connue des administrateurs réseaux via SNMP et des logiciels de la famille de Nagios. Viennent à côté les logiciels de configuration qui permettent de programmer les automates afin de leur faire réaliser les opérations voulues, ces configurations sont la plupart du temps réalisées grâce à des langages de programmation propres à chaque automate. Ensuite, la programmation est chargée soit en envoyant un binaire du programme, soit en reflashant tout le microcode/firmware de l'automate via USB ou autres. Le point qui fâche quant à la plupart de ces logiciels, automates et protocoles est qu'ils sont propriétaires et sont pour la plupart la définition même du _bloatware_. Certaines implémentations sont très douteuses, notoirement buggées, et on va le voir, très faciles à défaire d'un point de vue sécurité. 1 _: technologies connues comme vulnérables_ ##Nécessité du couplage avec les systèmes de gestion On pourrait se dire qu'isoler les systèmes incriminés sur des réseaux physiques dédiés devrait suffire à les rendre moins vulnérables. Malheureusement, ce n'est pas si simple, la prédisposition des utilisateurs à se servir de clé USB rompt souvent cet isolement, de nombreux exemples sont là pour le prouver ; en outre, les grands progiciels du marché cherchent actuellement à étendre leurs champs d'actions afin d'englober également la partie production, ceci doit permettre d'ajuster au plus près la production d'un bien à sa demande. Les décideurs pressés sont friands de ce genre de fonctionnalités afin de pouvoir être encore plus pressés. Il faut donc [composer avec cette contrainte](http://securid.novaclic.com/cyber-securite-industrielle/linter-connexion-des-reseaux-de-production-et-de-gestion-boite-de-pandore-ou-solution.html). On constate donc qu'un isolement n'est pas souhaité et serait de toute façon faillible ; ce rapprochement est très récent et certaines habitudes des utilisateurs ne sont plus du tout adaptées aux nouvelles contraintes entraînées par ces nouvelles interconnexions. #Des mauvaises habitudes, la réalité du terrain On constate que de nombreuses mauvaises habitudes existent tant de la part des concepteurs/installateurs que des exploitants. Certains installateurs ont tout d'abord comme habitude de connecter les automates qu'ils installent à l'Internet afin de pouvoir intervenir rapidement dessus en cas de besoin. Des recherches sur [Shodan HQ](http://www.shodanhq.com/) avec les noms de marques d'automates révèlent plusieurs milliers d'unités connectées à l'Internet et sans doutes vulnérables tout autour du monde. Il faut noter que certains exploitants ne sont pas au courant que leurs systèmes sont ainsi connectés à l'Internet. La seconde mauvaise habitude est l'utilisation de couples identifiant/mot de passe très faibles tel que : admin/1234 ou admin/00 ou 01/01... Certains postes de supervision ont également un utilisateur qui est continuellement connecté et sur lequel n'importe qui peut donc intervenir en bien ou en mal. Il s'agit là d'un florilège de mauvaises pratiques, cette liste n'est pas exhaustive ; mais par contre, tous les éléments de cette liste peuvent facilement être retrouvés sur un seul et même système de gestion. #Un monde de failles En plus de toutes ces mauvaises pratiques, les technologies employées sont vulnérables. Un hacker italien, Luigi Auriemma, s'est intéressé de près au sujet, mais face à l'ampleur de l'insécurité, il s'est fixé une règle : lorsqu'il trouve 6 failles sur un automate ou un logiciel, il passe à un autre et ne passe pas plus de deux jours d'investigation par automate/logiciel. Le résultat est impressionnant, des dizaines de produits [sont devenus vulnérables](http://aluigi.org/) ! On constate grâce à ses travaux et grâce aux travaux des autres hackers que toutes les couches des systèmes de gestion sont impactés : les réseaux sont parfois perméables, les automates peuvent manifestement être tous compromis car dotés d'architectures trop anciennes, et les outils de supervision sont également faillibles. Un attaquant a donc une surface d'attaque potentiellement très grande à exploiter. Quelques logiciels de configuration sont également touchés, pour ne rien arranger. #La jungle du web Ajouté à cela, les constructeurs ont eux aussi succombé à la mode du web (pas 2.0 néanmoins) et proposent presque tous des serveurs web sur leurs automates afin de les administrer. L'interface web permet divers niveaux de contrôle suivant les marques allant de la modification du code s'exécutant sur l'automate à la simple activation d'options. Ces serveurs web sont bien souvent de piètre qualité, utilisant des technologies telles qu'ActiveX, Flash et consort. Les pages HTML sont de très mauvaise qualité généralement. On constate qu'une grande part des failles divulguées concernent ces serveurs web. Ces serveurs web ne sont pas toujours désactivables, et leur utilité est très limitée ; les installateurs leur préfèrent souvent le logiciel de configuration pour des raisons d'ergonomie. Ces serveurs web sont donc un vecteur d'attaque très important alors qu'ils ne sont que très peu utilisés par les installateurs et les exploitants, une personne malintentionnée et techniquement douée arrivera par contre à faire des choses très poussées avec ce même serveur web. En prime, certains automates ne proposent pas de page d'authentification en HTTPS pour l'administration de ces automates, seule une authentification en HTTP est possible (qui est parfois utilisée au travers du grand Ternet), négligence des concepteurs ou incapacité à implémenter une pile SSL valide sur leur matériel spécifique ? #Des automates qui font le café Certaines marques telles que Wago essaient d'être les plus généralistes possibles : quatre langages de programmation différents, un très large panel de protocoles pris en charge ; on peut raisonnablement s'inquiéter de la nécessité de toutes ces fonctionnalités qui élargissent la surface d'attaque et le nombre de bugs possibles. Cette même marque s'est également démarquée via la révélation d'une porte dérobée dans certains de ces automates, cette _backdoor_ est maintenant publique. #La réponse des acteurs ##Les failles « Forever Day » Face à cet afflux de rapport de vulnérabilités, les constructeurs réagissent de diverses façons : beaucoup ne communiquent pas, certains assument même publiquement qu'ils ne vont [pas publier de correctif](http://securid.novaclic.com/cyber-securite-industrielle/forever-day.html?utm_source=rss&utm_medium=rss&utm_campaign=forever-day). C'est par exemple le cas d'ABB qui a annoncé qu'ils n'allaient pas corriger une vulnérabilité affectant toute une gamme de produit SCADA car considérée en fin de vie, mais malgré tout toujours très utilisée dans l'industrie. Au delà des failles qui ne seront jamais corrigées, certains exploitants ne peuvent mettre à jour certains automates car les programmes qu'ils exécutent ont besoin de certaines failles pour fonctionner (cas de la synchronisation de deux automates grâce à la lecture/écriture de la mémoire de l'un dans l'autre par exemple). On est donc confronté à des mises en œuvre de processus qui seront vulnérables tant qu'elles seront en fonctionnement du fait de ces problématiques. ##Les constructeurs inconscients Les constructeurs n'ayant pas encore été touchés par une vulnérabilité se cantonnent quant à eux à croire en la sécurité de leurs produits ; certains tels que WIT vont même jusqu'à vanter sur les salons la sécurité en avançant des points tels que le coté propriétaire du système, tout en présentant en toute confiance des pages web d'authentification en HTTP depuis l'Internet... Certaines réponses sont aussi très maladroites, le fabricant américain Tridium a récemment répondu à une faille de type [directory traversal](http://en.wikipedia.org/wiki/Directory_traversal_attack) permettant de récupérer le fichier _/etc/passwd_ de ses automates Niagara JACE à travers l'interface web en changeant simplement l'emplacement du fichier incriminé, ce qui n'a bien sûr pas changé quoi que ce soit au problème. #Que faire ? ##Pour les admins réseaux Les administrateurs réseaux doivent auditer tous leurs réseaux, des automates peuvent se cacher dans des endroits improbables (gestion de la ventilation ou autre) et isoler les équipements en question ; il faut aussi bien s'assurer qu'aucun automate ne soit connecté à Internet de quelque manière que ce soit. Les postes de supervision sont tout aussi sensibles et doivent subir le même traitement. Une politique de gestion des droits très fine par utilisateur doit être mise place afin de répondre de manière efficace aux différents problèmes exposés plus haut. Des outils tels que `metasploit` et `nessus` sont régulièrement mis à jour avec les nouveaux exploits, donc vous pouvez les utiliser (avec précaution tout de même sur les systèmes en production), des scripts `nmap` sont également de la partie. ##Pour les exploitants de systèmes La responsabilité des exploitants est de demander un audit complet du réseau et notamment de la partie production. Ils peuvent également faire inclure dans leur contrat de support avec les installateurs une clause pour être averti des failles affectant les produits qu'ils ont en exploitation. ##Pour les concepteurs de systèmes de contrôle Les concepteurs sont ceux qui ont le plus de travail, certains constructeurs avouent sans rougir ne pas avoir mis à jour leurs produits depuis plusieurs années, ce qui fera autant de retard à rattraper. Les conseils qui peuvent leur être prodigués sont nombreux mais on peut déjà citer : * publier des mises à jour quand le besoin s'en fait sentir ; * mettre à la poubelle les automates des années 90 et 2000 pour repartir sur des bases saines ; * reléguer la partie basse du logiciel à des spécialistes en employant des noyaux reconnus tel FreeRT, Linux, QNX ou autres qui savent implémenter correctement des protections et qui permettent de réutiliser des composants plus haut niveau tels que des piles SSL valables ou des interfaces SSH correctement implémentées ; * ne pas implémenter des serveur web partout et se contenter des protocoles déjà reconnus ; * publier des mises-à-jour quand le besoin s'en fait sentir ; * être compatible avec SNMP v3 ; * ne pas installer de porte dérobée. #Conclusion Vous l'aurez compris, le bilan est loin d'être rose. Les systèmes de contrôle industriels étant des systèmes ayant des durées de vie très importantes (jusqu'à 15 ans), on est en droit de s'inquiéter actuellement de leur sécurisation, afin d'éviter les problèmes dans les années à venir. Ces systèmes de contrôles se retrouvent partout, et ils se retrouvent employés dans de nombreux autres domaines, où si ce ne sont pas les mêmes systèmes, les mêmes erreurs de conception sont réalisées... Par exemple, dans le célèbre fast-food au clown, les bornes de commande « commande facile » sont vulnérables à une série de tapotement alterné sur les coins de l'écran tactile de la page d'accueil suivie d'un PIN à quatre chiffres, permettant d'accéder à une interface... très intéressante (NdM.: nous avons retiré une partie des infos détaillant la faille). La [nimage de circonstance](https://www.digitalbond.com/wp-content/uploads/2011/11/DecisionTree.png).

AltStyle によって変換されたページ (->オリジナル) /