Les conférences Black Hat et DEF CON à Las Vegas sont les événements cybersécurité de l’été aux USA, avec chaque année des douzaines d’interventions, y compris sur les systèmes industriels. Cet article analyse celles concernant la cybersécurité industrielle.

Je vais uniquement parler de présentations faites à la conférence Black Hat, parce qu’il n’y avait pas de sujet « industriel » à DEF CON (sauf erreur). Ce dernier est un événement traditionnellement moins sérieux, ou plus fun suivant le point de vue, et apparemment les SCADAs ce n’est pas assez fun. La liste des présentations DEF CON est téléchargeable ici, si quelqu’un veut vérifier et me prévenir le cas échéant !

Concernant Black Hat, les seuls éléments ayant retenu l’attention des media français sont les consignes de sécurité à l’intention des journalistes – comme couper le bluetooth et le wifi de leurs smartphones, ne pas accepter de clé USB d’un inconnu… On trouvera le détail dans plusieurs articles comme celui du Point ou ce billet chez Qualys. Pour rappel, les mots de passes piratés sont affichés au vu de tous sur un « wall of sheep » qui existe pour les deux événements.

La plupart des conférences de Black Hat sont commentées sur le site de dark reading (en anglais), avec la liste intégrale des interventions disponible sur le site de Black Hat. Il y a peu de choses disponibles en français, on peut patienter en (re-)découvrant le résumé de la version Black Hat Europe de ce printemps, commentée par Advens, en particulier la conférence « honey pot » reprise et enrichie pour Black USA (voir plus bas) : vous faites donc bien de parcourir le présent article !

Les conférences

Trois conférences concernaient directement les systèmes industriels, je les détaille par ordre d’intérêt croissant.

Une cyber-attaque un peu trop facile

Une présentation « pédagogique » a été effectuée par Brian Meixell et Eric Forner (Cimation). Leurs supports très bien faits s’adressent à des personnes peu au fait des réseaux industriels,  ils commencent par introduire les principaux composants (API, SNCC, etc…), les architectures réseaux, leurs vulnérabilités, et la facilité de mener une attaque.

Le clou du spectacle était la démonstration d’une attaque sur une simulation de pompe de puis de pétrole (les systèmes de pilotage d’installations pétrolières est le métier des intervenants).

C’est un peu curieux de voir ce type de présentation en 2013, alors qu’il y a deux ans il y avait des démos plus techniques sur des équipements réels, et qu’à priori les points présentés sont bien connus par toutes les personnes s’intéressant au sujet. Le souhait des organisateurs était sans doute d’avoir une présentation « tout public » du sujet industriel, bien réalisée et efficace en termes de communication.

Objectif atteint pour la comm’ : les auteurs prennent le contrôle d’un historian, d’un poste de développement, et à partir de là ils indiquent qu’on peut facilement changer le programme de l’automate pour supprimer une fonction de sûreté, envoyer via modbus de fausses données lues au serveur I/O pour que l’affichage soit correct, tout cela ayant finalement pour conséquence l’envoi de commandes non adaptées aux pompes jusqu’à causer le rejet de pétrole dans l’environnement.

Le matériel choisi avait des stacks TCP/IP non résistantes aux attaques de spoofing et main in the middle (permettant d’intercepter les trames et les manipuler), les automates n’avaient pas de systèmes d’authentification (même limité), il n’y avait aucun équipement de sécurité, les systèmes Windows n’étaient pas à jour : certes c’est souvent le cas, mais du coup c’est « normal » de faire ce qu’on veut sur le réseau.

Pour avoir fait ce type de démo de hacking je me dis que la barre pour les intervenants « industriels » à Black Hat n’est pas très haute, mais la qualité de la présentation justifie sans doute sa sélection dans la catégorie « pédagogique ». D’ailleurs on regrette de ne pas avoir ce type de support mis à disposition pour les sensibilisations en France : l’ANSSI fait des documents, mais quelques supports un peu plus utilisables en sensibilisation (présentation, video…) seraient bienvenus !

La présentation se termine par quelques conclusions de bon sens sur les mesures de sécurité de base à mettre en œuvre : filtrage réseau, mise à jour des systèmes Windows et durcissement…

La présentation en anglais est disponible ici, une autre analyse en anglais aussi est là.

La cyber-attaque à grande distance grâce aux réseaux sans fil

« Compromising industrial facilities from 40 miles away » : si le titre semble racoleur, le contenu de l’exposé de Lucas Apa et Carlos Mario Penagos est effectivement intéressant. Les auteurs ont voulu démontrer que l’utilisation de réseaux sans fils (essentiellement pour des capteurs), que ce soit Zigbee, ISA100 ou WirelessHart, présente un risque important, malgré l’utilisation (en théorie) d’un chiffrement de niveau adéquat (AES-128 bits).

Le problème vient de la mise en œuvre du chiffrement par les équipementiers et non à la technologie à la base. Trois produits d’équipementiers différents, chacun leader de leur secteur, sont passés au crible et leur vulnérabilité est expliquée, et démontrée (exploitée).

On peut trouver un point commun entre les vulnérabilités dans les trois exemples : en l’absence de « PKI » digne de ce nom (gestion des clés et certificats), les solutions sont le plus souvent d’utiliser une clé « fabriquant » et une clé générée pour l’installation, qu’il faut installer sur tous les équipements. En voulant faciliter ces étapes, les constructeurs réduisent très fortement l’intérêt du chiffrement.

Les noms des équipementiers ne sont pas donnés, ni les caractéristiques des réseaux, qui sont masqués dans les copies d’écran des interfaces de configuration présentées – je suppose que leurs utilisateurs pourront cependant les reconnaitre.

Les trois exemples présentés sont :

• un produit propose de générer une clé 128bits, mais avec une « entropie » trop faible : le générateur de nombres aléatoires est initialisé par la date, le nombre de clés 128 bits est ainsi trop limité car il ne faut quelques secondes pour créer un fichier avec l’ensemble des clés possibles (une clé par seconde sur une période de temps, cela fait « beaucoup » de clés possibles mais beaucoup moins que 128 bits). Évidemment il est possible de saisir une autre clé, mais je veux bien parier que c’est rarement fait. Le problème de la génération « aléatoire » de clés par ordinateur est souvent sous-estimé, cet exemple intéressant aide à le comprendre.

  

  Un générateur de clé à faible entropie

• dans le second exemple, une solution de gestion de clés est intégrée à l’outil de développement, qui de manière transparente insère la clé dans les fichiers de configuration qui sont chargés dans les capteurs sans fil. Il suffit donc de repérer quels octets portent la clé (a priori les seuls qui changent si on régénère les binaires à des dates différentes – la date étant aussi la source du générateur), et ensuite, pour s’attaquer à un vrai site utilisant cet outil de développement, il faut récupérer  un ou plusieurs équipements ou en retirer les binaires et lire les clés (via port série ou USB). Il faut donc avoir accès physique aux capteurs (ou aux capteurs en panne jetés ou remplacés…).  Cependant les auteurs, après tous ces efforts, se sont aperçu au moment de préparer la démo de mise en œuvre des attaques (video présentée en session),  que les clés n’étaient utilisées que pour l’authentification, mais pas pour les échanges, et qu’il était possible d’injecter des fausses données par simple réplication des trames sans avoir à trouver les clés. En réalité la situation est un peu plus compliquée car il faut aussi la clé du constructeur, mais les auteurs n’ont eu aucune difficulté à la trouver via recherche internet (compréhension firmware) et lecture du firmware du composant.

  

  Pas de sécurité sans PKI

• dans le troisième exemple, le produit est présenté par le fabricant (leader mondial) comme présentant un niveau de sécurité inégalé. Le détail de la technique utilisée est présentée dans les supports, mais en gros on tombe de sa chaise si on est assis, car le fournisseur explique que c’est grâce à son protocole propriétaire, au saut de fréquence pseudo-aléatoire et à la transmission de données en clair que l’on se protège puisque « seules les données » sont échangées (retranscription texto de la source en anglais).

  

  Le constructeur n’a pas compris le sujet

En conclusion de leurs présentations, les auteurs mettent en perspective ces vulnérabilités en rappelant que la manipulation à distance de données de capteurs, voire leur mise en panne si en plus ils présentent des vulnérabilités au niveau de l’interface réseau, peut avoir des conséquences importantes sur le procédé piloté. Ils donnent aussi quelques recommandations concernant la vigilance, les audits réguliers… J’aurais aussi indiqué « services achats » : un service achats sensibilisé au sujet de la cybersécurité me semble un impératif aujourd’hui !

Les supports de leur présentation sont téléchargeables (en anglais). Sur ce sujet un article 01business du 14 août donne plus de détails sur les impacts possibles et les techniques mis en œuvre.

Plus fort que le honeypot « SCADA », le honeynet !

Ce printemps, Kyle Wilhoit, chercheur chez Trend Micro, avait publié un document intitulé « Qui attaque vraiment vos équipements de contrôle-commande » (Who’s Really Attacking Your ICS Equipment?). L’auteur a remis le couvert à Black Hat, avec une version améliorée de son étude. Une courte description en français et les liens vers l’étude initiale sont disponible sur le site Advens (voir section 7).

L’étude initiale consistait à rendre accessible par internet deux versions simulées (sur machines virtuelles) de pseudo-systèmes municipaux de traitement des eaux, qui semblent vulnérables, ce qui stimule les attaquants et permet de surveiller la nature et l’origine des cyber-attaques. C’est ce qu’on appelle un « honeypot » (pot de miel), utilisé en général pour détecter une attaque en mettant en place dans une infrastructure un élément plus vulnérable que les autres et qui sera le premier signal d’une attaque (comme les rosiers en bordure de vigne). Je passe sur les résultats de cette première étude, qu’on peut consulter (en anglais) dans l’article original, car les nouveaux résultats sont plus détaillés.

L’auteur avec l’aide des ressources de Trend Micro sans doute (vu le succès de la précédente publication), a amélioré son dispositif de trois manières :

• 12 instances au lieu d’un seul « honeypot », réparties autour du globe, pour constituer un « honeynet » (je découvre le terme), sous forme de systèmes indépendants (un pirate ne peut pas passer de l’un à l’autre). Un gros effort de « localisation » a été fait, pour que chaque instance paraisse être une installation locale de traitement des eaux,
• simulation plus fine pour donner les apparences d’un vrai système de traitement des eaux, avec automates Schneider, IHM, serveur web etc…, le tout fonctionnant sur trois machines virtuelles,
• mise en œuvre de moyens plus fins de recherche de la source des attaques, via des scripts et applets qui se téléchargent sur le navigateur du pirate et collectent des infos de wifi, de type de systèmes, utilisation Tor ou pas etc…Pour les détails technique, voir le document de Kyle Wilhoit.

L’expérience a duré trois mois, et confirme l’hacktivisme ambiant puisque 74 attaques ont eu lieu  (les auteurs ont exclu les robots d’attaque automatique sinon les chiffres seraient bien supérieurs – sur un serveur web personnel non référencé sur internet, j’enregistre une douzaine d’attaques par jour !).

Les chercheurs ont classé les attaques en deux catégories : la majorité « non critiques » (pas de volonté de nuire, exploration et récupération d’information au pire) et 10 attaques « critiques », c’est à dire dont les actions si elles étaient réalisées sur un vrai système pourrait avoir des conséquences graves (pannes, pollution…).

Certaines attaques utilisaient des approches basiques (brute-force avec dictionnaire sur logon de l’IHM accessible par HTTP), d’autres étaient plus subtiles, mais globalement les attaques respectent les étapes standards : découverte du réseau, identification des OS des machines détectées, recherche de vulnérabilité, prise de contrôle, et rebond sur les autres systèmes. A ce stade on s’étonne quand même : faire une découverte du réseau local nécessite d’y avoir accès, donc d’avoir déjà compromis un système, ou alors ils ont mis directement sur internet tout leur environnement, ce qui n’est pas réaliste d’une vraie installation… C’est un point que je vais tâcher de préciser et je mettrai cet article à jour.

Évidemment le plus intéressant est la géographie des attaquants, l’information sur l’origine des attaques étant fiabilisée par des outils rajoutés au honeypot (voir le détail concernant les outils BeEF dans leur papier).

Voici ce que donne la répartition des attaques non critiques :

Source des attaques non critiques

Sur les douze honeypots, 3 sont en Russie : les auteurs indiquent que la plupart des attaques détectées viennent du même pays, mais cela ne suffit pas à expliquer le fait que 2/3 des attaques non critiques viennent de Russie. Les statistiques ne sont pas expliquées et les auteurs reconnaissent ne pas pouvoir donner d’explication. Est-ce que le hacking amateur est devenu un passe-temps en Russie ? Est-ce que le coût de l’eau est trop élevé et les gens veulent se venger sur ce qu’ils pensent être la compagnie des eaux locale ? Les auteurs suggèrent le vol d’information mais on peut être dubitatif…

La répartition des attaques critiques (10 au total) est tout aussi tranchée :

Source des attaques critiques

Les chinois semblent clairement être à la manœuvre (les auteurs indiquent que les attaques proviennent de 4 adresses IP de 2 sous-réseaux différents). C’est une « confirmation » qui fera plaisir aux gens de Mandiant qui dans leur rapport pointent également la Chine comme source majeure des attaques informatiques.

Pour les attaques critiques, les auteurs ne peuvent que reconnaitre leur difficulté à trouver des motivations, et on ne peut que conjecturer : « exercices » pour entrainer les hackers de la « blue army » ?, campagne tous azimuts pour attaquer les systèmes sur internet (mais on aurait des alertes sur les vrais systèmes !?). Les auteurs insistent sur le fait qu’ils ont bien fait la distinction entre des dégâts « accidentels », causé par des hackers faisant des erreurs, et les attaques volontairement malignes, visant en connaissance de cause à causer des dégâts, ce qui est donc a priori le cas de ces 5 attaques…

On peut vraiment se poser des questions sur ces résultats, mais évidemment l’intérêt est de montrer qu’il y a en permanence, et dans plusieurs pays (ok, dans certains pays), des hackers amateurs et plus sérieux, qui utilisent shodan et autres systèmes pour repérer, et attaquer, des systèmes de contrôle-commande accessibles sur internet.

Les auteurs finissent (un peu en queue de poisson donc…) leur article en rappelant 7 bonnes pratiques, dont je n’indique pas le détail mais seulement les titres :

• contrôle des clés USB,
• détection d’intrusion sur les réseaux,
• durcissement et contrôle d’exécution d’applications (par white list),
• établir une classification des données (secret, confidentiel, public…) – là il y a un peu une dérive car on est sur un système industriel, il serait plus pertinent de faire une classification en fonction de l’impact des systèmes en cas de piratage mais bon,
• mettre en œuvre un référentiel de cybersécurité, les auteurs citent le NIST (je complèterais en indiquent NIST 800-82 et on sera d’accord),
• faire des test d’intrusion trimestriels pour vérifier que les vulnérabilités sont patchées (là aussi c’est un réflexe de sécurité des SIs, voire mon article sur le sujet),
• gérer les vulnérabilités, utiliser un système de détection de vulnérabilités, patcher (même remarque).

En conclusion sur cette présentation : les auteurs ont monté un réseau de honeypots très impressionnant, mais on reste sur sa faim en termes d’interprétation et compréhension des résultats. Et les recommandations sont curieuses, peu adaptées à l’environnement industriel : les auteurs sont sans doute plus habitués à travailler sur des problématiques de serveurs web.

Il semble évident qu’il faut avant tout ne pas connecter les systèmes industriels à l’internet, et si c’est vraiment indispensable (pour une maintenance à distance), mettre en frontal un équipement durci avec authentification forte, et pas le frontal web fourni par le fournisseur d’automate ou de SCADA.

Conclusion sur black hat 2013

Les interventions restent moyennement pertinentes quant aux vrais enjeux de la cybersécurité industrielle, et on fait une fois de plus le constat qu’il y a finalement peu (ou pas) de chercheurs à la fois compétents en hacking, capables de monter des manips poussées, et conscients des enjeux des SI industriels.

Mais surtout on retire de ces trois conférences plus de questions que de réponses, notamment sur l’état réel des menaces, la motivation et le niveau de technicité des attaquants. Il reste donc difficile de justifier une politique de sécurisation des SIs industriels, et aujourd’hui c’est  surtout la vision qu’en ont les décideurs qui détermine les efforts et investissements effectués.

Peut-être aura-t’on plus d’éléments de réponse en octobre lors de la conférence annuelle organisée par Joe Weiss, maintenant appelée « ICS Cyber Security Conference« , entièrement consacrée aux systèmes industriels (ICS en anglais).

Post-scriptum : automates et hôpitaux…

Une conférence a traité du domaine médical, où les enjeux (impacts sur les personnes) et l’environnement (temps réel, 24/7, systèmes figés, etc…) sont comparables aux systèmes industriels, et où on retrouve donc le même type de vulnérabilité et de manque de solutions, notamment l’absence de mises à jour de sécurité par les fournisseurs. On est en dehors du sujet « industriel »,  je recommande juste la lecture de cette analyse en anglais, sachant que les supports ne sont pas disponibles. L’analyse établit aussi le parallèle avec les « SCADA », qui est le raccourci habituel dans la presse pour faire référence aux systèmes industriels.

Tags: ANSSI, Automates, Honeypot, SCADA