Accès physique indirect

2.3.3 Attaques de longue portée . . . . 44

2.3.4 Attaques indirectes à longue portée . . . . 44

2.4 Classification des attaques . . . . 45

2.5 Conclusion . . . . 47

Dans ce chapitre, nous analysons en détail les différents types d’attaques

sus-ceptibles de cibler les calculateurs embarqués dans une automobile moderne. Nous

nous intéressons ainsi à tous les éléments prenant part à de telles attaques pouvant

permettre de classifier les actions d’un attaquant.

Le chapitre s’agence comme suit. Dans la section 2.1, nous nous intéressons aux

différentes étapes d’une attaque, depuis les motivations de l’attaquant jusqu’aux

conséquences de l’attaque, souhaitées ou non, qui peuvent découler de leurs actions.

Dans la section 2.2, nous présentons et catégorisons les attaques que nous

qua-lifierons d’internes, c’est à dire des attaques réalisables contre le réseau embarqué

d’une voiture lorsqu’on est directement connecté à celui-ci.

La section 2.3 se concentre sur la description et la classification des attaques

lancées à distance contre le véhicule, illustrées lorsqu’il y en a par des exemples

tirés de la littérature.

30

Chapitre 2. Attaques ciblant les architectures automobiles embarquées

Finalement, dans la section 2.4, nous faisons la synthèse des différents scénarios

d’attaques présentés dans les sections précédentes en proposant une caractérisation

de ces attaques selon quatre axes principaux.

2.1 Décomposition d’une attaque

Les attaques contre les équipements embarqués par une automobile peuvent

prendre plusieurs formes. Il convient de distinguer :

1. Les attaques visant à altérer le comportement normal du véhicule sans pour

autant pénétrer son réseau, par exemple en émettant un signal pour perturber

un radar anti-collision. Ces attaques visent principalement les interfaces du

véhicule.

2. Les attaques informatiques, dont le but est de prendre le contrôle de tout

ou d’une partie du réseau embarqué dans le véhicule grâce à l’exécution par

des calculateurs du véhicule de commandes envoyées par l’attaquant, via du

code injecté ou des trames réseau malveillantes émises. Ces commandes sont

envoyées à un point d’entrée tel qu’une prise usb, le lecteur cd, la prise de

diagnostic, etc. Deux sous catégories peuvent être distinguées :

(a) Les attaques informatiques où l’attaquant ne cherche pas spécialement à

accéder au réseau embarqué mais est intéressé par les données qu’il peut

récupérer suite à la compromission d’un élément du réseau embarqué

(qui est par conséquent également la cible finale). Une attaque menée

contre le système télématique afin d’écouter les conversations ayant lieu

dans une voiture entre dans cette catégorie.

(b) Les attaques informatiques où l’attaquant va chercher à interagir avec le

reste du véhicule depuis son point d’entrée via le réseau embarqué.

Lors de nos recherches, nous nous sommes spécifiquement intéressés aux

at-taques informatiques, et plus particulièrement aux atat-taques se propageant via le

réseau embarqué. Nous ne considérons pas pour autant que les autres types

d’at-taques sont négligeables. Ceux-ci constituent également des sujets d’étude

intéres-sants mais sont hors du cadre de nos travaux.

2.1.1 Objectifs de l’attaquant

Avant de s’intéresser aux scénarios d’attaque potentiels, il faut tout d’abord se

demander quels sont les intérêts pouvant motiver une attaque informatique contre

le système embarqué dans un véhicule.

Vol

La motivation au premier abord la plus évidente est peut être le vol. Plusieurs

possibilités sont envisageables pour voler un véhicule (ou son contenu) en

s’ap-puyant sur l’électronique qu’il embarque. Tout d’abord, une attaque réussie contre

2.1. Décomposition d’une attaque 31

le système d’ouverture à distance peut permettre de déverrouiller la voiture, voire

de la démarrer dans le cas de véhicules ne nécessitant plus un contact pour

démar-rer (PKES Passive Keyless Entry and Start). Une autre possibilité est d’utiliser

une vulnérabilité d’un protocole de communication sans fil pour prendre le contrôle

du calculateur correspondant puis de s’en servir pour déverrouiller discrètement

la voiture et désactiver ses mécanismes d’antidémarrage ou une éventuelle alarme

en envoyant des instructions sur le bus. Dans de tels cas, le gain de l’attaquant

correspond à la valeur du véhicule volé ou celle des biens qu’il contient.

Modification des capacités du véhicule

Nous regroupons dans cette catégorie l’ensemble des cas où le propriétaire du

véhicule en est également « l’attaquant ». Celui-ci va alors chercher à effectuer des

modifications non autorisées sur le code ou les données contenus dans un ECU. Par

exemple, il peut vouloir en diminuer le kilométrage pour le revendre plus cher,

alté-rer le fonctionnement du moteur pour tenter d’obtenir plus de puissance ou encore

installer de nouveaux programmes illégalement obtenus sur son ordinateur de bord.

Un attaquant peut également tenter de contourner des mécanismes

d’authentifica-tion afin d’installer des ECUs différents de ceux approuvés par le constructeur afin

de réaliser des économies. Si, du point de vue du propriétaire, de tels actes peuvent

à première vue sembler sans danger immédiat pour la sécurité des passagers, ils

peuvent cependant avoir des conséquences néfastes à plus ou moins long terme

(aussi bien pour le véhicule et ses passagers que pour les finances du constructeur

dans le cas de l’installation de pièces de contrefaçon).

Sabotage du véhicule

Cette catégorie regroupe tout ce qui vise à dégrader le fonctionnement du

véhi-cule. Cela consiste à désactiver ou altérer le fonctionnement d’un ou plusieurs ECU,

en modifiant leur logiciel embarqué, en émettant des trames malveillantes ou en

pro-voquant un déni de service sur le bus. Les conséquences peuvent aller d’une simple

inconvenance (climatisation coupée par exemple) au déclenchement d’un accident

potentiellement mortel (freins qui ne répondent plus). Cependant, il est à noter

que même un léger dysfonctionnement survenant sur un grand nombre de véhicules

pourrait suffire à dégrader durablement l’image de marque d’un constructeur.

Vol de propriété intellectuelle

Un attaquant peut chercher à obtenir des informations confidentielles sur le

fonc-tionnement du véhicule ciblé, par exemple en écoutant et identifiant les trames qui

passent sur le bus, voire en récupérant le code source d’un ECU. Au delà d’une

uti-lisation possible de tels procédés par des concurrents (intelligence économique), ces

informations peuvent aussi permettre la fabrication et le commerce de contrefaçons

d’ECU ou dévoiler des vulnérabilités du matériel à un attaquant.

32

Chapitre 2. Attaques ciblant les architectures automobiles embarquées

Vol de données confidentielles

Les voitures embarquant de plus en plus d’équipements informatiques, elles

peuvent donc contenir des informations personnelles qu’un attaquant cherchera à

récupérer. Par exemple, nous pouvons citer la liste des contacts téléphoniques et

l’historique des appels, les coordonnées GPS des derniers trajets ou encore les

fré-quences radio favorites enregistrées dans l’interface multimédia. D’autres données,

circulant sur le réseau embarqué, peuvent aussi rentrer dans cette catégorie, comme

la vitesse actuelle du véhicule ou le kilométrage par exemple.

Défi intellectuel

Enfin, de nombreux exemples parsemant l’histoire de l’informatique nous

rap-pellent qu’il ne faut pas exclure l’attaquant motivé simplement par le défi que

représente la prise de contrôle d’un véhicule.

2.1.2 Interactions avec un réseau

Comme nous l’avons mentionné précédemment, les réseaux déployés dans les

automobiles à l’heure actuelle ont avant tout été pensés en termes de sûreté. En

faisant l’hypothèse qu’un attaquant a réussi à s’y connecter, nous nous intéressons

maintenant aux possibilités qui lui seraient offertes.

2.1.2.1 Vulnérabilités des bus

Des équipes ont cherché à savoir si des mécanismes de sécurité existaient sur

les automobiles actuellement commercialisées. Ces travaux [WWP04], [HKD09] se

sont tout d’abord intéressés aux potentielles vulnérabilités existant dans les réseaux

internes d’une voiture, en se concentrant majoritairement sur le plus répandu d’entre

eux, CAN. Ainsi il est apparu que de par sa conception, le réseau CAN ne permet

pas en l’état d’assurer les propriétés de sécurité définies en section 1.3.2.1.

Confidentialité Par construction, tout message envoyé sur le CAN est diffusé

(physiquement et logiquement) en clair à tous les nœuds. De fait, un nœud malicieux

peut écouter tout le trafic du bus auquel il est connecté.

Disponibilité Les règles d’arbitrage de CAN (voir 1.2.2) font qu’il est aisé pour

un attaquant de provoquer un déni de service sur le bus en envoyant en permanence

des trames prioritaires, forçant ainsi tous les autres ECU à arrêter leurs émissions.

Intégrité Comme nous l’avons vu précédemment, CAN permet de détecter des

altérations accidentelles survenues lors de la transmission d’un message grâce à un

CRC. Cependant, cela ne suffit pas en termes de sécurité puisqu’un attaquant peut

forger un CRC valide correspondant aux trames qu’il veut émettre. L’intégrité d’un

message n’est donc pas assurée.

2.1. Décomposition d’une attaque 33

Authenticité Une trame CAN (voir figure 1.5a) ne contient pas de champ pour

l’identification de son expéditeur. Par conséquent, n’importe quel nœud peut en

contrôler d’autres sur le même bus en émettant les messages appropriés.

Non répudiation Il n’est pas possible de prouver qu’un nœud a bel et bien émis

ou reçu un message, et donc s’il peut être à l’origine d’une attaque sur le réseau.

Ces propriétés de sécurité n’étant pas garanties par les réseaux automobiles

ac-tuels (des remarques similaires ont ainsi été émises à propos de FlexRay [NLPJ09]),

la prochaine étape est alors de savoir s’il est possible d’exploiter ces lacunes afin de

parvenir à prendre le contrôle d’un ECU, voire du réseau dans son ensemble.

2.1.2.2 Actions élémentaires

Comme définie en 1.3.2.2, une attaque est une action malveillante visant à violer

une ou plusieurs propriétés de sécurité. Quel que soit l’objectif final de l’attaquant,

cette action peut être décomposée en action élémentaires bien définies. Nous

consi-dérons que l’attaquant ne peut interagir avec sa cible qu’à travers le ou les réseaux

(filaires ou non) auxquels elle est connectée. Si les propriétés de sécurité ne sont

pas garanties, les actions élémentaires qu’il peut entreprendre pour arriver à ses fins

sont donc comprises dans la liste suivante.

Lecture L’attaquant a accès au trafic réseau et peut voir le contenu de chaque

trame.

Interruption L’attaquant empêche un message émis d’atteindre ses destinataires.

Ceux-ci ne reçoivent donc aucune information.Il s’agit du but d’une attaque par déni

de service.

Modification L’attaquant modifie le contenu d’un message légitimement émis, de

sorte que les destinataires ne reçoivent que la version modifiée alors que la source

croit avoir émis les bonnes informations.

Fabrication L’attaquant émet lui-même des messages, en les créant de toutes

pièces ou bien en rejouant des messages précédemment observés, se faisant alors

passer pour un autre nœud du réseau.

Une attaque est diteactive lorsqu’elle consiste en au moins une action de type

interruption, modification ou fabrication, et passive si elle ne contient que des

actions de type lecture.

2.1.3 Modélisation des attaques

Comme nous l’avons vu en 2.1.1, il existe bien des motivations pour mener

des attaques informatiques contre le réseau d’une voiture. Par la suite, nous avons

présenté des travaux qui ont montré que de telles attaques étaient réalisables sur des

34

Chapitre 2. Attaques ciblant les architectures automobiles embarquées

véhicules actuels. Par conséquent, il est légitime de faire l’hypothèse de l’existence

d’attaquants ciblant l’informatique embarquée dans l’automobile. À chacune de

ces motivations peut correspondre un ou plusieurs types d’attaquants, possédant

différentes ressources (niveau de connaissances, outils, ressources financières), qui

auront alors à leur disposition diverses méthodes pour parvenir à leurs fins. Les

combinaisons de ces paramètres mènent à une diversité de scénarios d’attaques

possibles. En s’inspirant de ce qui se fait dans l’informatique traditionnelle, des

travaux comme [BSDT09], [HD07] et [WWW07] ont ainsi cherché à caractériser de

telles attaques. Nous reproduisons en figure 2.1 le modèle adapté à l’automobile

proposé dans [HD07]. Ce modèle s’inspire, du modèle, défini dans [HL98] et utilisé

par les CERT (Computer Emergency Response Team) pour leur classification des

incidents. Cette classification opère une distinction entre événements, attaques et

incidents. Ainsi, un évènement consiste en l’application d’une action contre une

cible, ce qui correspond à la partie centrale de la figure. La description d’une attaque

prend également en compte les outils utilisés, les vulnérabilités exploitées ainsi que

le résultat de ces actions sur le système. Finalement, l’incident correspondant à une

attaque est classifié en identifiant l’attaquant ainsi que ses objectifs.

Hackers Spies Terrorists Corporate raiders Professional criminals Vandals Voyeurs Security scans Tuners Thieves Competing manufacturers

Attackers Tool Vulnerability Action Target ^Unauthorized_Result Objectives Malicious code Attached devices Wireless equipment Manipulated media Social engineering Design (protocol, specification, application) Implementation Configuration Misbehavior of a user Read Create/Spoof Copy Steal Delete Modify/ Reconfigure Probe Scan Flood Authenticate Bypass Automobile Bus system Control Unit Operating map Occupants/ Owner User data Manufac-turer data Road safety Increased access Disclosure of information Corruption of information / programs Blocking of resources (denial of service) Theft of resources Causing costs Violation of Confidentiality, Authenticity, Integrity, Availability, Non repudiation, Privacy Challenge, Status, Thrill Political gain Financial gain Damage Security evaluation Tuning

Event

Attack

Incident

Figure 2.1 – Classification du CERT adaptée à un environnement

automo-bile [HD07]

À l’heure actuelle, s’il est possible de trouver de nombreuses illustrations

d’at-taques contre les réseaux automobiles, comme nous le verrons par la suite, très peu

(voire aucun) d’incidents liés à la sécurité concernant des automobiles en circulation

2.1. Décomposition d’une attaque 35

ont été reportés. Pour l’instant, il semble donc difficile de déterminer avec si peu

de données si de telles classifications permettent bien de représenter l’ensemble des

menaces réelles.

Pour obtenir davantage d’informations au sujet des attaquants, l’utilisation d’un

pot de miel adapté à l’automobile a été proposée dans [VNLJ08] (voir la section 3.4.2

pour plus de détails). En faisant circuler des voitures équipées de ces pots de miel

pendant une certaine période, cela pourrait permettre de confirmer l’existence

d’at-taquants ciblant les réseaux automobiles, et le cas échéant donner de plus amples

informations sur leurs comportements, leurs moyens, leurs objectifs. Si un

déploie-ment (a fortiori à grande échelle) d’une telle expérience peut sembler irréaliste

aujourd’hui, un tel projet pourra devenir réellement intéressant dans un futur à

plus ou moins long terme, si les tendances vers l’autonomie et l’interconnexion des

véhicules se poursuivent et que de tels véhicules se démocratisent.

2.1.4 Conséquences étendues d’une attaque

Les scénarios d’attaques évoquées précédemment concernent le point de vue de

l’attaquant : dans le modèle de la figure 2.1, un incident se conclut ainsi par la

réalisation des objectifs de l’attaquant. Or, comparée à un système informatique

traditionnel, une voiture moderne constitue un véritable système cyber-physique.

Une perturbation (intentionnelle dans le cas d’une attaque) de l’informatique

em-barquée peut ainsi entraîner des répercussions sur le reste du véhicule et mettre

en danger ses passagers. Il convient donc également de considérer le véhicule dans

son intégralité lors de l’analyse des effets d’une attaque informatique contre

celui-ci, et non juste le système ciblé. [HKD09] définit à cet objet deux catégories de

conséquences :

– Les conséquences fonctionnelles, qui décrivent les effets que l’attaque a eu sur

les fonctionnalités du système embarqué ciblé. Elles correspondent souvent

aux objectifs de l’attaquant, ou sont du moins prises en compte par celui-ci

lors de son attaque.

– Les conséquences structurelles, qui décrivent les effets de l’attaque (ainsi que

du nouveau comportement du système embarqué ciblé) sur l’ensemble du

véhicule ainsi que sur son environnement. Si l’objectif de l’attaque n’était pas

in fine de nuire aux occupants de la voiture, ces conséquences peuvent ne pas

avoir été prévues ou être volontairement ignorées par l’attaquant.

Pour illustrer ces distinctions, considérons deux exemples hypothétiques.

1. Le propriétaire d’un véhicule réussit à manipuler l’odomètre pour diminuer le

kilométrage enregistré afin d’en tirer un meilleur prix à la revente. La

consé-quence fonctionnelle est la diminution de la valeur de la distance parcourue

mémorisée. Les conséquences structurelles concerneront tous les effets dus à

l’usure réelle du véhicule, usure que le nouveau propriétaire ignore.

2. L’attaquant souhaitant contrôler des ECU sur un bus critique réussit à émettre

des trames sur celui-ci, augmentant du coup le trafic sur le réseau. Ces trames

36

Chapitre 2. Attaques ciblant les architectures automobiles embarquées

possédant un identifiant bas, les règles d’arbitrage (cf 1.2.2) font que ses

sages sont prioritaires sur le bus et retardent donc l’émission d’autres

mes-sages, entraînant potentiellement des délais dans l’exécution de fonctions

cri-tiques. Ici, les conséquences fonctionnelles seront les réactions provoquées par

les trames émises par l’attaquant. Les conséquences structurelles concernent

l’impact de la congestion réseau sur le reste des calculateurs du bus (passage

en mode dégradé, réactions décalées . . . ).

2.2 Attaques locales

Dans cette section, nous nous intéressons aux possibilités offertes à un attaquant

lorsque celui-ci possède un accès physique direct sur le réseau embarqué, c’est à dire

qu’il a le contrôle d’un (ou plusieurs) nœuds du réseau. Nous y décrivons les

at-taques présentées dans la littérature, réalisables en ayant un tel accès direct sur le

réseau embarqué. Nous les avons catégorisées en fonction de l’impact qu’elles ont

sur le réseau embarqué du véhicule. Tout d’abord, nous présentons les procédés

permettant à un attaquant d’acquérir suffisamment de connaissances sur le réseau

avec lequel il cherche à interagir. Ensuite, nous détaillons les attaques n’entraînant

pas de conséquences durables sur le réseau embarqué. Finalement, nous nous

inté-ressons aux attaques altérant durablement le réseau, c’est à dire dont l’effet sur le

réseau perdure après le passage de l’attaquant.

2.2.1 Découverte de la cible

Tout d’abord, rapppelons que si CAN fait l’objet de standards, ceux-ci régissent

le format des trames mais pas l’agencement des données à l’intérieur de chaque

champ. Ceux-ci sont ainsi différents pour chaque constructeur, voire pour chaque

modèle de véhicule. Ainsi, un même identifiant N ne désignera pas nécessairement le

même type de trame d’un modèle à l’autre. Par conséquent, une trame N ne sera pas

nécessairement destinée aux mêmes ECUs et les informations contenues dans son

champ de données différeront également. Jusqu’à présent, les détails concernant

le contenu des trames émises sur le réseau embarqué sont gardés secrets par les

constructeurs, qui cherchent ainsi à dissuader toute tentative de manipulation du

réseau par autrui.

La première étape d’une attaque va donc généralement consister en une prise de

connaissance du système afin de comprendre quel est le rôle de chaque trame. Le

réseau CAN (ainsi que les autres protocoles couramment utilisés) ne garantissant

pas la confidentialité des données, le simple fait d’être connecté sur un bus suffit

pour observer son trafic en clair. Des attaques en "boîte noire" peuvent ainsi être

réalisées pour découvrir le fonctionnement du réseau. Cela se fait simplement en

se connectant au même bus que le système que l’on souhaite observer, puis en

observant le trafic réseau produit en réponse aux stimuli que l’on fournira. Ceux-ci

peuvent être des manipulations des différents équipements de la voiture (activer les

essuie-glaces, ouvrir une porte . . .) ou bien des trames émises sur le bus, qu’elles

2.2. Attaques locales 37

soient rejouées suite à une précédente observation ou générées aléatoirement (on

parlera alors de fuzzing).

Enfin, pour une compréhension plus approfondie du fonctionnement de certains

ECU, il reste possible de faire de la rétroingénierie en récupérant le code qu’ils

contiennent et en effectuant un débogage sur celui-ci.

Selon les modèles de voiture (et donc en fonction de l’architecture du réseau

embarqué), une simple connexion via le port OBD suffit pour pouvoir écouter une

part importante du trafic et interagir directement avec de nombreux ECU. [HKD09]

a ainsi détaillé un processus d’analyse en boîte noire en réalisant des écoutes via le

port OBD, et ce malgré la présence d’un filtre entre le port diagnostic et le reste

Dans le document Détection d'intrusion pour des réseaux embarqués automobiles : une approche orientée langage (Page 40-53)