Skip to content

Voitures connectées : Où en est le car hacking ?

Lors du defcon 21 (celui de 2013), Charlie Miller, ingénieur sécurité chez Twitter, a fait une conférence sur l’avancement de ses travaux sur le Car Hacking, c’est-à-dire le piratage de voiture, dans lesquelles il y a de plus en plus de composants électroniques. Les résultats de ce qu’il a réussi à obtenir avec son collègue, Chris Valasek, directeur Security Intelligence chez IOActive, lors de leurs recherches sont assez impressionnants, c’est pourquoi il est intéressant de le partager.

[Update : 19/12/2015] Des avancées considérables ont été réalisée depuis dans le domaine des attaques sur les voitures connectées depuis que cet article a été écrit. Il est toutefois intéressant de le lire car le fonctionnement des processus de communications dans les voitures utilisant des composants de communication.

Car Hacking, qu’est ce que c’est ?

Comme le nom vous l’aura sûrement fait deviner, le car hacking est le fait d’essayer d’exploiter les composants électroniques présents dans une voiture ou un élément motorisé (comprendre « automative » en anglais) afin d’en prendre totalement ou partiellement le contrôle. Le hacking est désormais un terme plutôt commun dans le langage de tous et l’on a directement l’image d’un serveur qui se met à envoyer tout et n’importe quoi ou des choses plus ou moins sensibles selon votre degré de connaissance en informatique. Le car hacking a de particulier qu’il est relativement nouveau et qu’il permet, in fine, de prendre le contrôle d’un engin mécanique relativement puissant. Les experts souligneront que des techniques de hacking ayant des effets physiques existent déjà, on prendra pour exemple le piratage d’environnements SCADA qui permettent de contrôler de grandes infrastructures techniques comme des centrales nucléaires ou des barrages. La dangerosité criante du car hacking est qu’aujourd’hui, au même titre que les smartphones ou les tablettes, une grande majorité de personnes possède une voiture avec plus ou moins d’éléments électroniques et que la présence de ces derniers tend indéniablement à croître.

Il faut savoir que les travaux de recherche qu’ils ont entamés sur les composants électroniques des voitures (ECU ou Electronic control units) ont débutés en 2010. Leur premier objectif a d’ailleurs été de trouver une voiture assez récente pour contenir des composants électroniques, mais relativement peu cher pour effectuer tout un tas de tests et de démontages dessus. L’essentiel de la démarche a été fait dans plusieurs buts :

  • Explorer une technologie mal ou non documentée
  • Faire partager ces découvertes à tous
  • Voir ce qu’il était possible de faire au niveau de la sécurité des utilisateurs finaux
  • Faire prendre conscience à tous de ce niveau de sécurité.

Dès le début de sa présentation, Charlie Miller convient à dire que « Car Hacking is hard », ce qui est plutôt logique au vu de quelques raisons évidentes :

  • Les technologies utilisées sont rarement vues, nouvelles et très peu ou pas du tout documentées. Il s’agit souvent de protocoles ou « d’applications » propriétaires que l’on n’a pas l’habitude de voir sur un système/réseau normal.
  • La partie mécanique de la voiture qui est en relation avec les composants électroniques est tout à fait inconnue pour des professionnels des nouvelles technologies, Charlie Miller ironise d’ailleurs en affirmant qu’il était plus facile de désassembler les applications des composants électroniques que de désassembler la voiture.
  • Les tests, tant au niveau réseau qu’applicatif étaient dur à réaliser, cela dû à la taille de l’engin à tester, des conséquences que cela pouvait avoir au niveau de la sécurité des testeurs, mais également, car les protocoles de communication n’étaient pac compatibles nativement avec les PC standards.

Après quelques recherches, les voitures obtenues ont été une Ford Escape de 2010 et une Toyota Prius de 2010 également, année à partir de laquelle les composants électroniques sont assez présents et communiquent suffisamment pour essayer d’en faire quelque chose. On parlera par exemple du Park assist qui permet d’effectuer des créneaux de manière autonome. Il est d’ailleurs à noter, pour ceux qui ne l’ont jamais expérimenté, que seul le volant bouge de façon autonome lors de ce processus, la vitesse et la marche avant/arrière est elle gérée par le conducteur. Il existe aussi la fonction « Pre-collision system » que l’on peut décrire comme un système de correction de trajectoire à vitesse élevée, on s’apprête à tourner à gauche ou à droite alors qu’il y a présence d’un objet (voiture, cycliste…). La voiture corrige alors automatiquement la trajectoire afin de ne pas percuter l’objet et il y a alors prise de contrôle du volant.

Electronic Control Unit (ECU)

Les chercheurs ont dans un premier temps utilisé ce genre de comportement pour étudier les réactions des composants électroniques de la voiture. Parmi ces composants, on notera donc les ECU.

Les Electronic control unit (ECU) sont les différents composants électroniques d’une voiture. Charlie Miller les assimile à des petits PC qui exécutent chacun une fonction bien spécifique au sein de la voiture. On peut en retrouver selon lui entre 20 et 30 au sein d’une même voiture, ils permettent de recevoir des informations de différents capteurs et également d’exécuter des actions mécaniques comme le fait de freiner ou de bouger le volant à droite ou à gauche. L’ECU est un terme générique et peut désigner plus généralement un composant portable qui peut être sous un OS propriétaire ou Windows.

À ce titre, on peut remarquer sur Wikipédia que chaque rôle des ECU peut être décrit via une abréviation. Ainsi, l’ECU se chargeant de la suspension (capteur et acteurs) se nommera SCM (Suspension control module). Les documents parlant du Car Hacking étant aujourd’hui plutôt rares et techniques (étant donné la nouveauté de la technologie), la connaissance des terminologies aide bien à les comprendre.

Il faut également préciser qu’au niveau physique, les ECU sont reliés entre elles suivant une topologie en bus, voici par exemple la topologie  CAN d’une Toyota Prius :

car hacking
Schéma du réseau CAN dans une voiture

CAN

Nous pouvons également parler de leur mode de communication bien spécifique, que Charlie Miller et son collègue Chris Valsek détaillent dans la vidéo de defcon21. Il s’agit du CAN ou Controller area network. Un simple BUS qui permet de relier chaque ECU entre elles et de les faire communiquer. CAN fait partie des 5 protocoles présents dans le on-bord diagnostics (OBD-II) qui permet l’échange de messages de diagnostique au sein de véhicule, aussi présent dans les engins comme les trains, les avions ou les bateaux. En Europe, CAN a été implémenté dans les véhicules à partir de 2001 (2004 pour les diesels). Charlie Miller en fait rapidement le tour lors de sa conférence :

  • Tous les messages sont envoyés en broadcast, il est assez difficile alors de savoir qui a envoyé tel ou tel paquet et à qui il est destiné, sans parler de l’absence totale de vérification de l’envoyeur ou du récepteur.
  • Tous les nœuds du bus reçoivent donc tous les paquets envoyés par les autres nœuds.
  • Il existe néanmoins un système de priorité binaire, les messages CAN dont l’ID est « 00 » seront prioritaires sur les « 01 ».
  • Le champ data qui est celui contenant les données « utiles » pour le nœud récepteur fait 8 octets.

Il en existe globalement deux types, les CAN « normaux » qui n’ont pas de sécurité particulière et les « diagnostic CAN » qui permettent d’avoir des informations plus précises et sont pourvus d’une identification entre l’émetteur et le récepteur et une authentification sous forme de challenge :

  • Le principe global et de prouver sa légitimité avant d’envoyer des messages diagnostic CAN à un ECU
  • l’ECU qui est censé recevoir des informations envoie un challenge de 3 octets utiles après le message qu’on lui a envoyé
  • l’ECU émetteur reçoit le challenge et renvoie ces trois octets en les traitant avec une clé interne à cet ECU précis, cette clé étant propre et différente à chaque ECU, l’ECU destinataire saura en fonction de ce qui lui est retourné de quel ECU il s’agit de par la façon dont cet ECU émetteyr l’aura traité.

Cela permet à la clé qui sert à traiter les échanges de ne jamais transiter via le protocole de communication CAN. Dans ses documentations, Charlie Miller fournit cet exemple d’échange :

IDH: 07, IDL: 26, Len : 08, Data : 02 27 01 00 00 00 00 00
IDH: 07, IDL: 2E, Len : 08, Data : 05 67 01 54 61 B6 00 00
IDH: 07, IDL: 26, Len : 08, Data : 05 27 02 D0 B6 F1 00 00
IDH: 07, IDL: 2E, Len : 08, Data : 02 67 02 00 00 00 00 00

ISO-TP (ISO1565-2)

Nous en apprennons également un peu sur l’ISO-TP (ISO 15765-2) qui est utilisé pour envoyer des données arbitraires d’une ECU à l’autre et permet, entre autre, de spécifier la caractéristique d’un message envoyé à travers CAN. Typiquement, les premiers octets signifient de quel type de message CAN il s’agit. En reprenant les exemples donnés par Charlie Miller :

 IDH: 07, IDL: 60, Len : 08, Data : 03 14 FF 00 00 00 00 00

IDH: 07, IDL: E0, Len : 08, Data : 10 82 36 01 31 46 4D 43
IDH: 07, IDL: E8, Len : 08, Data : 30 00 00 00 00 00 00 00
IDH: 07, IDL: E0, Len : 08, Data : 21 55 30 45 37 38 41 4B
IDH: 07, IDL: E0, Len : 08, Data : 22 42 33 30 34 36 39 FF
IDH: 07, IDL: E0, Len : 08, Data : 23 FF FF FF 2A FF FF FF

On observe en première ligne la présence d’un message CAN dit « unique » dans le sens où il est le seul message à transmettre l’information et qu’il contient l’information en entier dans le paquet. Ceux-ci sont identifiés par la première partie du premier octet (appelé « nibble » ou « quartet« ) représentée ici en hexa « 0« , le « 3 » qui suit indique les trois octets suivants sont utiles (soit « 14 FF 00« ). Suit la deuxième ligne le premier quartet qui est à « 1« , ce qui signifie qu’il s’agit du premier paquet d’une suite d’autres paquets qui formeront un message complet une fois tous reçu, les 3 prochains quartets (« 0 82« ) indiquent la taille totale de l’information. On a ensuite un paquet avec un premier quartet à « 3 » qui indique qu’il s’agit d’une sorte de paquet ACK en TCP appelé « Flow control frame ». On a ensuite une suite de paquet avec le premier quartet à « 2 » ce qui signifie qu’il s’agit de composants d’une suite de message (dont le premier est celui avec le quartet commençant à « 1« ), le deuxième quartet de ces lignes indique le numéro de message de la suite. On retrouve donc la suite  :

  • 10 xx xx xx -> Premier paquet de la suite
  • 21  xx xx xx -> Deuxième paquet de la suite
  • 23  xx xx xx -> Troisième paquet de la suite

et ainsi de suite. Pour avoir un résumé plus clair de la signification des premiers quartets de chaque paquet :

  • 0 – « Single frame » : il s’agit d’un paquet unique contenant l’ensemble de l’information, le deuxième quartet contient le nombre d’octets utiles
  • 1 – « First frame » : il s’agit du premier message CAN d’une suite de plusieurs messages CAN, les 2ème, 3ème et 4ème octets indiquent la taille totale de l’information
  • 2 – « Consecutive frame » : il s’agit  de message contenant le reste de l’information d’une suite de message CAN (ceux-ci suivent forcément un message « First frame »)
  • 3 – « Flow control frame » : il s’agit d’une sorte de message d’acknowledgement concernant un paquet « First frame » afin de valider son envoi, il peut également spécifier des paramètres d’envoi des paquets « Consecutive frame » qui suivront, comme leurs délais d’envoi

Le plus intéressant dans ces recherches étant bien sûr les attaques menées et leurs effets sur les voitures ciblées. Il faut savoir que lors de sa présentation au defcon 21, la seule façon dont les voitures ont pu être partiellement contrôlées est via un ordinateur branché sur le « réseau interne » de la voiture, c’est à dire qu’il envoyait des messages CAN au travers quelques adaptateurs comme cet « ECOM cable » qui permet la liaison entre un périphérique ECOM et un PC avec un port USB :

car hacking ecom
Voici l’embout d’un ECOM cable utilisé pour le car hacking

Voici une photo montrant une connexion entre la voiture et un ordinateur portable qui aura pour finalité d’injecter des messages (des ordres) aux ECU (composants électroniques) de la voiture :

car hacking
On imagine aisément que la tâche a dû être fastidieuse, tant au niveau de la mise en place des tests que des tests eux-mêmes.

De par ce biais, les deux chercheurs ont donc pu procéder à l’injection de messages CAN dans le but de faire effectuer des actions aux différents ECU et donc aux composants mécaniques de la voiture (volant, accélération, frein…).  Cependant, quelques limites aux périmètres de l’injection de message CAN ont été identifiées comme :

  • Toutes les fonctions mécaniques ne sont pas modifiables ou dirigeables par des messages CAN. L’accélérateur électronique par exemple dépend bien d’un ECU, mais celui-ci n’attend pas toujours de message venant d’autres ECU pour agir, son action ne peut donc pas toujours être modifiées via l’injection de message CAN
  • Le conflit entre les vrais messages envoyés entre ECU et les faux messages envoyés par les pirates entrent en conflit, ce qui peut produire des actions contradictoires avec un résultat n’ayant pas grand sens. On imagine par exemple que le correcteur de trajectoire envoie le volant à droite et qu’en même temps des paquets malveillants l’envoient à gauche, tout ça plus ou moins en même temps.

Variation de l’indicateur de vitesse

Le premier exemple présenté lors du Defcon 21 est le fait de faire changer la valeur du « speedometer », c’est-à-dire du compteur de vitesse, digital dans le cas d’une Ford. Ceci a été fait via un simple code python envoyant des messages CAN à l’ECU s’occupant de l’affichage de cette information :

car hacking python code
Code python utilisé lors du car hacking

Dans les vidéos présentées lors de la conférence, on voit clairement que la voiture est immobile, mais que le compteur affiche tout de même une vitesse qui varie selon le bon vouloir de la personne derrière l’ordinateur connecté au réseau :

car hacking vitesse
Exemple de car hacking par le contrôle de l’affichage de la vitesse

Prendre le contrôle du volant

Les chercheurs ont également, par ce biais d’injection de message CAN « normaux », réussi à prendre le contrôle du volant pour faire tourner la voiture. Une limite importante tout de même de la réussite de cette prise de contrôle est que la voiture soit dans le mode « Auto Park assist » ou à très basse vitesse (en dessous de 8 km/h) autrement les messages CAN seront ignorés (par sécurité sans doute).

Pour prendre la décision de bouger le volant à droite ou à gauche, le véhicule se base sur des capteurs de proximité ainsi que sur la vitesse du véhicule qui indique au PSCM (Power Steering Control Module ou module de contrôle du volant) de tourner le volant. Il « suffit » donc de récupérer la position du volant (indiquée dans les messages CAN commençant par « 00 81 »). En les récupérant lors d’une procédure d’assistance au parking, voici les valeurs que ces messages contenaient :

car hacking park assit
Graphique observé pour le park assist

Comme dit précédemment, le cadre d’attaque a été identifié comme faible de par le fait que les messages indiquant au volant de tourner seront simplement ignorés à vitesse normale ou élevée dans le cadre du Park assist.

D’autres attaques plus dangereuses ont été menées, cette fois-ci par l’injection de message CAN de type diagnostique (ceux requérant une identification entre ECU via le challenge dont nous avons parlé plus haut). Parmi les attaques menées avec succès :

  • Accès sécurité (Ford)
  • Désactivation des freins (Ford)
  • Extinction des phares et des lumières (Ford)
  • Activation des freins (Toyoya)
  • Activation/Désactivation du verrouillage des portes (Toyota)
  • Resserrage de la ceinture (comme lorsque l’on freine et que la ceinture ne peut plus se tirer) (Toyota)
  • Variation de la jauge de carburant (Toyota)

Note : Loin d’avoir fait le tour de la présentation et de la discipline, je vous invite à regarder la vidéo de la présentation lors du defcon 21 et également le PDF « Adventures in Automotive Networks and Control Unit » écrit par  Charlie Miller  et Chris Valasek.

Et si on regardait plus loin ?

Les résultats obtenus après quelques mois de recherche sont tout de même impressionnants, même si à l’heure de la présentation les techniques utilisées nécessitaient une connexion physique à l’hôte attaqué, on peut réfléchir à quantité de façon dont les voitures communiquent  aujourd’hui et voir qu’il y a également des connexions qui peuvent s’effectuer à distance :

  • Connexion via le GPS
  • Liaison avec les Smartphones
  • Liaison Bluetooth
  • WiFi, avec des solutions comme AutoBox, qui se charge de distribuer le WiFi dans une voiture en plus d’avoir une carte SIM pour obtenir Internet par exemple
  • Des systèmes de communication entre les voitures comme Scoref : voir cet article venant d’un grand média « http://www.lesnouvelles.fr/2013/05/06/scoref-un-systeme-pour-ameliorer-la-securite-routiere/« . Il est d’ailleurs à souligner l’insouciance du directeur du projet Gérard Segarra : « En 2040, nous serons capables d’éviter les accidents graves en prenant le contrôle des véhicules. Lorsque par exemple deux véhicules risqueront de se “rencontrer”, le système agira pour freiner la voiture ou la faire dévier de sa trajectoire« . Le système pourra donc, s’il est corrompu, être utilisé pour un tas d’autres actions plus malveillantes les unes que les autres. On y voit bien là une avancée certaine pour la sécurité routière.

Il y a d’ores et déjà des exemples de composants électroniques de voiture bogués ayant mis en danger la vie de leur propriétaire. On peut par exemple prendre le cas de cet automobiliste qui a franchi 3 péages à 200 km/h parce que son régulateur de vitesse était « simplement » bogué et bloqué (Source : Ladepeche.fr)

Il est assez étonnant de voir à quel point les erreurs faites lors de la création des protocoles de communication entre ordinateurs n’apprennent rien à ceux qui construisent de nouveaux systèmes. Le simple fait que les ECU acceptent de recevoir des messages CAN ayant un effet direct sur les processus mécaniques (volant, accélérateur, affichage compteur…) sans aucune vérification de la légitimité de l’émetteur est simplement une faille de sécurité béante évidente. Si l’on fait la transition avec un domaine plus connu, il s’agirait de la même chose que si l’on autorisait un inconnu à exécuter certaines commandes Shell sur un serveur Linux. Ceci sans authentification ou vérification de son identité.

Il est désormais courant d’entendre parler de ransomware ou de virus infectant plusieurs milliers d’hôtes par jour comme le dernier SynoLocker qui chiffrait les communications des NAS avec plusieurs dizaines de milliers d’hôtes infectés. Que se passerait-il si au lieu de chiffrer le contenu de milliers de NAS, une joyeuse équipe de pirate décidait d’exploiter une faille 0-day dans un modèle de voiture ou de firmware pour les faire aller à 150 km/h ? Un scénario catastrophe qui parait beaucoup moins drôle lorsque l’on s’intéresse à ce que Charlie Miller et Chris Valasek (qui ne sont certainement par les seuls à travailler sur le sujet) ont réussi à faire.

On peut maintenant étendre ce genre d’analyse à l’Internet des Objets, qui est une tendance à connecter tout ce qui entoure notre quotidien, de la montre au frigo. On étend alors la problématique de la sécurité non pas seulement à du matériel stockant des photos de famille ou permettant d’appeler ses proches, mais à des engins capables de causer des dégâts assez conséquents, d’engendrer des consommations d’énergie à l’échelle d’une ville entière,de stocker ou de garantir le bon conditionnement de la nourriture. La sécurité prend alors une tout autre tournure qui est loin des préoccupations économiques et stratégiques des entreprises. Alors que cet Internet des Objets est d’ores et déjà présent (montre, smartphone, lunettes, frigo…), la sécurité est aussi absente dans leur conception qu’elle ne l’était il y a quelques années lorsque toutes les entreprises se connectaient à Internet pour simplement échanger des mails.

I Am The Cavalry

« The Cavalry is a global grassroots organization that is focused on issues where computer security intersects public safety and human life« 

Ce collectif « I am The Cavobalry » a donc pour but premier de faire agir les constructeurs et concepteurs d’objets et de technologies comme celles présentes dans les voitures connectées (mais aussi d’autres objets connectés comme les appareils médicaux, aujourd’hui informatisés ou les appareils domestiques) de porter plus leur attention sur la sécurité de ces objets et, in fine, de leur utilisateur : le grand public.

Un an après la présentation de Charlie Miller, lors du DefCon 22, ce collectif a adressé une lettre à l’industrie automobile afin de leur demander de mettre en place des mesures de sécurité plus importantes dans les systèmes électroniques des véhicules (ce qui serait également valable pour tous les objets connectés à venir). « I am the Calvary » est la signature de cette lettre et représente donc un ensemble de chercheurs en sécurité et de personnes préoccupées par la sécurité du grand public à l’utilisation des objets connectés tels que les voitures utilisant des composants électroniques comme vus dans cet article.

Plus qu’une simple demande, le groupe a même orienté les industries vers certaines solutions ou début de solution comme le fait de faciliter la mise à jour des firmwares ou l’utilisation des systèmes d’isolement physique des différents composants et non un isolement logique qui pourra tôt ou tard être bypassé.

Partager :
Published inArticles

3 Comments

  1. Petites Précisions: Les différents calculateurs (les fameux petits composants électrocinétiques) ont des noms bien différents suivant la marque de la voiture Pour le cas des différents bus de multiplexage,il y en a de toutes sortes,CAN H et CAN L, VAN dont les principales différences sont le temps de réponse et le signal qui est différent

    • Ogma_Sec

      Merci également pour ces précisions. Comme je l’ai dit je n’ai pas fait le tour du sujet mais c’est quelque chose dont je suis certains on va entendre beaucoup parler prochainement !

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *