Comment un hacker peut pirater votre drone !
1/ Introduction
Nous avons choisi de nous intéresser à la sécurité des drones disponibles pour les particuliers avec des prix allant de 100 à 200 euros.
Ces drones présentent tous des fonctionnalités équivalentes comme un flux vidéo en direct et peuvent être contrôlés depuis une application de smartphone ou une télécommande basse fréquence (2.4Ghz). Dans cet article nous avons volontairement mis de côté la télécommande radio et nous nous sommes focalisés sur l’application de smartphone.
Un article écrit par Benoit Decampenaire et Jean-Baptiste Caron
2/ Découverte technique
Nous avons commencé à analyser le fonctionnement de ceux-ci et voici ce qu’on a pu noter:
- L’ensemble des drones que nous avons testés sont des points d’accès wifi (AP).
- Pour les contrôler il faut d’abord s’appairer avec le drone.
- L’appairage wifi ne requiert pas de mot passe.
- Certains drones exposent des services tel que Telnet et FTP.
Le drone à tendance à utiliser sa batterie très rapidement ce qui nous a poussés à le raccorder à une batterie beaucoup plus puissante afin de ne pas être interrompus toutes les 10 minutes.
3/ Analyse des communications
La méthodologie d’attaque a été la même pour tous les drones:
Puisqu’il est possible de se connecter à l’AP sans authentification, il nous a été possible de rejoindre le réseau avec un ordinateur.
Nous nous sommes placés en Man in the Middle (MitM) entre le drone et le smartphone afin d’analyser le trafic réseau avec Wireshark.
L’objectif du MitM est d’intercepter les communications entre notre téléphone qui discute au travers de l’application et le drone.
Pour cela, on va utiliser la technique d’ARP spoofing où l’on va indiquer à travers des requêtes ARP au drone que nous sommes le smartphone et au smartphone que nous sommes le drone.
Nous sommes donc en mesure d’analyser toutes les communications entre l’application et le drone.
Voici un schéma pour représenter notre attaque :
Nous avons remarqué des similitudes dans le fonctionnement des différents drones.
- L’application commence par demander le flux vidéo au drone avec un ou plusieurs paquets qui diffèrent entre les marques et modelés de drone. Le drone commence ensuite à émettre le flux vidéo sur un autre port. Certaines applications utilisent aussi des paquets de keep alive et un autre paquet pour arrêter le flux.
- Quand on utilise l’application mobile on remarque principalement deux types de paquets. Des paquets de commande qui servent à exécuter des fonctions comme le décollage, l’atterrissage et des paquets de contrôle qui servent à diriger le drone en jouant sur la puissance des moteurs. Les paquets de commande respectent en général la forme suivante :
| Rôle | Commande (1 octet) | Déplacement (4 octets) | CRC (1 octet) |
|---|---|---|---|
| Décollage | 01 | 80 80 80 80 | 01 |
| Atterrissage | 00 | 80 80 80 80 | 00 |
Le CRC (Cyclic Redundancy Check) ici est un simple XOR de certains des octets du paquet. Il permet d’assurer l’intégrité (ou pas) du paquet.
Les octets de déplacement sont ici inutilisés et sont donc à leur valeur par défaut (0x100/2 = 0x80 ou parfois 0x7f).
0x80 représente la position par défaut et n’entraîne pas de modification de la vitesse des moteurs. En modifiant la valeur des différents octets on modifie la puissance de certains moteurs ce qui entraîne un mouvement du drone.
Nous avons identifié la position des octets responsables du déplacement du drone dans les paquets de contrôle.
| Offset | 1 | 2 | 3 | 4 |
|---|---|---|---|---|
| Effect | déplacement gauche/droite | monter/descendre | avancer/reculer | rotation gauche droite |
Dans les paquets de contrôle l’octet de commande à toujours la même valeur qui dépend du modelé. Le ou les bytes correspondant au mouvement sont modifiés et le CRC est calculé accordement.
Par exemple :
| Rôle | Commande (1 octet) | Déplacement (4 octets) | CRC (1 octet) |
|---|---|---|---|
| Rotation vers la droite | 03 | 80 80 80 90 | 13 |
| Avancer en montant | 03 | 80 95 87 80 | 11 |
4/ Prise de contrôle
Sans être en MitM il est possible:
- de se connecter à l’AP du drone
- de lui envoyer des paquets de contrôle même s’il est déjà contrôlé par l’application
- de lui demander le flux vidéo même si le flux vidéo est déjà transmis à l’application.
- de désauthentifier le smartphone du drone afin d’être le seul en mesure de le contrôler.
Nous avons décidé d’écrire un script pour contrôler le drone avec une manette de XBOX 360. Nous avons rencontré certaines difficultés avec des librairies python. En effet nous voulions être en mesure de contrôler finement les moteurs et nous avions aussi besoin de savoir si le joystick regagnait sa position neutre. (Ce script est inclus dans l’article).
Nous avons choisi pygame car les autres librairies que nous avons testées ne remplissaient pas ces conditions.
Nous sommes parvenus à prendre le contrôle du drone pendant qu’il était contrôlé depuis l’application.
Pour la partie flux vidéo nous sommes parvenus à demander le flux et à le recevoir mais nous avons eu de nombreux problèmes de qualité vidéo et de fluidité qui sont probablement dus à une compréhension imparfaite de notre part.
Notre démarche était la suivante :
- Envoyer le paquet de demande du flux vidéo
- Récupérer les paquets UDP du flux vidéo (sur un autre port)
- Envoyer la donnée contenue dans les paquets vers VLC.
Nous avons déterminé que certains paquets ne contiennent pas de données vidéo et nous les avons filtrés afin de ne pas les transmettre à VLC. Cependant la qualité des images restait un problème et nous avons trouvé un outil : pylwdrone (https://github.com/meekworth/pylwdrone). Il permet de communiquer avec les caméras lewei des drones et nous a permis d’avoir une image de meilleure qualité.
La démonstration est terminée ! Que pensez-vous de la sécurité des produits grand public comme les drônes ? Des expériences à partager ?
