Review of the 2019 INSHack day on IoT security

INSHack is an event organized by the InSecurityassociation, a student association of INSA Lyon engineering university, committed to raising awareness of IT security and IoT security.

This event aims to bring together students, businesses and IT security aficionados. It takes place in three phases, starting with conferences led by professional experts, then a buffet lunch meeting with businesses and finally, a security challenge in the evening.

For this fifth edition held on May 2, 2019 on the Lyon INSA campus, the conferences focused on embedded systems and the Internet of Things (IoT).

These themes are very popular at the moment and for good reason. The need for connectivity is growing, whether for individuals, with such aspects as home automation, but especially for businesses and the public sector, through industry 4.0 or the Smart City.

Conference no. 1: State of the art and methodology of IoT security analysis

presented by AlgoSecure

The Internet of Things (IoT) is a booming field and it is estimated that several billion objects will be connected to the Internet in the coming years. Unfortunately, in this race for the IoT market, most businesses and object builders forget (knowingly or unknowingly) to integrate the security aspects.

Obviously this is a problem, because many of these connected objects work by collecting user data, and in the absence of security barriers, these data can be captured by an attacker. But the problem can be even more serious when these devices have an important physical role, such as a pacemaker.

The IoT sector is still sorely lacking in maturity and is repeating the same mistakes as were made in the development of “classic” Internet.

 

From a security point of view and more generally, there are three participants in the IoT ecosystem:

  • Manufacturers, who by nature, have full information about their product to hand and can introduce security during the development phase.
  • Public authorities, which do not have access to full product information, but can define applicable standards that include security.
  • And end-users, who have no access to information about the product.

To test the security of an IoT product, we put ourselves in the end user’s shoes (without information) and we analyse how a product works, trying to identify vulnerabilities and draw up an assessment of the security level.

This is called the pentest (penetration test).

This pentest phase is made difficult because several constraints are inherent to this field: the heterogeneity of devices, their mobility, distribution and scalability.

The main issue arises from the heterogeneity of devices. On the same IoT network, several devices can communicate with each other using different communication media and protocols. This requires the use of different analysis tools for each protocol, and makes it difficult to view the communication and interactions between the different objects.

With the aim of simplifying the information collection and analysis phase, AlgoSecure is working on a tool to bypass the communication protocols used.

Their approach is as follows: collect all the information communicated using sensors and transform this information into a generic format.

Once this step is completed, we need to model and view these interactions. This takes place in graph form, with four steps.

The first graph represents the direct communication between devices (point-to-point link).

The second graph models end-to-end interactions. For example, it serves to view the interaction between a sensor and an actuator without taking into account any intermediaries.

The third graph uses the graphs of phase 2 and groups them by “application” while determining the type of device (sensor, actuator, etc.)

The last graph uses “patterns” to determine the precise interactions and logic flows between the different objects.

This tool uses a database to store generic communications. This database is a neo4j tool used to generate the graphs for the previous steps.

This generic approach allows us to bypass the communication protocols used and enables us to view the interactions between objects. It is particularly effective in the case of a complex IoT system involving interaction between different objects.

This tool greatly facilitates the security analysis of an IoT network, by providing a clear view of interactions and by grouping together the analysis tools specific to a particular communication protocol.

AlgoSecure plans to make this tool public and open-source by the end of 2019.

Looking for more information about RTone?

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.

X