SCADA : attention, ça commence à devenir chaud
Il y a quelques temps, l'ami @fo0_ éveillait notre attention sur un hack un peu particulier d'un système SCADA survenu aux USA, à Springfield, Illinois. Des intrus se seraient introduits sur le système supervisant l'approvisionnement en eau de la ville. Compromettant d'abord le système d'information du constructeur, ils seraient ensuite parvenus à détruire une pompe a eau en jouant avec le système de monitoring, l'allumant et l'éteignant.
En faisant quelques recherches comme nous en avons l'habitude chez Reflets, nous sommes tombés sur des pages assez intéressantes. Nous avons par exemple mis la main sur un le fichier de configuration de la base de données d'un PLC (Programmable logic controller) :
<Config conVer="0.15.1" serial="460847047" model="PLC800-U-1-2M00-12-0" password="c1o9o3p17" modNet1="7" modNet2="836" modVer1="2.01" modVer2="" ntp="" offUTC="01:00:00" dayLightSaving="True" synchroNodes="True" language="es" gsmBand="0" decimalSeparator="." dayReadBill="1" profileDepth="30" timeBetwRetries="5">
Cette ligne nous renseigne sur le modèle, un concentrateur destiné à contrôler et mesurer l'énergie, puis à communiquer les données collectées, son numéro de série, et ... son mot de passe, en clair. Le système transmet des données sur un serveur FTP, placé sur le LAN du SCADA :
<Lan DHCP="False" ip="192.168.3.203" netmask="255.255.255.0" gateway="192.168.3.100" primaryDNS="" secondaryDNS="" /> <Ftp ftpEnabled="True" compEnabled="False" host="**.**.**.***" port="2121" user="concentradores" pass="1931" path="ct danses" />
Le FTP est doté d'un mot de passe de 4 chiffres... Juste en dessous, on voit que le système est connecté au réseau GPRS de Vodaphone Espagne, ce qui nous renseigne du coup un peu plus sur l'origine et la localisation de l'équipement :
<Gprs gprsEnabled="False" apn="ac.vodafone.es" user="vodafone" pass="vodafone" gprsConnection="False" dynDnsDomain="" dynDnsUsername="" dynDnsPassword="" />
Avec ces informations disponibles librement sur Pastebin, on obtient une base faillible pouvant être une porte d'entrée pour compromettre un système. C'est assez moyennement rassurant car on observe ici un veritable enchainement de mauvaises pratiques devenu dramatiquement commun chez les éditeurs de ces solutions. Les communautés de la sécurité informatique s'intéressant de plus en plus aux SCADA et ces derniers étant de plus en plus présents, connectés à Internet, c'est vraiment le moment de commencer à s'inquiéter.
L'épisode Stuxnet n'aura pas manqué d'éveiller l'attention de nombreuses autorités dans le monde. Les USA, plutôt bien placés pour prendre la mesure des vulnérabilités de ces systèmes qui n'ont pas à l'origine été créés pour être connectés à Internet, ont par le biais du département d'état à l'énergie publié un petit guide de bonnes pratiques sécuritaires des SCADA. C'est bien sympa ces petits guides, mais ça ne suffit pas.
En France, en dehors de certains travaux d'acteurs privés comme EADS, la prévention et l'accompagnement des industries qui manipulent des SCADA sur des systèmes sensibles demeure quasi inexistant. Ces industries doivent s'en remettre aux seules affirmations des éditeurs de solutions. Nous vous en parlons maintenant depuis plusieurs années. Nous sommes nous mêmes tombés sur d'importantes vulnérabilités sur des SCADA et nous nous sommes par exemple retrouvés aux commandes du contrôle en énergie d'une université entière en Asie, nous avons pu constater à maintes reprises les mauvaises pratiques de certains éditeurs de ce type de solutions et aujourd'hui, vu le nombre de codes d'exploitation disponibles, vu la lenteur de certains éditeurs à patcher les vulnérabilité et la lenteur inhérente à certaines industries pour tout ce qui touche aux systèmes informatisés, sans vouloir paraitre trop alarmistes, il nous semble de plus en plus évident qu'un jour ou l'autre, dans un futur surement très proche, un incident majeur se produira.