Analyse du système de sécurité du drone : AR.Drone 2.0 Quad

Analyse du système de sécurité du drone : AR.Drone 2.0
Quad-Copter
[Codages et Sécurité des Réseaux]
CLAURE CABRERA Oscar Mike
DOYEN-LE BOULAIRE Marine
Filiere ISSC
ENSIMAG
Grenoble, France
Filiere ISSC
ENSIMAG
Grenoble, France
[email protected]
[email protected]
ABSTRACT
Les drones ont initialement été utilisés au profit des forces
armées ou de sécurité d’un Etat, mais de plus en plus ont
aussi des applications civiles comme la recherche, le cinéma,
et l’environnement.
Certains fabriquants ont compris que les drones pouvaient
leur ouvrir le marché des particuliers, passionnés par l’aéromodélisme
ou simplement souhaitant réaliser des vidéos de vacances
originales. Depuis les premiers modèles à destination du
grand public, les drones se sont énormément démocratisés,
ne coûtant plus que quelques centaines d’euros pour des
modèles relativement perfectionnés, pilotables depuis un smartphone et retransmettant un flux vidéo en streaming. En particulier, l’interface de l’application AR.Freeflight de l’entreprise
Parrot a été conçue de manière à pouvoir être utilisée par
Figure 1:
Capture
des personnes n’ayant aucune connaissance en pilotage.
AR.Freeflight
Un des modèles les plus populaires aujourd’hui est l’AR.Drone
2.0 de la société française Parrot. Ce drone étant principalement considéré comme un jouet, la sécurité de ses systèmes
et de ses communications n’a, semble-t-il, pas été un élément central lors de sa conception. Pourtant, il est faux de
croire que le piratage d’un drone est sans intérêt ou sans
conséquence. Outre, le vol pur et simple (un pirate prend le
contrôle du drone, le fait atterrir et part avec), il est possible d’imaginer des scenarii où le drone, devenu incontrôlable
pour son pilote légitime, tombe au milieu d’une foule ou
percute des lignes à haute tension.
Les gouvernements prennent peu à peu conscience des risques
et des opportunités que représentent les drones et commencent à les prendre en compte dans la législation. En France,
leur utilisation est principalement réglementée par deux arrêtés du 11 avril 2012 et par le code de l’aviation civile. En
ce qui concerne les activités dites de loisirs pratiquées par
d’écran
de
l’application
des amateurs, les limites de ce qu’il est possible de faire sont
assez simples. Le vol au-dessus d’une zone peuplée est interdit ; le pilote doit toujours avoir un visuel sur son appareil.
La hauteur maximale de vol est de 150 mètres, bien qu’il existe des zones avec des limitations plus basses, par exemple
à proximité d’un aérodrome. Dans le cas d’un vol en immersion (le pilotage se faisant directement à partir de la vidéo
envoyée en streaming par le drone), un second pilote doit
avoir un visuel sur le drone et être capable d’en reprendre le
contrôle à tout moment. Un autre point crucial de la règlementation est le respect de la vie privée d’autrui. En effet,
ces drones sont quasiment tous équipés de caméras haute
définition et donc capable de filmer des personnes n’ayant
rien à voir avec le pilotage du drone dans leurs activités.
Comme pour des prises de vue plus classiqes, il est interdit de filmer des personnes sans leur consentement. Enfin, la diffusion et surtout la commercialisation des images
obtenues au moyen de la caméra d’un drone sont interdites.
Cette restriction est souvent interprétée dans le milieu des
passionnés comme une concession faite aux photographes
professionnels pour éviter une concurrence.
Dans cet article, nous faisons une étude du système de communication de l’AR.Drone 2.0 Quad-Copter, suivie d’une
étude de ses faiblessses et des attaques qu’il est en conséquence possible de mettre en place.
Table 1:
Résultats de
AR.Drone
Port Nom du service
21
FTP
23
Telnet
5555
freeciv
1.2
Figure 2: AR.Drone 2.0 Parrot sur lequel porte
cette étude
Categories and Subject Descriptors
H.4 [Information Systems Applications]: Miscellaneous;
D.2.8 [Software Engineering]: Metrics—complexity measures, performance measures
General Terms
Security, Drone
Keywords
Security, Drone
1.
INTRODUCTION
L’AR.Drone de la société Parrot est un drone Quad-Copter
commandé à distance grâce à l’application AR.FreeFlight
disponible pour les apparails mobiles de plateforme iOS et
Android. La connexion se fait via un réseau Wi-Fi nonsécurisé créé par le drone après son allumage. Ainsi tout appareil peut s’y connecter, envoyer des instructions au drone
et recevoir sa télémétrie et son flux vidéo.
Même si l’AR.Drone 2.0 n’est pas un drone à usage professionnel, ses caractéristiques physiques et sa facilité de contrôle, grâce à l’application AR.FreeFlight, font de lui un
outil puissant. L’AR.DRONE offre aussi la possibilité, en
utilisant son propre SDK, de développer des applications
diverses ciblant la recherche, la sécurité, les jeux, la cinématographie, etc.
1.1
Etude d’une trame wireshark
La figure 1 présente la capture d’une communication entre
le pilote (adresse IP : 192.168.1.2) et le drone (adresse IP :
192.168.1.1).
Le protocole utilisé au niveau de la couche 4 du modèle OSI
est le protocole User Datagram (UDP). Comme ce protocole ne nécessite pas d’authentification au préalable, il peut
représenter une faille de sécurité comme nous le verrons dans
la suite.
On constate que les paquets de commande envoyés par le
pilote à son drone sont assez reconnaissables, tant via le filtre ”ar drone” de wireshark que par leur taille (154 ou 155
octets) et leur contenu. Procédons à l’analyse du paquet
n6094.
Il correspond à une commande de virage à gauche envoyée
par le pilote(1). Il est possible de lire la télémétrie du drone :
virage (roll), altitude (pitch), accélération (gaz), yaw ????.
Il est donc possible d’espionner les mouvements d’un AR
Drone.
l’analyse de ports du
Commentaires
/Data/Video/
Access ROOT
streaming de la video
Système de Communication
Une fois allumé, l’AR.Drone 2.0 met en place un point d’accès
non-sécurisé appelé ardrone2-XXXXXX où XXXXXX est
une séquence de numéros apparemment aléatoires. Dans
notre cas, il s’agit de la suite 090933. Une fois connecté à
ce réseau, il est possible de faire un scan de ports ciblant
l’adresse IP du drone (192.168.1.1) en utilisant l’application
NMAP. Le résultat de ce scan nous montre les ports ouverts
:
Il est très important de remarquer que les services FTP et
TELNET ne sont pas sécurisés (protégés par mot de passe).
En conséquence, on peut communiquer avec le drone de
manière frauduleuse à travers ces ports. Par exemple, on
peut se promener dans l’architecture des fichiers du drone
en utilisant simplement telnet ou lui envoyer des fichiers par
FTP. Ces manipulations sont d’autant plus faciles que les
portes (ou plutôt les ports) ont été laissées grandes ouvertes.
Il ne s’agit pas là d’une sécurité faible mais d’une absence
de sécurité.
1.3
Système Interne
Le système d’exploitation du drone est de type UNIX.
Dans le répertoire /bin se trouve la plupart des scripts permettant de commander le drone. Par exemple, /bin/check update.sh
est le script gérant la liste des scripts à lancer au démarrage
du drone et /bin/Wifi setup.sh permet de démarrer les connexions Wifi. Le fichier de configuration principal se trouve
dans le répertoire /data : config.ini. Il faut souligner que,
puisque le port 23 est ouvert, on peut accéder à tous ces
scripts, les modifier, les exécuter, voire les supprimer par
une simple connexion en telnet. En effet, la connexion se
fait par défaut en root et nous donne donc tous les droits
sur les fichiers.
Le flux vidéo peut être récupéré dans le répertoire /data/video.
Il est possible de récupérer ce flux en différé en branchant
une clé USB sur le drone. Celle-ci se monte automatiquement dans le répertoire /data/video/usb.
Le programme chargé de gérer à proprement parler le pilotage du drone est program.elf. C’est ce fichier qui transforme les commandes envoyées par le pilote en suite d’actions
à effectuer par le drone.
2.
DÉVELOPPEMENT (MAIN BODY)
Nous avons entrepris de mettre en pratique deux scénarii
d’attaque du drone parmi toutes ceux possibles. Dans les
deux cas, il s’agit d’une attaque de type Directory Traversal.
2.1
Attaque de type Directory Traversal
Les attaques de type Directory Traversal Attack consistent
à exploiter, non pas directement une faille de sécurité mais
plutôt une faiblesse de la sécurité pour accéder à des fichiers
qui ne devraient pas pouvoir être accessibles. Un exemple typique pour les applications internet est l’accés à des
Figure 3: Exemple de trame wireshark entre le drone et le pilote
pages réservées à l’administrateur par simple connaissance
de l’URL.
2.2
Réinitialisation du drone
Le processus program.elf est le processus chargé de commander le drone. En conséquence, terminer ce processus a donc
pour effet de ”tuer” le pilotage du drone. Ceci se traduit
par une réinitialisation des programmes du drone. Si celuici était en train de voler, la perte des commandes provoque
sa chute. Par sécurité et pour éviter de risquer d’abı̂mer le
drone, il vaut donc mieux éviter de procéder à cette attaque
lorsque le drone est en l’air. De plus, une fois réinitialisé,
le drone cherche à retourner à son état antérieur. Ainsi, s’il
était dans les airs, il y retournera. Ceci se traduit par un
décollage pouvant surprendre le pilote s’approchant de son
drone pour voir la raison de sa chute brutale. Qu’il soit au
sol ou dans les airs, les diodes sous les hélices sont un témoin visuel de l’état du drone : si elles sont vertes, le drone
est pilotable ; si elles sont rouges, une réinitialisation est en
cours.
Nous avons réalisé un script qui provoque une réinitialisation
brutale du drone à intervalles réguliers, par exemple tous les
$delay=20 secondes. Il s’agit du script CSR resetAttack.sh.
Celui-ci cherche toutes les $delay le PID du processus program.elf et le force à se terminer.
Pour réaliser cette attaque, il faut procéder de la manière
suivante :
• Lancer l’exécution du script via le protocole telnet.
On observe alors que les diodes placées sous les hélices passent
du vert au rouge toutes les $delay. C’est le signe de la réinitialisation périodique de program.elf.
2.3
Déconnection du client propriétaire
La seconde attaque que nous avons expérimentée est une
attaque de désauthentification du client. Cela consiste à
déconnecter le pilote légitime de son drone et d’en prendre
le contrôle. Cette attaque diffère de la précédente sur deux
points :
• Le pilote perd totalement le contrôle de son drone.
Dans la première attaque, il pouvait toujours le diriger
entre deux réinitialisations. Autrement dit, la connexion Wifi n’était pas coupée.
• A l’inverse, nous pouvons maintenant avoir le contrôle
total du drone et lui envoyer nos propres commandes
de vol.
Le script que nous avons écrit et qui permet cette attaque
est CSR DroneHacker.sh fourni dans l’archive. L’attaque se
conduit de la manière suivante :
• Envoyer le script au drone via le protocole FTP (commande ”PUT”). Le fichier se retrouve dans le répertoire /data/video.
• On cherche, parmi les réseaux Wifi autour de nous,
un Access Point dont l’adresse MAC est de la forme
90:03:b7:*:*:*. Il faut savoir que les adresses MAC sont
en réalité composées de deux parties : les six premiers
octets sont caractéristiques de l’entreprise qui a fabriqué la machine (ici le drone) et les six derniers caractérisent la machine proprement dite. Une adresse
MAC de la forme 90:03:b7:*:*:* est donc caractéristique d’un drone construit par l’entreprise Parrot.
• Se donner les droits d’exécution sur ce script (commande ”chmod”).
• Le script iwScanParser.sh permet de parser ces résultats.
• Se connecter au réseau Wifi non-sécurisé généré par le
drone.
• Une fois celui-ci trouvé, on retient l’adresse MAC complète et le canal RF.
https://projects.ardrone.org/
• On envoie au drone le script de désauthentification de
la même manière que pour l’attaque précédente.
[4] SHACHTMAN, ”Computer Virus hits U.S. Drone Fleet”
Nous recevons alors les données de télémétrie et le flux vidéo
du drone.
Normalement, nous devrions également pouvoir envoyer des
commandes de vol au drone, que ce soit via un script python
(qui contient un scénario de vol complet) ou via un clavier
ou une manette de console. Nous n’avons pas pu faire cela,
nos différents périphériques n’étant malheureusement pas reconnus par le drone. La seule commande que nous avons pu
envoyée est le changement de couleur des leds. Cela permet
néanmoins de montrer que les échanges après cette attaque
fonctionnent dans les deux sens : du drone vers nous et de
nous vers le drone.
3.
CONCLUSIONS
La principale conclusion à tirer de ce travail est que le AR.Drone
2.0 de la société Parrot ne met en place aucune sécurité vis-àvis des intrusions informatiques et du code malicieux. En effet, comme nous venons de le montrer, il n’est pas nécessaire
de cracker des sécurités pour accéder aux fichiers du drone,
pour provoquer une réinitialisation de ses programmes ou
pour désauthentifier son pilote légitime. Nous nous sommes
contentés de passer par les ports 21 (FTP) et 23 (telnet en
mode root) du drone qui sont continuellement ouverts. La
seconde faiblesse est que le réseau wifi mis en place par le
drone n’est même pas protégé par un mot de passe.
Cependant, il ne faut pas croire que ceci soit une exception
dans l’industrie des drones et que Parrot a fait preuve d’un
laxisme étonnant contrairement à ses concurrents. En effet,
les drones de la marque Dji qui se situent dans la gamme de
prix supérieurs (à partir de 1000) souffrent des mêmes faiblesses. D’une manière plus anedoctique puisque les usages et
les sécurités sont totalement différents, des drones militaires
américains (Predator et Reaper) ont déjà été avec succés la
cible de virus informatiques.
APPENDIX
A. HEADINGS IN APPENDICES
A.1 References
[1] PLEBAN, BAND, CREUTZBURG, ”Hacking and securing the AR.Drone 2.0 quadcopter - Investigations for improving the security of a toy”.
http://proceedings.spiedigitallibrary.org/
proceeding.aspx?articleid=1833079
[2] KAMKAR, ”SkyJack”.
http://samy.pl/skyjack/
[3] Project AR.Drone,
http://www.cs.clemson.edu/course/cpsc420/material/Papers
/Computer%20Virus%20Hits%20US%20Drone%20Fleet.pdf"
[5] AR.Drone 2.0, ”State of the art technology”
http://ardrone2.parrot.com/ardrone-2/specifications/
Figure 4: Données de télémétrie et flux vidéo reçus après une attaque de désauthentification