Pourquoi il faut arrêter de diffuser les failles génériques

Les annonces concernant des vulnérabilités très larges se multiplient, contribuant à embrouiller encore plus la situation des SI industriel et orientant vers des solutions non pertinentes. Faux problème, vraie confusion : pourquoi faut-il arrêter avec ces « fake vulns » ?

En 2011, suite à la publicité faite à l’attaque Stuxnet, les chercheurs en sécurité ont commencé à s’intéresser au milieu industriel et on fait les premières découvertes massives de vulnérabilités (Luigi Auriemma, Ruben Santamarta, etc.). Cela a permis à plusieurs d’entre eux de se faire un nom, quelquefois de manière pertinente comme ceux précédemment cités, mais souvent de manière discutable pour une majorité. Pourquoi ? Car mettre en avant des vulnérabilités évidentes et difficiles à corriger amène de la confusion aux acteurs du secteur, souvent peu matures sur ces sujets.

Ainsi récemment, des chercheurs ont fait enregistrer une vulnérabilité générique et évidente, indiquant que faire du fuzzing sur des automates (avec une large liste de constructeurs) risquait de charger le CPU et de leur faire manquer un cycle, voire de les planter. La belle affaire ! C’est une connaissance de base de tout acteur sérieux en cybersécurité industrielle… Le standard NIST 800-82 indiquait dès la première édition de 2011 qu’il fallait éviter de scanner des réseaux industriels car cela pouvait causer des défauts, et donc évidemment le fuzzing [1] à plus forte raison… On enfonce des portes ouvertes !

Quand les chercheurs enfoncent des portes ouvertes

En effet, de nombreuses vulnérabilités « évidentes » sur les SI industriels (automates, passerelles, logiciels…), résultent logiquement de l’absence de spécification de sécurité. Si l’on n’exige pas de changer le mot de passe par défaut dans la configuration d’un logiciel, l’intégrateur n’a aucune raison d’embêter ses utilisateurs (et le constructeur ne mettra éventuellement pas de mécanisme de mot de passe du tout !). Si l’on n’exige pas de mécanisme anti-brute force, comme un délai croissant entre les tentatives de connexions, il n’y a aucune raison de mettre en place ces mécanismes qui peuvent poser problème en cas de besoin d’une maintenance réactive car les mainteneurs internes ou l’exploitant n’ont en général pas encore de système mutualisé de gestion de mots de passe.

Sur de nombreuses applications, le risque lié à l’utilisation d’équipements non sécurisés est d’ailleurs tout à fait acceptable. Il n’est en effet pas pertinent de mettre des équipements certifiés de cybersécurité partout. Pour les besoins de sécurité plus importants, des références certifiées commencent par ailleurs à être disponibles, mais leur nombre reste encore assez limité.

Pourquoi ça pose problème

On voit aujourd’hui des vulnérabilités acceptées par MITRE ou le CERT ICS sur des cas qui n’apportent rien sauf de la confusion. En SI industriel, corriger toutes les vulnérabilités est impossible et irréaliste parce qu’elles sont trop nombreuses, pas encore découvertes, ou ne pourront jamais être corrigées (matériel est trop vieux ou souci de conception qui ne peut être modifié avec un logiciel). Les mettre en avant embrouille, puisque le vrai problème n’est pas de trouver comment corriger ces failles, mais comment empêcher qu’elles ne soient exposées et exploitables par des attaquants.

Deux exemples de « fake vulns » :

• Vulnérabilité multiples sur Modbus : elles sont factuellement exactes, mais en quoi lister ces vulnérabilités évidentes aide-t-il ? Pourquoi s’intéresser uniquement à Modbus ? Si ce protocole reste l’un des plus courants même sur les installations neuves car il est efficace et a un nombre record d’équipements compatibles, tous les protocoles industriels sont dans le même cas, même si leur exploitation est quelquefois plus complexe. Mais surtout, quelles solutions apporter ? Pointer du doigt Modbus sans recours est inutile, sauf à suggérer qu’il faille s’en passer… Certes, utiliser OPC-UA serait préférable, mais peu d’équipements le supportent (souvent via des options payantes), et il est plus complexe à mettre en œuvre, avec certificats etc.

• Vulnérabilités Triconnex et attaques Triton : des tentatives d’attaques exploitant cette vulnérabilité ont effectivement eu lieu (en Arabie Saoudite, selon cette analyse). Ces équipements sont chers et complexes à programmer, expliquant que peu de chercheurs aient publié sur le sujet. Rappelons que tous les automates de sécurité ont été conçus sans exigence de cybersécurité ! S’il venait à l’esprit d’attaquer une autre cible, il n’y aurait pas de difficulté à trouver une faille à exploiter. Je prends le pari que n’importe quel SIS (Pilz, HIMA…) a des failles que l’on peut trouver si on le veut vraiment. Rappelons également que l’attaque sur Triton n’est possible que si un commutateur physique sur la face avant de l’automate est en position « Program ». Elle est donc impossible en position « Run ». Encore une fois, la solution n’est pas de se passer de ces modèles ou de patcher, mais d’avoir des bonnes pratiques de contrôles d’accès logique et physique..

Corriger une vulnérabilité est rarement la solution

En 2011, on pouvait comprendre que des chercheurs en sécurité qui découvraient le monde des SI industriels s’étonnent des vulnérabilités et les publient. En 2019, voir qu’il y a encore autant de portes ouvertes enfoncées est navrant. Oui, les équipements industriels sont majoritairement non sécurisés, comme cela a été à plusieurs reprises montré par exemple par les projets « Basecamp », en 2011 sur les automates, en 2015 sur les passerelles, mais non, la focalisation sur la chasse et la correction des vulnérabilités n’est (toujours pas) la solution.

Aujourd’hui, il faut considérer qu’un équipement industriel est par défaut vulnérable à la plupart des attaques standards (fuzzing, DoS, MitM, brute-force, etc.), ceci jusqu’à preuve du contraire (les rares équipements certifiés). L’approche « détectons et corrigeons les vulnérabilités » est à oublier, car elle ne fonctionne tout simplement pas ! Mieux vaut utiliser des approches mises en œuvre par des acteurs sérieux depuis des années et qui fonctionnent, par exemple par segmentation, détection ou barrières de défense multiples.

Quant à la recherche de vulnérabilités, elle est pertinente à condition de s’intéresser aux vulnérabilités d’architecture, de connexions distantes, d’organisation, de non-maîtrise de l’installation (inventaire, cartographie), qui sont les vrais leviers de sécurisation en SI industriel.

[1] « le fuzzing » consiste à utiliser un outil (par exemple un script python utilisant la librairie scapy) pour générer des trames réseau aléatoires et les envoyer en volume à une cible, après connexion TCP ou à un port UDP ouvert.