Qui sommes-nous ?

Le Security Labs est une équipe de R&D au sein de Sentryo qui développe la prochaine génération de visualisations et d’algorithmes de détection pour notre produit, ICS CyberVision.

Nous analysons les dernières menaces du monde des ICS (Industrial Control Systems) et essayons d’améliorer le produit dans sa capacité de détection et son utilisation. Cela inclut notamment le développement d’outils pour aider nos clients à mieux comprendre leur réseau mais également le développement de nouvelles techniques innovantes pour détecter les cyber-attaques.

Contexte

Bien que notre expertise principale porte sur les systèmes dits “cyber-physique” et spécifiquement les réseaux industriels, nous nous intéressons aussi à d’autres domaines connexes et aux systèmes critiques en général. Et à ce titre, la prochaine génération de voitures connectées et autonomes est un sujet qui nous tient à coeur.

Dans ce cadre, l’année dernière, nous avons étudié de nouvelles façons pour détecter les activités malicieuses sur le réseau d’une voiture, et en particulier, sur la menace particulière de l’injection de message.

Note
Ce travail a fait l’objet d’une présentation à la conférence S4xEurope, dédiée à la sécurité des systèmes industriels, à Vienne (Juin 2017). La vidéo de la présentation est disponible sur YouTube en cliquant ici.

Sur quelle donnée ?

Dans une voiture moderne, des centaines d’équipements électroniques appelés ECUs (pour Electronic Control Units) communiquent sur un bus partagé (une catégorie de système de communication) avec le protocole CAN. Chaque ECU a un rôle spécifique dans le fonctionnement du véhicule. Un ECU peut, par exemple, mesurer la vitesse du véhicule et la communiquer à tous les autres participants sur le bus. Un ECU peut, lui, attendre un ordre spécifique d’un autre ECU pour enclencher le freinage du véhicule.

Le protocole CAN est relativement ancien, et plutôt basique. Chaque ECU peut diffuser un message CAN sur le bus (broadcast). Le message doit contenir un identifiant (ID) qui permet d’identifier l’ECU émetteur. Et le message peut contenir jusqu’à 8 octets de donnée.

Le contenu des messages est, quant à lui, spécifique aux différents constructeurs et modèles de voiture. Nous savons que la valeur de vitesse du véhicule circule dans un des messages sur le bus mais, a priori, nous ne connaissons ni le type de message (ID), ni comment et où la valeur a été encodée dans le message (position, nombre de bits, endianness). Au premier coup d’oeil, on pourrait voir cela comme un mécanisme de protection mais, comme souvent, la sécurité par l’obscurité ne tient qu’un temps, et un attaquant déterminé pourra faire le travail de reverse-engineering nécessaire et trouver l’information.

La menace

Les véhicules récents deviennent de plus en plus connectés au monde extérieur. En utilisant une vulnérabilité sur un des multiples sous-systèmes informatiques existants à l’intérieur du véhicule, un attaquant peut disposer d’un accès à distance au bus CAN.

Une fois sur le bus, l’attaquant peut y injecter des messages malicieux. Ceci est possible à cause de la méthode de communication (broadcast) particulière du bus CAN et du manque de sécurité du protocole. Le problème est que les ECUs prennent régulièrement des décisions critiques basées sur l’information lue depuis le bus et, ces derniers n’ont quasiment aucun mécanisme en place pour filtrer les messages anormaux.

Une attaque en particulier nous vient à l’esprit où un attaquant a réussi à déclencher la fonction de “park assist” (aide au stationnement) de la voiture [1], pendant qu’elle circulait à haute vitesse, pour provoquer un accident. L’ECU responsable du “park assist” doit théoriquement surveiller la vitesse de la voiture et accepter l’ordre à la condition que celle-ci circule à moins de 5 mph (miles par heure). Malgré cette protection, l’attaque a été possible car l’attaquant a aussi injecté de fausses valeurs faibles de vitesse sur le bus (note: l’attaque est ici simplifiée).

Dans cet exemple, tromper un ECU a permis à un attaquant la prise de contrôle de la direction du véhicule dans une situation très dangereuse pour le conducteur. Contourner la restriction de vitesse et forcer un virage à haute-vitesse peut facilement provoquer un accident.

[1] 2016, Charlie Miller and Chris Valasek, “CAN Message Injection”, voir le document

Travaux similaires

Notre projet s’est inspiré du travail de Jun Li [2] qui a présenté son prototype à la conférence DEFCON. L’idée générale est de créer une capacité de détection d’anomalie sur le bus CAN.

Le processus est le suivant :

  • extraire, avec une connaissance de la structure et du contenu des messages, les variables physiques comme la vitesse, les RPM (rotations par minute), ou les valeurs d’accélération circulant sur le bus CAN surveillé;
  • apprendre la normalité du système, c’est à dire les interactions normales de ces variables pendant la conduite;
  • détecter les déviations de ce modèle, ces déviations peuvent révéler une injection malicieuse de messages;

C’est un problème de détection d’anomalie sur des séries temporelles multivariables. Différentes approches existent pour aborder ce problème. Nous allons présenter notre méthode.

[2] 2016, Jun Li, “Deep Learning on CAN BUS”, DEFCON car hacking village 2016, voir la vidéo

Notre expérimentation

Dans ce projet, nous avons utilisé le bus CAN (high-speed) d’une voiture moderne (modèle datant de 2016). Nous sommes partis de zéro, avec le véhicule et un outil pour capturer le trafic CAN. Nous avons alors créé différentes captures réseau de différents parcours réalisés avec le véhicule. Pour chaque parcours, nous avons soigneusement noté nos actions et l’état de la voiture (vitesse, accélération, etc.).

Reverse-engineering des messages CAN

Nous avons alors commencé à analyser cette donnée pour retrouver les différentes variables physiques. A partir de nos observations et de la rare documentation disponible sur Internet, nous avons exploré la donnée et extrait les variables les plus importantes: vitesse, accélération, rotations par minute (RPM), angle de la direction, etc.

Ci-dessous, un exemple de l’extraction de la variable “RPM”. Nous avons découvert que, sur ce modèle, la valeur est stockée dans deux octets consécutifs (le 4ème et le 5ème) des messages d’un CAN ID particulier.

Comme vous pouvez le voir sur la droite, nous avons réussi à reconstruire la série temporelle complète des rotations par minutes, commençant à 0 au début de nos captures, moteur arrêté, et évidemment changeant lors du parcours.

Cela termine cette première partie, qui a présenté l’environnement CAN, la menace de l’injection de messages malicieux, et comment nous avons réussi à extraire la donnée nécessaire depuis les messages. Dans la deuxième partie, nous utiliserons cette donnée pour entraîner des modèles de Machine Learning en conditions normales, et essayer de détecter les attaques d’injection !