Retour sur la journée INSHack 2019 sur la sécurité IoT
Conférence n°1 : Etat de l’art et méthodologie de l’analyse de la sécurité IoT
présentée par AlgoSecure
L’Internet des Objets (IoT) est un domaine en pleine explosion et on estime à plusieurs milliards le nombre d’objets connectés à internet dans les prochaines années. Malheureusement dans cette course pour le marché de l’IoT, la plupart des entreprises et constructeurs en oublient (sciemment ou non) d’inclure la partie sécurité.
Évidemment cela pose un problème, car beaucoup de ces objets connectés fonctionnent en collectant les données de l’utilisateur, et en l’absence de sécurité, ces données peuvent être récupérées par un attaquant. Mais le problème peut être encore plus grave lorsque ces objets ont un impact physique comme par exemple dans le cas d’un pacemaker.
Le domaine de l’IoT manque encore cruellement de maturité et reproduit les mêmes erreurs que lors du développement de l’internet “classique”.
D’un point de vue sécurité et plus globalement, on distingue 3 acteurs appartenant à l’écosystème de l’IoT :
- Les fabricants qui, par nature, ont toutes les informations sur leur produit en main et qui peuvent donc introduire la sécurité pendant la phase de développement.
- Les autorités publiques, qui n’ont pas accès à toutes les informations sur les produits, mais qui peuvent mettre en place des standards à suivre qui incluent la sécurité.
- Et les utilisateurs finaux, qui n’ont accès à aucune information sur le produit.
Afin de tester la sécurité d’un produit IoT, on vient se mettre à la place de l’utilisateur final (sans informations) et on va analyser le fonctionnement du produit et essayer de trouver des vulnérabilités afin de pouvoir dresser un bilan du niveau de sécurité.
C’est ce que l’on appelle le pentest en anglais (test d’intrusion).
Cette phase de pentest est rendue difficile car plusieurs contraintes sont inhérentes à ce domaine : l’hétérogénéité des objets, leur mobilité, la distributivité et la scalabilité.
La principale difficulté vient de l’hétérogénéité des objets. Dans un même réseau IoT plusieurs objets différents peuvent communiquer entre eux en utilisant différents supports et protocoles de communication. Cela demande donc l’utilisation de différents outils d’analyse pour chaque protocole utilisé et cela rend difficile la visualisation des échanges et interactions entre les différents objets.
Leur approche est la suivante : récolter toutes les informations des communications via des sondes et transformer ces informations dans un format générique.
Une fois cette étape effectuée, il faut maintenant pouvoir modéliser et visualiser ces interactions. Cela se déroule sous forme de graphes en 4 étapes.
Le premier graphe représente les communications directes entre des équipements (liaison point à point).
Le deuxième graphe modélise les interactions de bout en bout (end-to-end). Par exemple il permet de visualiser l’interaction entre un capteur et un actionneur en faisant abstraction des différents intermédiaires.
Le troisième graphe utilise les graphes de la phase 2 et permet de les regrouper par “application” tout en déterminant le type d’objet (capteur, actionneur, …)
Le dernier graphe utilise des “motifs” qui permettent de déterminer les interactions précises et flux logiques entre les différents objets.
Cette approche générique permet l’abstraction des protocoles de communication utilisés tout en offrant la possibilité de visualiser les interactions entre objets. Elle est particulièrement efficace dans le cas d’un système IoT complexe faisant interagir différents objets.
Cet outil facilite grandement l’analyse de la sécurité d’un réseau IoT en offrant une visualisation claire des interactions et en regroupant les différents outils d’analyse spécifiques à tel ou tel protocole de communication.
AlgoSecure prévoit de rendre public et open-source cet outil en fin d’année 2019.
Conférence n°2 : Analyse d’une attaque du malware industriel Triton
présenté par Sentryo
Un réseau industriel est un réseau informatique qui permet la communication entre différents équipements industriels au sein d’une usine. Ce type de réseau diffère d’un réseau classique de par ses contraintes liées à son environnement, à son utilisation et aux impacts en cas de défaillance.
Le système global est appelé système de contrôle industriel (ICS) et est composé de plusieurs parties :
- d’automates programmables (PLC) qui lisent des informations depuis des capteurs et effectuent des actions en conséquence,
- de systèmes de contrôle et d’acquisition de données (SCADA) permettant le regroupement et la visualisation des différentes informations pour l’opérateur de contrôle,
- d’une station d’ingénierie permettant la programmation et reprogrammation d’un PLC,
- de systèmes instrumentés de sécurité (SIS), systèmes autonomes qui surveillent le processus physique afin d’assurer la sécurité et la sûreté de fonctionnement.
Ces différents équipements industriels communiquent entre eux grâce à des protocoles de communication qui peuvent être ouverts à tous (ex : modbus) ou alors propriétaire (ex : S7 de Siemens). De plus, la plupart du temps, le réseau sur lequel communiquent ces équipements est relié via une passerelle au réseau classique de l’entreprise.
Maintenant que nous savons un peu mieux ce qu’est un système industriel, nous pouvons passer à l’analyse du malware Triton.
Le malware Triton est un malware qui vise un modèle particulier de SIS, le Triconex MP30008 commercialisé par Schneider Electric. L’usine ciblée est une usine de pétrochimie localisée en Arabie Saoudite.
L’attaque s’est déroulée en 3 étapes. La première est une intrusion dans le réseau classique de l’usine pour, dans un deuxième temps, compromettre la station d’ingénierie permettant la reprogrammation des automates. La dernière étape est la reprogrammation du SIS ciblé afin d’y injecter une backdoor, ce qui permettra aux attaquants de lancer des commandes à distance.
La partie intéressante de cette attaque se trouve entre la station d’ingénierie et le SIS. En effet, afin de communiquer entre eux ils utilisent un protocole appelé Tristation.
La malware exécuté sur la station d’ingénierie, qui a pour but de reprogrammer le SIS, s’appelle trilog.exe. Ce nom a été choisi afin d’échapper au filtrage des processus sur leur nom. Une fois exécuté, il scanne le réseau dans le but de trouver un SIS vulnérable, s’y connecte, vérifie qu’il peut lire et écrire dans la mémoire, récupère la table des programmes présents dans l’automate. Puis, il injecte le programme malveillant permettant l’exécution de commandes à distance.
Le protocole utilisé pour la communication entre la station d’ingénierie et le SIS s’appelle Tristation et, est un protocole propriétaire, ce qui en rend l’utilisation très difficile pour toute personne n’ayant pas accès aux spécifications.
Comment les attaquants ont-ils pu utiliser le protocole Tristation ?
- Soit ils se sont basés sur des papiers existants qui ont déjà analysé ce protocole.
- Soit ils ont eu accès à du matériel de développement et ont pu analyser les librairies utilisées pour effectuer la rétro ingénierie du protocole.
Via ce protocole, les attaquants ont ainsi pu injecter une backdoor.
Cette backdoor utilise une vulnérabilité encore inconnue à cette époque (“zero day”) afin de pouvoir s’exécuter en mode superviseur et ainsi être résistante à toute reprogrammation du SIS.
Pour communiquer avec la backdoor, les attaquants se sont servis d’une commande réseau très rarement utilisée qui répondait à leurs ordres seulement lorsqu’un paramètre précis était passé à cette commande.
Les attaquants ont effectué une première tentative d’attaque via cette backdoor, mais ont dû effectuer une erreur dans la commande passée, ce qui a fait buguer le SIS. Le problème a été attribué à une défaillance du SIS et l’attaque n’a donc pas été détectée.
Ils ont par la suite effectué une deuxième tentative mais là encore, l’attaque ne s’est pas déroulée comme prévu et cette fois elle a pu être détectée par les ingénieurs dépêchés sur place.
Plus de peur que de mal donc dans cette attaque qui n’a pas eu de réelles conséquences, mais cela pose un sérieux problème au vu de la criticité des impacts et conséquences potentielles dans le cadre industriel.
Il paraît important de se poser la question de l’efficacité de la sécurité par l’obscurité (protocole propriétaire) au vu de ce genre d’attaque.
Conférence n°3 : Sécurité d’un réseau IoT
présenté par Sogeti
Nous l’avons déjà évoqué dans la conférence n°1, la course au marché de l’IoT engendre des produit développés dans la précipitation et sans ajout de couche de sécurité. C’est encore plus vrai pour les produits grand public d’origine chinoise. Ceux-ci sont connus pour être très peu sécurisés et être vulnérables à des attaques des plus basiques.
Les exemples les plus connus sont les caméras IP, qui ont servi à plusieurs reprises dans des attaques par dénis de service.
C’est sur une de ces caméras, la VstarCam, que nous allons nous attarder.
Après une rapide recherche sur internet via des outils comme Shodan, on s’aperçoit qu’il existe à peu près 1500 caméras de cette marque directement connectées à internet (beaucoup plus, de manière indirecte).
La caméra est utilisable via une application mobile, on peut alors piloter la caméra, prendre des photos, récupérer des fichiers vidéo, etc. Il paraît alors logique que la sécurité est primordiale dans ce cas d’utilisation. Et pourtant nous allons voir que ce n’est pas cas.
La première partie de l’analyse se concentre sur l’application mobile. On va tout d’abord récupérer cette application et l’analyser via différents outils. Il en ressort un niveau de sécurité faible et cela nous permet de récupérer des informations sur les serveurs avec lesquelles communique l’application. Il apparaît également que ces serveurs sont uniquement un relai entre l’application et la caméra, ce qui signifie que l’authentification via mot de passe est réalisée directement par la caméra.
On va maintenant se placer sur le réseau entre l’application et la caméra afin de récupérer les paquets qui sont échangés. On remarque tout d’abord que le protocole utilisé est simplement un protocole propriétaire qui encapsule des requêtes HTTP classiques. De plus, ces requêtes HTTP ne sont pas chiffrées, donc lorsqu’on se connecte à la caméra, l’identifiant et le mot de passe utilisés sont transmis en clair.
Cela est déjà largement suffisant pour effectuer une attaque sur cette caméra, mais le manque de sécurité ne s’arrête pas là.
En effet, les caméras sont identifiées par un numéro de série unique, et ce numéro est également transmis en clair dans la requête. De ces caméras ont des vulnérabilités connues qui permettent, en connaissance de son numéro ID, de pouvoir récupérer directement les identifiants stockés sur la caméra, de pouvoir récupérer les fichiers vidéos via une injection de commande sur le serveur FTP, ou encore de se connecter sur son serveur telnet avec des identifiants par défaut.
Toutes ces vulnérabilités offrent beaucoup de possibilités à un attaquant. Il peut récupérer les identifiants et se connecter à la caméra. Il peut également se faire passer pour la caméra et envoyer de fausses informations à l’utilisateur. On imagine facilement un scénario où l’attaquant se fait passer pour la caméra et envoie une ancienne vidéo à l’utilisateur qui pense alors que tout est normal.
Ce genre de vulnérabilités n’est pas spécifique aux caméras VstarCam et se généralise à beaucoup de caméra IP chinoises, mais pas seulement.
Il convient donc, pour quiconque souhaitant faire l’acquisition de ce genre de produit, d’apporter un soin tout particulier quant au choix du produit.
Originally published at https://rtone.fr on May 23, 2019.
