Le symposium S4, qui a eu lieu fin janvier à Miami, marque une nouvelle étape dans l’odyssée de Charybde à Scylla de la cybersécurité industrielle. Comme après la conférence « Black Hat » de l’été 2011, les informations présentées obligent à repenser – à nouveau – la sécurité des installations.

Le point clé de ce symposium est que la génération actuelle d’automates industriels présente des failles béantes de sécurité, tous constructeurs confondus. Ces failles sont très difficiles à colmater car liées au design, mais sont très faciles à exploiter par des logiciels malveillants ou des pirates.

L’article présente une synthèse des principales conférences de ce symposium, et en tire les conséquences pour les fournisseurs et les industriels.

Les différentes conférences

Voici les conférences détaillées dans l’article :

• une étude avec des statistiques très parlantes sur la dernière décennie et sur 2011,
• le projet BaseCamp, et ses analyses accablantes sur la sécurité des automates,
• Ralph Langer qui en 45mn a décortiqué le « payload » de Stuxnet,
• une étude sur les systèmes industriels connectés à l’internet.

Tous les liens sont fournis dans l’article, à noter que toutes les sources sont en Anglais. Cette conférence, largement commentée dans la blogosphère spécialisée du monde anglo-saxon, n’a encore eu aucun écho sur les sites d’information français – sans doute parce qu’un peu technique. Une analyse est en effet nécessaire, dont acte !

Analyse statistique des vulnérabilités dans le contrôle-commande

Sean McBride a regroupé dans une présentation de 88 pages des statistiques très parlantes sur les vulnérabilités des SCADAs et automates. Les points clés sont donnés en Anglais sur le blog de Tofino, avec accès au téléchargement de la présentation (nécessite de s’enregistrer). Voici ce qui me semble le plus important à noter.

Confirmation de l’explosion du nombre de failles découvertes, dont je me suis déjà fait l’écho sur ce blog (cliquez sur le graphique pour l’avoir en grand) :

Confirmation également que tous les fournisseurs sont impactés : aucun n’a mis en pratique l’état de l’art de la sécurité informatique. Mais celle-ci n’était effectivement pas d’actualité dans le monde industriel avant 2011. Confirmation également que les solutions ne suivent pas, i.e. les fournisseurs ne sont pas pressés de fournir des patchs pour corriger les problèmes de sécurité :

Plus inquiétant encore que le nombre de patchs disponibles : leur inefficacité. En effet, il semble que 60% (chiffres du CERT ICS) des correctifs ne résolvent en fait pas le problème : nous verrons plus bas que c’est en fait « normal », du fait de la nature des failles.

Sean mentionne dans sa conférence quelques exemples : patchs Siemens qui sont facilement contournés (i.e. pirates sont à peine gênés), ou des patchs qui visent à empêcher l’attaque par les « exploits » publiquement disponibles, mais ne corrigent pas réellement la faille.

La liste des « exploits », i.e. recette ou code permettant d’utiliser la faille pour attaquer et mettre en panne ou prendre le contrôle des équipements, est également très longue (attaques publiquement disponibles sur internet) :

Dans la mesure où peu de patchs sont disponibles, qu’ils sont en majorité inefficaces, et que de toutes manières il n’est pas aisé d’appliquer des correctifs sur des systèmes de production en fonctionnement, on mesure l’extrême vulnérabilité des installations.

A noter que cette liste n’inclut pas les nouvelles vulnérabilités et « exploits » révélés par le projet BootCamp, lors de cette même conférence.

BootCamp : la démonstration de l’absence de sécurité des automates

Les automates programmables industriels (API) sont des équipements coûteux (le prix d’une voiture)  au cœur des installations industrielles, ils pilotent en temps réel des processus quelquefois très complexes. Les automates ont des « protections » par mots de passe pour accéder aux portions de code, quelquefois même aux variables.

Ces protections sont toutes relatives dans la mesure où les protocoles servant à les configurer, via Ethernet de nos jours, sont en clair (non chiffrés). Donc il est relativement facile d’intercepter les mots de passe via des attaques réseaux de base (ARP table poisonning etc…)

Stuxnet avait utilisé des faiblesses dans les automates Siemens, mais pour cela a dû mettre en œuvre un mécanisme d’attaque très complexe (faille permettant d’insérer plusieurs portions de code et de données – voir le prochain sujet plus bas). On avait déjà eu droit à d’autres révélations, notamment les failles de sécurité des cartes réseaux de toute la gamme Schneider : des « backdoors » (publiquement connues à présent) permettent d’y injecter le firmware que l’on veut, entre autres failles (CVSS – échelle de gravité – 10/10).

Bootcamp nous oblige à relativiser ces précédentes alertes, car les failles trouvées sont à la fois plus graves, plus faciles à exploiter, et plus difficiles à corriger.

Le projet BootCamp est présenté par ses membres comme une réaction face à l’inertie des fabricants, démontrée par les statistiques de Sean McBride présentées précédemment. Ces chercheurs ont décidé de frapper fort en faisant publiquement la preuve de la vulnérabilité de la plupart des automates, allant jusqu’à développer des « exploits ».

Pour cela ils ont monté un projet lancé à l’automne 2011, avec pour objectif de faire cette présentation lors du symposium S4. Parmi ces chercheurs figurent Dillon Berresford (voir l’article sur sa démo de l’été 2011), Ruben Santamarta, qui a dévoilé les failles Schneider, et quatre autres contributeurs.

D’un point de vue plus technique, le projet BootCamp visait aussi à dénoncer l’aberration que constitue la décision du CERT ICS, à l’automne dernier, de ne lancer des alertes que sur les failles de développement (« bugs » de sécurité), mais pas sur les problèmes de « design ». Par exemple, la nécessité d’utiliser TFTP (protocole non sécurisé, espionnable) pour configurer les automates GE D20 n’est pas considéré comme une faille par le CERT ICS, or cela permet clairement de faire ce que l’on veut si l’on a accès au réseau.

On peut visualiser en ligne la video de l’intervention et consulter l’article présentant l’équipe, la méthode et les résultats. Un rapport complet est annoncé, pas encore disponible.  Le principal résultat des tests sur les différents automates est présenté dans ce tableau :

• la croix rouge signifie qu’il y a une faille facilement exploitable sur la fonctionnalité (exemple : Backdoors sur Schneider et GE : des mots de passe à peine cachés – et à présent publics – permettent d’accéder au système et de modifier la configuration via HTTP, telnet ou ftp pour charger le fimware),
• le point d’exclamation signifie qu’il y a une faille mais moins facile à exploiter,
• et la coche verte signifie qu’il n’a pas été trouvé de faille,
• concernant les « absents » de cette liste : Siemens ayant déjà été largement épinglé, les chercheurs se sont focalisés sur les autres constructeurs ; cependant Ralph Langer y revient dans sa conférence sur Stuxnet (voir plus bas). Wago a également été passé au crible avec de nombreuses failles trouvées, mais pour une raison inconnue n’a pas été intégré dans ce tableau.

Des « exploits » existent déjà, certains développés par les chercheurs, et sont inclus dans le logiciel publiquement disponible « metasploit », qui permet à tout le monde de jouer au hacker. La société Tenable a également communiqué sur la disponibilité d’une mise à jour de leur produit de détection de vulnérabilités « nessus », permettant la détection de toutes les vulnérabilités présentées.

Ces failles ne sont sans doute que la partie émergée de l’iceberg : on pourrait en effet reprocher à l’équipe BaseCamp de rendre ainsi publiques des informations qui peuvent être exploitées par des hackers malveillants (les « black hat »), mais vue la facilité de détecter ces failles, les « black hat » peuvent également les trouver et développer des « exploits » sans qu’on le sache (comme pour Stuxnet). Il est donc préférable que soit rendu public le niveau de vulnérabilité de ces systèmes pour forcer les clients, et les fournisseurs, à enfin réagir de manière adaptée.

Sur ce point justement, l’absence de réaction des différents constructeurs est dénoncée dans un autre article de DigitalBonds (organisateurs du symposium) : cette inertie est interprétée par Eric Byres comme le résultat de l’absence d’exigences exprimée par les clients, comme il l’avait précédemment déjà dénoncé.

Avec ces révélations, il est encore plus facile aujourd’hui de concevoir un Stuxnet. On sait en effet que Stuxnet était d’une (trop ?) grande complexité, comme l’a présenté Ralph Langer, premier chercheur à l’étudier, dans la conférence suivante (pour une introduction à Stuxnet, voir l’article correspondant de ce blog).

Le « payload » de Stuxnet expliqué : le « deep dive »

Ralph Langer l’avait annoncé à l’automne : il a présenté lors d’une conférence de 45mn une analyse complète de la « charge active » (payload en termes techniques) injectée par Stuxnet dans les automates de l’usine d’enrichissement de Natanz en Iran. L’exposé s’adresse aux initiés, et donc outre le besoin de bien comprendre l’Anglais, il faut avoir des bases de programmation des automates industriels et être déjà familiarisé avec Stuxnet. Avec ces pré-requis, le visionnement est intéressant.

(extrait de la présentation de Ralph Langer) Photos publiées sur le site web de la présidence iranienne, ayant aidé à analyser (et peut-être concevoir) Stuxnet

Les points clés présentés par Ralph sont :

• la preuve que la cible était bien l’usine d’enrichissement d’uranium de Natanz en Iran,
• les portions de code insérés dans les automates, leur fonctionnement exact,
• au vu de la précision de l’algorithme : la nécessité d’avoir une plateforme matérielle répliquant une centrifugeuse de Natanz pour mettre au point l’attaque,
• le fait que Stuxnet exploite des failles de design, notamment la possibilité d’écrire dans la mémoire de recopie de l’état des capteurs, qui devrait être en lecture seule. C’est donc une faille impossible à combler immédiatement par Siemens, car un certain nombre d’applications (qui utilisent cette possibilité) ne fonctionneraient plus,
• l’absurdité du fait que le DHS, et l’équipe CERT ICS, aient décidé de ne pas considérer comme des vulnérabilités les problèmes de design des automates et SCADAs (sous la pression des constructeurs, selon l’équipe Bootcamp), puisque les « serious guys » – comme dit Ralph Langer – conçoivent leurs attaques en tirant profit de ces failles de design,
• la croyance d’être en sécurité car l’installation est déconnectée d’internet, ou parce que le réseau de production n’est pas connecté au réseau de bureautique, est définitivement à abandonner. C’est d’ailleurs l’esprit de toutes les nouvelles normes de cybersécurité industrielle, qui définissent des couches d’interconnexion, mais supposent que tous les niveaux sont interconnectés.

Cette présentation du fonctionnement de Stuxnet conforte donc, dans leurs analyses et leurs conclusions, le travail de l’équipe BootCamp : les failles de design communes à tous les automates industriels sont d’autant plus inquiétantes qu’on ne peut pas les solutionner à court terme.

Dernière présentation intéressante : les systèmes exposés sur internet

Parmi les présentations moins frappantes mais tout de même intéressantes, une analyse d’un chercheur nommé Eireann Leverett a trouvé plus de 10,000 (en fait 10,358) systèmes de contrôle-commande directement connectés à internet, en utilisant l’outil de recherche shodan (il a pour cela utilisé 33 requêtes différentes, avec les mots clés correspondant aux différents constructeurs et produits).

A noter qu’une démonstration de cet outil avait été faire par Lexsi, lors de la conférence du CLUSIR dédiée à la « Cybersécurité industrielle » , que j’avais organisée en novembre 2011.

Chaque point ci-dessus est un système accessible d’internet (SCADA ou automate), et les points en rouge (la majorité donc) comportent des failles de sécurité publiquement connues. Un article détaillant l’ensemble de la démarche est disponible en téléchargement.

Le chercheur indique que parmi les systèmes identifiés se trouvaient le pilotage d’un réseau municipal d’eau irlandais, et la gestion des égouts d’une ville de Californie. Il démontre ainsi qu’il est facile, voire ludique, de détecter et d’attaquer ces systèmes – surtout au regard des autres révélations ci-dessus. Certains exploitants ont reconnu qu’ils ne savaient même pas qu’ils étaient connectés à internet !

L’attaque de ces systèmes est donc à portée d’hacktivistes moyennement expérimentés en hacking, comme les Anonymous, les Akincilar etc…

Quelles conséquences ?

Pour revenir à mon précédent article, on peut dire que c’est vraiment « la fête au village » pour les hackers, y compris les amateurs qui voudraient s’en prendre à des systèmes industriels. A ce propos, ce précédent article rappelait la multiplication en 2011 (x3) du nombre des attaques sur les sites industriels (selon le DHS américain et l’ANSSI français), tendance qui pourrait donc se confirmer en 2012.

Mais surtout, il semble difficile de mieux démontrer la nécessité pour les exploitants de mettre en place un minimum de sécurité, a priori en commençant par une analyse de risques. En effet, une évaluation des risques, même très basique, permet de quantifier et d’évaluer le niveau de vulnérabilité d’une installation, les impacts potentiels, et d’avoir une première idée des mesures nécessaires : à partir de là il devient possible de prendre des décisions et éventuellement d’affecter des moyens pour réduire le risque s’il est inacceptable.

Les fabricants et éditeurs de systèmes industriels (automates, SCADAs…) doivent reconnaître que leurs produits constituent des vecteurs d’attaques informatiques faciles à exploiter, et prendre leurs responsabilités :

• tous les fournisseurs doivent mettre en place des processus pour alerter leurs clients, développer systématiquement des solutions (patchs) pour corriger les failles, et surtout les tester pour vérifier leur efficacité. Cependant les failles de sécurité étant souvent la conséquence de choix en phase design, comme démontré par le projet BootCamp, les patchs sont par nature souvent inefficaces, comme le montrent les statistiques présentées dans la première conférence,
• les éditeurs de logiciels industriels (SCADA mais aussi MES, GPAO etc…) devraient adopter les bonnes pratiques et méthodes de développement logiciel sécurisé, comme les éditeurs de systèmes d’exploitation (dont Microsoft) s’y sont mis depuis bientôt dix ans, tout comme les éditeurs de logiciels internet et web (serveurs, CMS, plateformes de développement Java, .NET etc…). Un prochain article reviendra sur ce sujet et sur l’approche ISAsecure prônée par l’ISA.

Conclusion et actions recommandées

Durant l’année 2012 au moins, on va devoir vivre avec ces systèmes extrêmement fragiles, en attendant que les solutions arrivent et qu’on ait le temps de les qualifier et de les mettre en production.

Le délai nécessaire pour sécuriser ces systèmes sera long, étant donné qu’il s’agit de problèmes de design. Il est même probable que la seule vraie solution soit apportée par de nouvelles versions des produits, entièrement re-designés. Cela a été le cas avec Windows, dont la version XP, qui ne pourra jamais être réellement sécurisée, a pour successeur Windows 7, conçu et développé avec une méthodologie entièrement revue du point de vue de la sécurité (l’obsolescence de XP SP3, c’est à dire l’arrêt de la génération de patchs de sécurité, est annoncée par Microsoft pour le 8 avril 2014 – et juillet 2014 a priori pour MS Server 2003 SP2).

Quelles solutions ?

Eric Byres met l’accent sur le besoin pour les industriels de mettre la pression sur leurs fournisseurs. C’est en effet indispensable pour que ces derniers fassent évoluer leur méthodologie de développement pour inclure la sécurité, mais cela n’apportera une solution qu’à moyen terme et probablement plutôt via une prochaine génération de produits, et non pas via des patchs sur la génération actuelle.

Dans le court terme, faute de pouvoir sécuriser le cœur des installations industrielles (SCADA et automates, truffés de failles impossibles à corriger), toute l’attention doit être portée à la protection périphérique et en profondeur des installations :

• accès physique restreint et contrôlé,
• encadrement légal et contractuel de tous les intervenants,
• formation et sensibilisation du personnel (au vu de l’actualité c’est un besoin croissant, mais aussi relativement « facile » à faire),
• attention aux accès distants, notamment des sous-traitants – en particulier, exclure tout accès distant permanent sans surveillance active,
• solutions techniques : défense en profondeur, segmentation des réseaux, détection d’intrusion, logs de l’activité réseau…,
• procédures et ressources humaines dédiées (il s’agit d’avoir des personnes compétentes qui surveillent les installations et savent réagir aux alertes).

Dans tous les cas, avant de lancer des actions tous azimuts ou pour régler tel ou tel problème identifié, il est indispensable d’avoir une vraie démarche d’analyse de risques (même sous une forme rapide, en quelques jours), pour avoir une vision complète de la situation et pouvoir traiter en priorité les vulnérabilités les plus critiques.

A l’évidence peu d’industriels pourront se payer le « luxe » d’un bon niveau de cybersécurité avec toutes les mesures ci-dessus, notamment du fait de l’expertise « maison » nécessaire.

Pour les autres, il reste possible de mettre en place un minimum de précautions, souvent de bon sens : avec le bon niveau d’information et un peu d’attention du management, des progrès importants peuvent être accomplis rapidement.

Il faudra ensuite maintenir les efforts (importants ou plus limités suivant le cas) dans le temps, pour pouvoir ajuster les mesures à l’évolution des menaces et vulnérabilités, car, comme on l’a vu depuis début 2011, on n’est jamais au bout des surprises !

Tags: Attaques, Automates, DHS, Failles, SCADA, Siemens, Stuxnet