Haro sur DNP3, HART, CAN et les autres !
Les protocoles de communication industriels font beaucoup parler d’eux ces temps-ci. La séquence médiatique est toujours la même : des chercheurs en sécurité s’intéressent à un protocole, semblent découvrir qu’il n’est pas sécurisé, montent des expériences édifiantes, publient des articles dévoilant les vulnérabilités ou font des interventions dans des séminaires avec démos à l’appui, et la presse spécialisée en fait ses choux gras.
On a ainsi eu droit aux révélations sur les vulnérabilités DNP3, HART et tout récemment CAN. Cet article passe rapidement en revue ces différents cas et si vous lisez jusqu’au bout vous comprendrez le choix de l’illustration ci-contre !
DNP3
Un binôme de chercheurs en sécurité s’est attaqué l’automne dernier au protocole DNP3, ou plus précisément, a testé toute une gamme d’équipements « parlant » DNP3 pour tester leur résistance à des attaques simples de type fuzzing, overflow… : c’est à dire trames mal formées, protocole non respecté, volume très important etc…
Adam Crain and Chris Sistrunk ont ainsi découvert 25 failles, publiées par le CERT ICS américain, qui en a même fait un document synthétique en plus des alertes individuelles. Il s’agit essentiellement de mauvaises implémentations de la couche applicative, qui permet de causer des dénis de service en y envoyant des données mal formées. Les auteurs n’ont pas cherché à développer des « exploits » permettant effectivement d’injecter des paramètres, du code, ou autre, contrairement au cas du CAN qu’on verra plus bas.
DNP3 est largement utilisé dans le domaine des « smart grids », c’est à dire les équipements des réseaux électriques aux USA, pour en faire le pilotage via des EMS (Energy Management Systems, aujourd’hui similaires à des SCADAs). Le protocole est utilisé des serveurs centraux jusqu’aux boitiers de répartition, sur des liaisons Ethernet fibre pour partie, et avec des liaisons série pour ces derniers. Eric Byres en parle dans un article sur son blog et rappelle au passage que la norme de sécurité NERC-CIP, visant à protéger le réseau électrique nord-américain, exclut les accès par liaison série du périmètre de sécurisation… Comme ces failles se trouvent sur des unités déportées (RTUs) aussi bien que sur les logiciels SCACA, on peut imaginer qu’il est possible d’attaquer le contrôle central du réseau électrique en se connectant à un boitier de répartition de quartier, ce que théorise un autre blogger cité et confirmé par Eric Byres.
A noter que ces révélations sont arrivées peu après l’annonce par Critical Intelligence que shodan, le « google » des services connectés sur internet, repérait depuis septembre les systèmes ayant des ports ouverts correspondants à plusieurs protocoles industriels, dont Profinet et DNP3 !
Des moyens de sécuriser DNP3 existent, même si ça ne résout pas forcément le problème des failles au niveau applicatif. Schneider a dès 2011 fait l’annonce de la prise en charge, dans sa gamme d’automates SCADApack E dédié aux réseaux hydrauliques, d’une version sécurisée du protocole (authentification et chiffrement AGA12, un livre blanc a été publié). D’ailleurs peut-être ont-ils durci l’implémentation DNP3 au niveau applicatif ce qui expliquerait qu’ils ne soient pas dans la liste des équipements avec faille ? (une faille dnp3 plus récente a été annoncée mais sur des produits Telvent, hérités du rachat de cette société)
<mise à jour Avril 2014> : le CERT ICS a étendu la liste des équipements testés et vulnérables (dont un autre constructeur racheté par Schneider en 2010, Control Microsystems, qui édite « ClearSCADA »). Globalement on reste sur des dénis de service non exploitables à distance, donc des scores de vulnérabilités faibles.
HART
HART signifie « Highway Addressable Remote Transducer », ce qui n’aide pas beaucoup à comprendre de quoi il s’agit. Il s’agit d’un protocole maître-esclave permettant de lire les données de capteurs, et qui a la particularité d’implanter une communication « numérique » sur une liaison analogique (4-20mV) existante, par modulation de fréquence. Depuis, des encapsulations sur Ethernet et une version « wireless » (sans fil) ont été développées.
C’est au symposium S4 de ce début d’année que d’autres chercheurs ont recherché des failles sur ce protocole très répandu aux USA. Joe Weiss résume bien la conférence dans un article sur son blog : la faille, liée au protocole et non à un constructeur ou équipement, permet la configuration voire la prise de contrôle d’un ou plusieurs capteurs, et à partir de là, d’influencer sur le processus contrôlé, voire théoriquement permet de remonter vers le réseau de gestion.
Il y eu relativement peu d’écho suite à cette présentation : il est en effet difficile d’imaginer l’impact d’une modification de données de capteurs, voire de la corruption de leur firmware. Si l’on veut causer des dégâts à une installation, jouer sur les données des capteurs est une approche très complexe car cela nécessite de connaître le détail du processus industriel et de son pilotage : c’est généralement plus simple de « simplement » générer des commandes malveillantes…
On voit ainsi que la plus ou moins forte médiatisation de failles de sécurité dépend beaucoup de la facilité à illustrer l’impact de leur exploitation, comme le montre également l’exemple suivant…
CAN
Le buzz en début d’année a été fort sur le protocole CAN (Car Area Network), avec la prochaine mise sur le marché d’un module qui est annoncé comme permettant de pirater ce bus série utilisé dans les véhicules (automobiles, camions…), et qui, comme les deux autres protocoles cités, n’est en rien sécurisé. On pourra ainsi prochainement, pour moins de 30€, acheter un module permettant d’envoyer des ordres aux équipements d’une voiture quelconque (air-bag ouvre toi !), voire même à distance puisqu’il y a à présent des capteurs sans fil courte distance (pression des pneus).
De nombreux articles ont cette fois repris l’information : si pirater les automates d’un réseau électrique ou d’une installation industrielle n’intéresse pas le grand public, le piratage des automobiles est un sujet beaucoup plus porteur!
En français c’est l’article de slate.fr qui est le plus « parlant ». Les abonnés trouveront un article un peu plus mesuré dans le supplément Eco du journal Le Monde daté du 5 mars. En anglais, Slate fait encore plus fort en titrant « For $20 you can turn a car into a hacker zombie » !
Le comble dans le cas présent est que les articles sont rédigés sur la base du résumé d’une conférence qui n’a pas encore eu lieu à cette date (Black Hat Asia, fin mars 2014) !
Et alors, que faire ?
A la fin de son billet concernant HART, Joe Weiss se demande s’il ne faudrait pas revenir à des câbles analogiques et des signaux 4-20mV, tant la surface d’attaque des réseaux industriels numériques est élevée, vu le nombre toujours croissant d’équipements programmés et surtout de la publication de leurs failles.
Eric Byres suggère pour sa part d’installer des filtres applicatifs au cœur des réseaux DNP3 (rappel : il est patron de Tofino qui en vend, ce qui n’ôte rien à la pertinence de la suggestion).
Pour CAN on n’a pas encore vraiment de solution, d’ailleurs en réalité on n’a pas encore de problème (la conférence n’ayant pas encore eu lieu), mais cela semble fortement plausible.
Ceci dit, pas de panique : pour les professionnels du domaine, il n’y a là rien de vraiment nouveau. En fait il y a une devise Shadock qui me semble tout à fait appropriée : « s’il n’y a pas de solution, c’est qu’il n’y a pas de problème ». Je m’explique…
L’hypothèse de base dans les études de sécurisation de SIs industriels est que l’accès physique à un réseau industriel permet de faire à peu près n’importe quoi : arrêter un automate, envoyer des commandes illégitimes, voire reprogrammer des firmwares.
C’est intéressant d’avoir régulièrement des rappels mais heureusement les solutions sont connues et commencent à être mises en œuvre : approches architecturales (défense en profondeur, zones), détection d’intrusion, protection physique, et, dans quelques cas, remise en œuvre de systèmes câblés analogiques, comme le suggère Joe Weiss.
Donc en effet pas vraiment de solution pour résoudre le problème spécifique de la sécurité des protocoles industriels, mais on a des solutions alternatives qui fonctionnent, et donc pas de problème !
P.S. la citation la plus adaptée est celle d’Einstein : « s’il n’y a pas de solution c’est que le problème est mal posé », mais je préfère la version Shadock ! Merci au site « Problèmes et solutions« …
Dans la série des « révélations » sur la facilité à hacker ces bus, à noter la dernière en date sur CAN sur le blog de Digital Bond, qui présente l’intérêt d’être didactique sur la techno CAN :
http://www.digitalbond.com/blog/2015/04/13/attacking-canbus-part-1/
Dans le commentaire ci-dessous, il est indiqué que la suggestion de Joe Weiss de remettre en place des systèmes câblés à certains endroits est probablement humoristique.
En réalité, c’est effectivement une solution utilisable (et au moins réalisée une fois sur mon conseil) dans certains cas particuliers (ex : un système de sûreté simple) – donc c’est tout à fait sérieux même si cela peut paraître étonnant.
La découverte de « failles » dans les protocoles industriels aussi bien que dans leur implémentation est une copie dela chasse au bug sur TCP/IP qui a eu cours à la fin des années 90.
À l’époque, pas 6 mois sans qu’une annonce fracassante (le ping de la mort, ICMP Redirect, les numéros de séquence consécutifs, etc) ne viennent encombrer Usenet.
On constate que quel que soit le support le marché de la peur fonctionne toujours.
Il faut faire peur pour tenter de vendre quitte à répéter ce que d’autres ont trouvé.
Je trouve dommage de réduire le rôle du conseil/consultant à cela : ce n’est pas un tabloïd !
Qui plus est, ça ne fonctionnait pas forcément il y a 20 ans [1] et ça fonctionne encore moins à présent (la crise) et surtout pas dans le monde industriel : impossibilité d’agir (on ne change pas un automate comme on remplace un serveur qui est immobilisé 3 ans et quand bien même, le pauvre, je ne pense pas qu’un automate de 1990 supporte la dernière version de DNP3, Profinet et autres), longévité des équipements, investissements colossaux, autre culture.
Ça ne fonctionne tellement pas qu’il faut en passer par la case législation pour tenter d’imposer un minimum aux OIV !
Que les chercheurs fassent leur boulot. Seuls eux ont le temps et l’argent nécessaire pour faire ce travail.
Les informations produites sont avant tout à destination des concepteurs de systèmes industriels afin qu’ils s’améliorent, enfin !
Ce que l’on attend d’un conseiller n’est pas qu’il fasse peur, que diable !
Les responsables avec qui j’ai pu discuter lors de présentations ou de conférences ont déjà peur depuis de nombreuses années et prient pour qu’un accident majeur ne survienne pas (ou alors un tout petit incident afin qu’enfin de maigres subsides puissent être débloqués afin de placer un minimum de garde-fous).
Non, on attend du conseil qu’il propose des SOLUTIONS, en clair ce qu’il est possible de faire afin de tenter de contourner voire neutraliser ces failles.
Encore une fois, les résultats de recherche ne sont pas là pour faire peur mais pour nous aider à comprendre des choses qui sont, par définition, cachées.
Cachées par l’entremise de NDA, cachées par des entreprises enfermées sur elles-mêmes et qui ont le culte du secret par défaut et cachées, enfin, par des secrets qui n’ont plus cours à l’heure des réseaux sociaux et de l’impact civil.
Ces résultats sont là également afin d’être à même d’imaginer des solutions à ces problèmes.
C’est grâce au travail de ces chercheurs que nous disposons aujourd’hui de tonnes d’outils, de bibliothèques, de documents permettant de comprendre un système industriel, d’analyser, d’émuler voire de simuler des protocoles industriels.
C’est une chance phénoménale !
Pourquoi ne pas embrayer sur cette joyeuse nouvelle plutôt que de continuer à la jouer années 90 ?
Quand à l’avis de Joe Weiss, tout en respectant le bonhomme, je pense qu’il ne va pas assez loin : revenons au travail manuel (un capteur dans chaque main et on annonce la valeur à la cantonade).
Au moins cela fera de l’emploi.
Je plaisante … tout comme le sieur Weiss.
—
Concernant CAN, si le sujet est pertinent, le buzz entourant la présentation de la BlackHat Asia 2014 est tout simplement de l’hypocrisie.
CAN a déjà été présenté maintes fois en conférence internationale.
Un site très fouillé, canbushack.com, existe depuis 2009. Ses représentants seront d’ailleurs présents à Blackhat USA au mois d’août afin de proposer des formations (> 2 200 USD tout de même !).
Cela a commencé en 2010 avec les premières publications et les premières conférences sur le sujet : IEEE Symposium on Security and Privacy en 2010, UsenixSec 2011, des articles de l’université de Washington ou de San Diego, et j’en passe dont le programme CarShark pour, finalement, arriver à la Defcon 21 de 2013.
Dès 2009 et surtout à partir de 2010, on sait que l’implémentation de CAN dans les véhicules (américains au moins) est faible : faible d’authentification des composants (ECU), peu de paquets différents conduisant à une interprétation rapide et reprogrammation assez aisée de certains ECU (comme le lecteur media), sensibilité importante des composants (ECU) aux paquets foireux, fuzzing dévastateur.
Voici ce qu’écrivait à l’époque (2010) l’un des chercheurs :
« In our car we identified no fewer than five kinds of digital radio interfaces accepting outside input, some over only a short range and others over indefinite distance. While outside the scope of this paper, we wish to be clear that vulnerabilities in such services are not purely theoretical. We have developed the ability to remotely compromise key ECUs in our car via externally-facing vulnerabilities, amplify the impact of these remote compromises using the results in this paper, and ultimately monitor and control our car remotely over the Internet. »
Et, également, un autre :
In starting this project we expected to spend significant effort reverse-engineering, with non-trivial effort to identify and exploit each subtle vulnerability. However, we found existing automotive systems — at least those we tested — to be tremendously fragile. Indeed, our simple fuzzing infrastructure was very effective and to our surprise, a large fraction of the random packets we sent resulted in changes to the state of our car.
Sachant qu’il existe des adaptateurs USB to CAN sur le marché (250 euros tout de même) la porte est directement ouverte pour du hacking à partir d’un ordinateur portable d’autant que certaines bibliothèques existent toutes faites (python-can pour ne citer que celle là).
On imagine donc ce qu’il est désormais possible de faire avec une Framboise 314 [3] (qui n’existait pas en 2010) et, bientôt, avec l’Edison d’Intel, 2 plates-formes auxquelles il est très facile d’ajouter des composants communicants (WiFi, BT, M2M) et pour lesquels il est encore plus facile de programmer (Shell script, python, ruby) que sur un microcontrôleur.
À l’issue de la Defcon 21 un outil de reprogrammation de la partie data des ECU utilisés dans le groupe Volkswagen est sorti (https://github.com/fjvva/ecu-tool) permettant de pratiquer du chiptuning.
Donc, le sujet de la conférence est intéressant mais planquer l’information, prétendre que les outils ne seront pas divulgués (voir Engadget) cela va à l’encontre de l’objet du chercheur.
Et ce, d’autant que l’essentiel a été fait dans les années précédentes.
Hypocrisie !
À moins qu’il s’agisse de protection vis-à-vis d’une probable condamnation de ladite conférence comme ce fut le cas à la BlackHat 2011 (ou DefCon, je ne sais plus) où une révélation un peu hâtive des failles de la carte Mifare Classic servant de support au MTA de New York avait déclenché les foudres de cette dernière et interdit la communication. Là non plus il n’y avait pas péril en la demeure car les failles de la Mifare Classic sont connues depuis 2007, l’intérêt de la conférence résidait davantage dans la connaissance des structures de données figurant sur cette carte et leur signification.
Comme précédemment, je serai bien plus intéressé par une présentation des SOLUTIONS que, encore une fois, de la matière à faire peur.
Les conférences de hacking méritent bien mieux !
—
Ah, encore une chose : je préférerais que l’on parle de procédé et non de processus industriel.
Je chipote mais s’il y a 2 mots c’est qu’il y a 2 sens.
Il y a bien une notion de séquencement (on procède) mais un procédé est, selon moi, avant tout technique et un processus est avant tout organisationnel.
ISO 9001 ne fait pas clairement la distinction (sans doute pour des raisons liées à la langue anglaise ou process signifie à la fois processus et procédé).
Dans d’autres référentiels comme le BPMS, le procédé est une partie de la procédure tous deux appartenant au monde de la solution tandis que que le processus appartient au monde de la décision.
Pour me résumer : le procédé est stocké dans la machine numérique, le processus dans le progiciel de gestion ce dernier assurant les entrées et les sorties du procédé.
[1] Même en piratant les annuaires des téléphones Bluetooth présents dans la salle de conférence : ça faisait rire les auditeurs mais ne les émouvaient pas outre mesure.
De vrais potaches qui riaient de la bonne farce faite à leur voisin tout en espérant que cela ne leur arrive pas en dehors de la salle.
[2] http://video.foxbusiness.com/v/2566303720001/hackers-can-take-control-of-your-car/#sp=show-clips
https://media.defcon.org/DEF%20CON%2021/DEF%20CON%2021%20video%20and%20slides/DEF%20CON%2021%20Hacking%20Conference%20Presentation%20By%20Charlie%20Miller%20and%20Chris%20Valasek%20-%20Adventures%20in%20Automotive%20Networks%20and%20Control%20Units%20-%20Video%20and%20Slides.m4v
[3] Raspberry Pi.
db