Scada : un niveau de sécurité qui serait risible s'il n'était préoccupant

"L'état de la sécurité des Scada est vraiment risible", estime le chercheur Terry McCorkle. "Je ne sais pas quoi dire d'autre à ce sujet." McCorkle a présenté le fruit de ses recherches à l'occasion du récent Kaspersky Security Analyst Summit 2012. Des recherches qu'il a menées avec son collègue chercheur Billy Rios, au cours des neuf derniers mois.

Tous deux se sont penchés sur la sécurité, la disponibilité, et l'accessibilité sur Internet des interfaces homme-machine qui traduisent les données des systèmes Scada en représentations visuelles de systèmes industriels. Les opérateurs utilisent ces interfaces pour consulter les schémas fonctionnels des systèmes industriels et pour les contrôler : activer des commutateurs ou des pompes, relever ou réduire des températures, etc. Ces interfaces homme-machine (IHM) sont généralement déployées sur des machines Windows et communiquent avec des contrôleurs à logique programmable (PLC) ainsi que les autres contrôleurs font fonctionner les systèmes industriels.

McCorkle a expliqué que lui et Rios se sont lancés dans leur projet de recherche avec l'objectif de trouver 100 bugs en 100 jours. Ils partaient du postulat selon lequel la sécurité avait évolué au point où 100 bugs en 100 jours serait un objectif raisonnable. Mais 9 mois après le lancement du projet, les chercheurs ont trouvé plus de 1000 bogues, dont 95 étaient facilement exploitables. Tous ont été signalés aux fournisseurs concernés via l'ICS-CERT.

"100 bugs, on peut penser que c'est beaucoup. C'est ce que nous pensions, en tout cas, parce que le développement et la sécurité ont évolué", indique McCorkle. "Nous avons pensé que des experts des Scada avaient suivi le mouvement. La réalité est qu'ils sont restés coincés dans les années 90. Les cycles de développement sécurisé n'existent pas et ce n'est pas la seule chose qui manque !"

McCorkle et Rios ont découvert un grand nombre d'erreurs susceptibles de déboucher sur des dépassements de mémoire tampon, des trous dans les bases de données SQL, des vulnérabilités Web telles que le stripping inter-sites (XSS) et des vulnérabilités ActiveX. McCorkle a indiqué avoir été en mesure, dans un cas, d'ouvrir un shell de commande à travers un contrôle ActiveX. Toute personne ayant accès à ce shell est en mesure d'exécuter à distance des commandes, s'est-il alarmé.

Le problème, selon lui, est que les exploitants de Scada pensent que, parce que leurs systèmes sont isolés d'Internet, ils sont inaccessibles. Mais cela ne s'applique pas à leurs IHM : elles ne sont pas seulement dotées d'un accès facile sur Internet, mais la sécurité est souvent désactivée par défaut sur les systèmes qui les hébergent, bien qu'ils soient accessibles via des outils d'administration à distance tels que VNC. Plus grave, les manuels d'utilisation recommandent de ne pas lancer d'analyse de vulnérabilité et autre contrôle de sécurité sur ces systèmes…

Et pour compliquer encore un peu plus la situation, la gestion des systèmes industriels informatisés est souvent déléguée à des tiers sans préoccupation relative à la sécurité. Les ingénieurs locaux ne veulent pas corriger les éventuelles vulnérabilités de peur que le correctif brise un processus. Et les informaticiens doivent en priorité répondre à des exigences de disponibilité. Pour McCorkle, tout cela concourt à maintenir la sécurité des systèmes de contrôle industriel à un niveau risible.

"La responsabilité doit être remontée au fournisseur. Et celui-ci doit  fournir un moyen automatisé de déploiement de correctifs," dit-il. "Microsoft n'a pas toujours eu de systèmes de notification et de gestion automatisée des ressources. S'il les a créés, c'est parce que les clients l'ont demandé. Les tiers qui exploitent ces systèmes ne s'intéressent pas à leurs clients. Lorsque des correctifs sont disponibles, c'est pour le moment au client d'assumer la responsabilité de leur déploiement. Il faut créer des mécanismes pour automatiser cela. "