Le 14 février 2012 (11:52) - par Searchsecurity.com
L'état préoccupant de la sécurité des systèmes informatisés de contrôle
industriel (Scada) est probablement le secret le plus mal gardé dans
les cercles des experts de la sécurité informatique. Ces systèmes qui
permettent de surveiller, gérer et administrer tous les systèmes
industriels, des centrales nucléaires aux systèmes de climatisation en
passant par la robotique ou même les portes des cellules de prison,
cachent mal leurs vulnérabilités, selon les experts.
"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. "
http://www.lemagit.fr/article/scada/10461/1/scada-niveau-securite-qui-serait-risible-etait-preoccupant/?utm_source=essentielIT&utm_medium=email&utm_content=new&utm_campaign=20120215&xtor=ES-6
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. "
http://www.lemagit.fr/article/scada/10461/1/scada-niveau-securite-qui-serait-risible-etait-preoccupant/?utm_source=essentielIT&utm_medium=email&utm_content=new&utm_campaign=20120215&xtor=ES-6
Aucun commentaire:
Enregistrer un commentaire