Après un mois d’août calme sur le front des annonces de sécurité relatives au SCADA, les alertes ont repris de plus belle cette semaine, et concernent des fournisseurs variés, dont certains jusque-là épargnés.

Dans cet article : résumé des épisodes précédents, explications sur ce nouveau lot de failles, et conclusions à en tirer…

Résumé des épisodes précédents

Dans le monde de la cybersécurité industrielle, on peut parler d’un avant et d’un après Stuxnet. En effet, avant l’automne 2010, le nombre des failles SCADA connues et publiées pouvaient se compter sur les doigts de… deux mains.

Depuis, des chercheurs, et heureusement aussi les fournisseurs, ont pris conscience de l’importance de détecter et traiter les vulnérabilités des systèmes industriels, pour les rendre un peu moins facile à attaquer.

Etape 1

C’est d’Italie que vient, ce printemps 2011, le premier coup de semonce : Luigi Auriemma envoie à une liste de distribution spécialisée un message où il détaille pas moins de 34 failles sur les SCADA de marque Siemens Tecnomatix, Iconics GENESIS, 7-Technologies IGSS, et DATAC RealWin. La plupart des failles sont basiques, type « buffer overflow » (copie par le logiciel de données d’entrée dans une variable, sans vérifier que la variable a la taille suffisante), ou de type « déni de service » (possibilité de faire « planter » l’application). De plus, dans la mesure où pour chacun des produits il a trouvé un minimum de six (!) failles, on peut en conclure que sa liste est  limitée par le temps qu’il a consacré à sa recherche, et que, quelque soit le produit SCADA, il trouverait sans doute plusieurs failles.

Son message initial, avec un lien vers chacune des failles trouvées, est ici : http://seclists.org/bugtraq/2011/Mar/187. Une analyse en français est disponible ici : http://www.lemagit.fr/…/scada-des-dizaines-failles-consolidees/. Cet article indique par ailleurs que, peu après cette publication, un premier kit d’exploitation payant de l’ensemble des failles SCADA a été mis sur le marché – permettant aux pirates de réellement tester des installations (pour les « gentils »)  ou de les attaquer (pour les « méchants »). C’est l’impact, gênant, de la publication immédiate de failles trouvées : rendre publiques les failles bénéficie à leur découvreur qui y gagne en visibilité (et il faut le reconnaître, aux professionnels de la sécurité qui ont ainsi des arguments à faire valoir), mais pose un problème dans le domaine des SCADA où la mise à disposition et l’application de correctifs n’est pas encore une pratique très courante. En général, en procédant à une publicité immédiate des failles, on augmente donc le risque couru par les installations.

D’ailleurs, dans les semaines qui suivent, les kits de hacking « publics » et gratuits (metasploit, exploit-db) reçoivent également des contributions correspondantes à ces différentes failles, qui sont donc à présent à disposition de tout un chacun.

Etape 2

Durant l’été, en Juin et Juillet, on assiste à des annonces successives de vulnérabilités par différents contributeurs (peut-être que Luigi leur en a donné l’idée !). La newsletter d’Eric Byres (voir son blog dans la liste des liens) fait ainsi état à fin Juin puis début Juillet d’une douzaine de failles trouvées sur les produits Ecava Integraxor, 7-technologies IGSS, Samsung Data management, Siemens Simatic S7, Rockwell Rslinx Classic, Progea Movicon, Sunway Forcecontrol, Indusoft ISSymbol, Azeotech DAQfactory, Rockwell FactoryTalk, et Siemens SIMATIC WINCC.

A noter que la presse (anglo-saxonne) se fait l’écho d’une seule d’entre elles, celle de Sunway, en titrant « US reveals Stuxnet-style vulnerabilities in Chinese SCADA » (Juin 2011), ce qui dénote un traitement partiel et orienté de l’information, et surtout masque l’ampleur du phénomène en sous-entendant que les logiciels chinois seraient les seuls vulnérables.

D’autre part, Siemens (Stuxnet visait leurs SCADA et automates), qui faisait figure de bon élève en jouant le jeu de la communication, reçoit plusieurs coups de boutoirs sous la forme de dénonciation de nouvelles (et nombreuses) failles, ainsi que lors d’une démo au forum « black hat » d’Août 2011, qui montre la simplicité des attaques sur une gamme d’automates de la marque. Sur ce sujet je vous invite à relire mon précédent article.

La société Gleg met à jour son pack « d’exploits » pour inclure de quoi exploiter ces nouvelles failles ainsi que d’autres, dont certaines 0-day (dont ils ont la primeur apparemment) : Broadwin\Advantech, Labview, Progea Movicon 11, Carel PlantVisor Pro – voir le détail sur le site SCADAhacker.

Etape 3 : en août c’est les vacances !

Vu l’emballement des annonces, je m’attendais à un mois d’août chaud. Or le climat du côté des alertes SCADA était aussi frais… qu’à Paris (les averses en moins). Tant mieux aussi pour nous tous qui avions envie de vacances.

La première averse de l’automne est drue !

La trêve estivale a pris fin le 13 septembre, avec une nouvelle publication d’une longue liste de failles par… Luigi Auriemma ! Il s’est intéressé à d’autres produits, et… a trouvé de nombreuses autres failles : Beckhoff TwinCAT, Measuresoft ScadaPro, Rockwell RSLogix, Carel PlantVisor, Progea Movicon / PowerHMI, DAQFactory, Cogent DataHub, eSignal, MetaStock, avec deux nouvelles annonces ce vendredi 16 concernant ISI rFactor et Race WTCC. On peut parier que ce n’est pas terminé. Comme précédemment, il a trouvé plusieurs failles pour chaque produit. Le détail des failles avec les numéros de version des produits est consultable sur son site http://aluigi.altervista.org/.

Cela cause une pluie d’alertes au niveau du CERT-ICS, puisqu’ils émettent une alerte par faille… On peut questionner leur valeur ajoutée puisque le niveau de détail fourni par les CERT ICS est inférieur à celui fourni à l’origine par Luigi, mais les informations sont en couleur et bien présentées dans un PDF… J’en ai parcouru plusieurs pour vous éviter de le faire : si vous êtes concerné, allez plutôt lire les infos postées par l’auteur. Je dois reconnaitre cependant que j’ai été initialement alerté grâce au CERT-ICS.

Conclusion

Il semble y avoir confirmation de ce que l’on soupçonnait, à savoir que les systèmes SCADA, qui n’ont pas forcément, dans le passé, bénéficié des meilleures pratiques en terme de développement sécurisé, sont bourrés de failles.

Si le système que vous utilisez n’est pas encore dans la liste n’en tirez pas trop vite de conclusion. Ainsi j’ai moi-même indiqué à un fournisseur qui ne figure pas dans cette liste une vulnérabilité de type « DOS » trouvée dans le cadre d’un test d’intrusion. Comme sans doute d’autres acteurs, j’ai joué le jeu normal consistant à signaler la faille au seul éditeur.

Combien de failles ont ainsi déjà été signalées aux éditeurs et sont en cours de traitement (du moins, on l’espère), sans qu’elles n’aient encore été rendues publiques ?

Mais surtout, combien de failles ont été trouvées par des « black hat hackers », c’est à dire des pirates qui ne cherchent pas à faire progresser la sécurité, mais à exploiter les failles ainsi trouvées pour leur compte, ou en les vendant pour intégration dans de futurs Stuxnet ?

La conclusion qu’on peut certainement tirer dès à présent, est qu’il devient difficile d’ignorer des signaux d’alerte de plus en plus clairs ; un minimum d’énergie et de temps devrait être consacré par les responsables d’infrastructures critiques à la cybersécurité, pour la simple raison qu’en cas d’incident, on pourrait à présent légitimement leur reprocher de ne rien avoir fait malgré les alertes multiples !

Tags: CERT, Failles, SCADA, Siemens