Le précédent article consacré à shellshock introduisait le sujet et en donnait l’essentiel à savoir..

Ce second article examine les impacts sur les SI industriels en posant la question de la présence de la faille shellshock pour chaque type d’équipement. Cela revient à voir si les systèmes en question sont basés sur linux (ou un unix), et si bash, et des moyens d’activer la faille, pourraient s’y trouver.

Shellshock et les réseaux industriels

Les systèmes industriels étant de plus en plus souvent numériques, et plus précisément, de plus en plus informatiques, ils fonctionnent souvent avec un operating system (OS) standard : soit temps-réel (type VxWorks, pSos…) pour les systèmes temps-réels (API), soit linux, pour les même raisons de flexibilité et de coût (et de fiabilité en général) que les appliances mentionnées dans l’article précédent.

Automates programmables : y-a-t’il des shells bash sur les OS temps réels, type VxWorks, QNX, pSos ?

Les API sont généralement basés sur des OS temps réel, pour assurer le déterminisme des boucles de contrôle. La question de savoir s’ils sont vulnérables à shellshock revient donc à se demander si ces OS disposent du shell bash.

A priori non pour VxWorks, sur QNX les gens ont vraiment du mal à y porter Bash en tous cas ce n’est pas installé par défaut, et apparemment pSos n’est plus assez à la mode pour que la question se pose ?

Donc, la plupart des automates programmables (y compris les interfaces Ethernet qui se présentent sous forme de modules séparés) et des systèmes critiques seraient à l’abri. Pour l’instant les constructeurs ne communiquent pas : aucun résultat à la recherche « shellshock » sur les pages sécurité des sites de Schneider Electric, Siemens (en fait si: quelqu’un a posé la question dans le cas de Siemens), A-B Rockwell…

A noter cependant qu’il existe des automates (qu’on pourrait qualifier d’entrée de gamme) fonctionnant sur linux : chez Wago par exemple (série 758), mais il n’y a pas plus d’information sur shellshock pour autant. Enfin la version « temps réel » de linux (linux-RT) ne semble pas encore déployée industriellement.

Et dans les autres équipements ?

Les SI industriels ne sont pas constitués seulement de SCADA et d’automates, ce qu’on pourrait finir par croire à force de lire les articles de vulgarisation. De très nombreux autres objets connectés sont présents : passerelles (entre protocoles), capteurs intelligents munis de serveurs web et autres (ftp,telnet…), imprimantes, terminaux et interfaces homme-machine (IHM dédiées, Panel PC…), bornes de réseaux sans fils, ainsi que… de très nombreux développements « maison » pour des applications de suivi de production qui ces dernières années ont évolué vers du .NET, java ou html5 – permettant avec des ateliers complets le développements d’applications fonctionnant sur tout client léger (browser web sur PC, tablette…), et servies le plus souvent par l’ensemble LAMP (Linux, Apache, MySQL, PHP).

Les IHM (interface homme-machine)

La plupart des solutions d’IHM, qu’elles soient purement logicielles (à installer sur un PC), ou intégrées (Panel PC etc…) sont conçues pour Windows, du fait de l’intégration avec les SCADA des constructeurs (Siemens SIMATIC, Schneider MAGELIS…). Donc pour une fois, Windows nous épargne un soucis.

Il existe des initiatives intéressantes d’IHM sous linux, par exemple celle d’Openwide : il n’y a pas de communication particulière sur le sujet, ce serait donc à évaluer.

Les RTU (remote terminal unit)

Très employés dans les installations étendues, moins contraintes par les aspects temps réels (pas de notion de « boucle »), les unités distantes (y-a-t’il une traduction officielle de RTU ?) modernes disposent d’un OS permettant de communiquer avec différents protocoles sur Ethernet (voire directement OPC), et naturellement linux, gratuit, fiable… est la solution idéale, même si de nombreux équipements sont encore basés sur des processeurs embarqués avec du code spécifique.

Même quand linux est utilisé, les systèmes sont relativement légers (et peu pourvus en RAM) et par conséquent n’embarquent que peu de services, en particulier, pas de serveurs web ou autres interfaces permettant l’exploitation de la faille shellshock.

On pourra consulter ces exemples Moxa ou Versatrak.

A noter un cas particulier de ce type d’équipement : les « smart meters », ou « compteurs intelligents », en cours de déploiement chez les clients des fournisseurs d’électricité aux USA et en Europe (Linky en France chez ErDF). Ces équipements restent assez simples (a priori pas d’OS linux embarqué), ce qui est tant mieux dans la mesure où malgré cela certains équipements présentent des failles au niveau de leur code embarqué (firmware) permettant d’en prendre le contrôle, comme récemment révélé en Espagne. Si cela peut être intéressant pour les clients, afin de payer moins cher en modifiant le comptage (comme avéré dans plusieurs cas aux USA), le risque principal est lié à la possibilité d’une cyber-attaque par envoi de commandes de « déconnexion » du réseau à un vaste ensemble de compteurs, provoquant une brusque chute de consommation qui pourrait dépasser les capacités d’absorption du réseau. Pour cette raison, plusieurs analystes militent contre les smart meters, car le risque dépasserait largement le bénéfice attendu (3% d’économie d’électricité en Europe en 2020).

Les passerelles

Les passerelles sont conçues comme des équipements simples à configurer et à utiliser, et par définition supportent plusieurs protocoles, et donc sont pourvues de port(s) Ethernet. Plus encore que sur les RTU, linux est ici la solution idéale pour ces équipements, qui contrairement aux RTU, disposent le plus souvent d’une interface web, servant soit uniquement à la consultation, soit à la configuration.

Ces équipements sont donc a priori vulnérables. Ce point est important car lorsque l’on cherche à segmenter un réseau industriel dans un objectif de cybersécurité, on se pose souvent la question de savoir si les passerelles peuvent faire office de barrière entre deux zones d’une installation, puisque les commandes et informations transmises sont limitées aux protocoles industriels. Par exemple, les commandes spécifiques d’un constructeur ne seront pas traduites par la passerelle qui implémente les protocoles « standards ».

Dans le cas présent, les passerelles peuvent être considérées comme des équipements susceptibles d’être corrompues et pouvant servir de relais à des attaques : de potentiel allié de la sécurité, l’équipement devient un allié de l’attaquant.

Parmi les constructeurs possiblement concernés on peut citer les passerelles avancées des fournisseurs Digi One, Schneider, Lantronix.

Inversement, d’autres passerelles, plus compactes et souvent moins flexibles, ne se configurent que via des protocoles spécifiques (Hilscher), via port série (Equustek), ou carte SD/USB (ConnectPro).

A noter que le projet SHINE, qui vise à cataloguer les systèmes industriels directement connectés à internet, a identifié plus de 200,000 passerelles accessibles sur le net : le sujet est donc particulièrement d’actualité. Le projet est arrêté car « ils n’en voyaient pas le bout », sinon il serait intéressant de vérifier pour ces « cibles » identifiés si le port 80 est également accessible… et si la faille shellshock est présente.

Si des passerelles sont connectées à des équipements critiques, cela mérite donc examen, et on en profitera pour vérifier a minima que personne n’a eu l’idée de prévoir un accès internet non sécurisé pour y accéder à distance….

Les capteurs intelligents

Le principe des capteurs « intelligents » est d’embarquer un système permettant plusieurs choses :

• auto-calibration, auto-adaptation (gain…) ;
• fourniture directe de mesures en grandeurs physiques (température) au lieu de données nécessitant un traitement (formule) sur un automate, voire l’élaboration de tendances et du traitement du signal embarqué (vibrations, seuils…) ;
• diagnostique sur le fonctionnement, alarmes ;
• protocoles avancés et multiples (y compris OPC).

Tout ceci nécessite donc une capacité de calcul embarquée. Ce type de capteurs existe depuis plus de 20 ans, cependant l’offre est encore essentiellement basée sur des équipements assez basiques communiquant avec des bus terrains (typiquement HART), filaires ou sans fil. Dans certains domaines de pointe, où les capteurs peuvent être particulièrement onéreux (flux neutroniques, analyseurs de gaz…), des produits évolués avec des OS embarqués commencent à apparaitre, mais cela reste anecdotique à ma connaissance : on pourra s’en préoccuper le cas échant mais il n’y a pas lieu de s’en inquiéter dans les installations standard.

Les équipements de sécurité

Les pare-feux industriels (Tofino Eagle, Innominate mGuard par exemple) sont-ils touchés ou pas ? Difficile de le savoir faute de communication publique sur leurs sites (à cette date). Les informations techniques ne précisent pas l’OS embarqué (linux ou autre), et si Tofino avait rapidement communiqué sur le fait que leurs produits n’étaient pas concernés par hearbleed, il n’y a pas pour l’instant de communication équivalente concernant Shellshock…

La démarche du CERT-ICS américain pour inviter les constructeurs à communiquer

Comme vu ci-dessus, on manque d’information. Contrairement à heartbleed, les informations sur shellshock restent limitées, avec cependant les constructeurs issus du monde IT (Cisco, Juniper etc…) un peu plus réactifs, car plus rodés à l’exercice ?

Le CERT ICS américain, principale source d’information sur les failles des systèmes industriels, semble avoir fait le même constat. En effet, ils ont d’abord publié un « advisory » initial sur shellshock, où la note maximale CVSS de 10 était attribuée à shellshock. Ils viennent de publier un autre document, où ils font état de leur demande à tous les principaux constructeurs de faire l’état des lieux des systèmes concernés chez eux par shellshock, et de leur communiquer cette liste. On dispose ainsi, par constructeur, de listes de produits impactés selon eux.

Vous retrouverez dans cette liste certains des « candidats » que nous avons identifiés plus haut dans l’article (Digi, Moxa…) et d’autres. La liste semble relativement réduite… mais la raison en est surtout que par rapport à la longue liste de constructeurs contactés (donnée en entête), moins d’une dizaine ont confirmé l’existence de la vulnérabilité dans certains de leurs produits. J’ai demandé au CERT ICS leur confirmation que les fournisseurs cités dans la section « remerciements » et absents de la liste des produits avaient répondu – et c’est effectivement le cas.

Selon cet état des lieux, il y aurait donc finalement très peu de produits impactés, et aucun chez Schneider Electric, ABB, Honeywell, Phoenix contact, Tofino, pour ne citer que ceux sur lesquels on peut avoir des soupçons (linux embarqué sur certains produits, serveurs web). c’est donc a priori une bonne nouvelle, mais un peu étonnante.

Ceci dit, on peut supposer raisonnablement que la réponse des fournisseurs porte sur les produits au catalogue, ou au moins encore supportés, et non les anciens produits que l’on peut trouver dans la base installée.

Sur le terrain, ayant sollicité un certain nombre de contacts travaillant sur des projets de sécurisation, il n’y a pas de cas avéré, mais le plus souvent aucun véritable test n’a été fait. Les réponses des fournisseurs conduiront sans doute à légitimer cette inaction.

Le CERT-UK un peu plus alarmiste

Dans la version britannique de l’alerte shellshock, on trouve deux choses intéressantes un peu plus clairement affirmées qu’ailleurs :

• l’alerte sur les systèmes embarqués (section 2) y compris anciens puisque toutes les versions bash sont concernées (depuis 1995), mais sans examen ni catalogue comme l’a fait le CERT US,
• le fait que de nombreux CNI (infrastructure critiques au niveau national, équivalent des OIV – opérateurs d’importance vitale en France – sont concernés), et par conséquent un appel à ces organisations à identifier les systèmes concernés, les patcher si possibles ou prendre d’autres mesures sinon.

Conclusion (rassurante ?)

On voit que cela demanderait un effort considérable d’examiner si oui ou non les différents équipements standards ou développés en internes sont vulnérables à la faille shellshock, effort d’autant plus difficile à justifier que les constructeurs se veulent rassurant. Si l’on veut avancer plus vite, des outils automatiques peuvent aider mais sont délicats à employer en environnement actif. Comme souvent, on se posera la question uniquement pour les environnements réellement critiques, les systèmes de sûreté d’installation sensibles par exemple.

Le remplacement de produit, ou le rajout d’équipement de sécurité, peut alors s’envisager, mais avec des coûts difficiles à justifier puisque cela n’apporte pas de fonctionnalité.

Le plus probable est donc que peu d’actions vont être effectuées, avec un pari sur le caractère apparemment très relatif de la menace – espérons que ce soit le cas.

Tags: Attaques, Automates, Failles, Industriel, Linux