Vulnérabilité des drones DJI – Recherche Checkpoint

Vulnérabilité des drones DJI – Recherche Checkpoint

25 juin 2020 Non Par Chris Gratt



8 novembre 2018

Recherche: Oded Vanunu, Dikla Barda et Roman Zaikin

DJI est un leader mondial dans l’industrie des drones civils et de l’imagerie aérienne.

En plus des consommateurs, il a également pris une part importante du marché des entreprises, les clients provenant des infrastructures critiques, de la fabrication, de l’agriculture, de la construction, du secteur de la gestion des urgences et plus encore. Avec autant de clients dans le monde, à la fois grand public et entreprises, les drones DJI peuvent obtenir des données et des images à partir d’un large éventail de perspectives et d’un large éventail de sujets.

Dans une enquête récente, Check Point Research a découvert une vulnérabilité qui, si elle était exploitée, permettrait à un attaquant d’accéder au compte DJI d’un utilisateur sans que l’utilisateur en soit conscient. Cela pourrait donner accès à:

  • Journaux de vol, photos et vidéos générés lors du vol des drones, si l’utilisateur DJI les a synchronisés avec les serveurs cloud DJI. (Les journaux de vol indiquent l’emplacement exact du drone tout au long de son vol, ainsi que des critiques de photos et de vidéos prises pendant le vol.)
  • Affichage en direct et affichage de la carte en vol des drones si un utilisateur DJI a utilisé le logiciel de gestion de vol FlightHub de DJI.
  • Informations de compte DJI, y compris les informations de profil utilisateur.

Cette vulnérabilité a été consultée via le DJI Forum, un forum en ligne où DJI discute de ses produits. Un utilisateur qui s’est connecté au forum DJI puis a cliqué sur un lien malveillant spécialement implanté peut avoir volé des informations de connexion pour permettre l’accès à d’autres ressources du réseau DJI:

  • Plateforme web de DJI (compte, boutique, forum)
  • Les données du serveur cloud sont synchronisées avec les applications pilotes GO ou GO 4 DJI
  • FlightHub de DJI (plateforme de gestion centralisée des drones)

Nous avons notifié DJI de cette vulnérabilité en mars 2018, et DJI a répondu de manière responsable. La vulnérabilité a depuis été corrigée. Le DJI a classé cette vulnérabilité comme à haut risque mais peu probable, et a indiqué qu’il n’y avait aucune preuve que cette vulnérabilité avait été exploitée par quelqu’un d’autre que les chercheurs de Check Point.

Diagramme: Vue simplifiée de trois attaques potentielles.

Vidéo de démonstration de l’attaque
(Remarque: les captures d’écran et les images de la trajectoire de vol vues dans cette vidéo ou diagramme ci-dessus ont été prises grâce à Airdat, qui n’a pas été impliqué dans cette recherche et n’a pas été affecté par cette vulnérabilité.)

Analyse technique

Nos recherches ci-dessous expliquent comment nous avons pu accéder aux informations de vol sensibles des drones DJI, ainsi qu’aux données utilisateur sensibles, sur les trois plateformes DJI Web, Mobile App et FlightHub.

Nous allons d’abord expliquer où se trouve la vulnérabilité et comment elle fonctionne.

Vulnérabilité

En bref, la vulnérabilité est présente dans le processus d’identification DJI.

DJI utilise un cookie qu’un attaquant peut obtenir pour identifier un utilisateur et créer des jetons ou des cartes pour accéder à ses plateformes. En utilisant ce cookie, un attaquant peut facilement détourner le compte de n’importe quel utilisateur et prendre le contrôle complet des applications mobiles DJI, du compte Web ou du compte DJI FlightHub de tout utilisateur.

Nous avons commencé la recherche en recherchant le processus de connexion sur le site Web de DJI parce que nous voulions d’abord comprendre comment l’utilisateur est reconnu par le backend DJI et quels paramètres ou cookies sont importants pour le processus de connexion. Nous avons donc regardé tout le trafic passant par le client (navigateur) et le backer DJI.

Nous avons rapidement remarqué que DJI utilise plusieurs sous-domaines pour les services qu’il propose:

  • forum.dji.com
  • account.dji.com
  • store.dji.com

De plus, la connexion entre ces domaines utilise le framework OAuth. En conséquence, nous avons commencé à examiner le trafic sur ces sous-domaines.

D’après notre analyse, nous avons constaté que l’exigence de mobile.php L’URL nous a donné des informations sensibles sur notre utilisateur de test DJI qui contiennent des informations telles que Nom d’utilisateur. member_uid. signe et beaucoup plus.

C’était intéressant car cela nous a fait rechercher comment le contributeur DJI a identifié notre utilisateur et s’il utilise le même identifiant. Nous avons donc examiné les cookies utilisés là-bas et avons constaté qu’un cookie, appelé «méta-clé», était responsable de l’identification de l’utilisateur.

Personnage 1: Demander mobile.php

Puisque notre objectif était maintenant d’obtenir ce cookie de méta-clé de toute manière possible, nous avons dû trouver un sous-domaine qui n’est pas protégé par l’attribut http uniquement, et qui empêcherait JavaScript de fuir le cookie.

Le sous-domaine qui répondait à nos besoins était forum.dji.com, nous avons donc commencé à rechercher des vulnérabilités sur cette plate-forme.

Détection de vulnérabilité

Après une courte recherche, nous sommes tombés sur la demande GET suivante: https://forum.dji.com/forum.php?mod=ajax&action=downremoteimg&message=

Ici, nous avons vu que le paramètre de message se reflète dans la réponse. Mais il y avait deux obstacles:

  1. Il y avait une fonction “barre oblique” qui ajoute une ligne aux caractères suivants “” /
  2. L’injection de charge utile XSS s’est produite dans une fonction non définie appelée “updateDownImageList “ qui a été importé d’un autre code JavaScript que nous n’avions pas dans notre contexte.

Nous avons supposé que la réponse à notre demande GET ressemblait au pseudo-code suivant:

Donc, pour commencer avec la fonction d’échappement, nous avons commencé avec une barre oblique et une citation comme ceci:

parent.updateDownImageList („ );

Ensuite, “additions” ajouterait également des lignes inversées, ce qui fuirait notre ligne et la changerait en une chaîne comme celle-ci:

parent.updateDownImageList („ \ ‘ );

Alors maintenant, nous devions nous occuper des personnages restants ‘); et la fonction “updateDownImageList” non identifiée.

Pour résoudre les caractères restants, nous avons ajouté un simple commentaire html comme celui-ci

parent.updateDownImageList („ );

Il ne nous reste plus qu’à gérer une fonction non identifiée. Pour surmonter le fait que cette fonction n’est pas définie, nous avons dû la définir nous-mêmes.

Donc, notre charge utile a fini comme ceci:

‘Avertissement (document.cookie); function updateDownImageList (data) {}

Personnage 3: Cookies que nous avons reçus en utilisant notre charge utile.

Un attaquant pourrait alors créer une charge utile que ce cookie de méta-clé enverra à son site. Ce type de XSS ne bloquerait aucun vérificateur XSS car il est en JavaScript lui-même et ne se compose pas de scripts ou d’événements.

Pour exécuter cette attaque XSS, tout attaquant doit écrire un simple post sur le forum DJI qui contiendra un lien vers la charge utile. Après tout, DJI restreint les liens vers le contenu qui se trouve sur le forum lui-même, il est donc impossible d’envoyer un lien vers un site Web malveillant de cette manière.

Figure 4: Un exemple de page malveillante qui renvoie vers le message d’un attaquant potentiel sur un forum DJI.

Comme notre XSS est situé sur le forum lui-même, nous avons pu contourner la restriction de connexion. De plus, comme des centaines de milliers d’utilisateurs communiquent avec le forum DJI, un attaquant ne devrait même pas partager un lien malveillant car les utilisateurs eux-mêmes le feront lorsqu’ils transmettront le message et le lien.

Après avoir obtenu la méta-clé, nous avons examiné le processus de demande et testé comment le backer DJI traite l’application sur chaque plate-forme DJI, en commençant par le site Web de DJI.

Site DJI

Pour avoir accès à n’importe quel compte d’utilisateur sur le site Web de DJI, tout ce dont nous avions besoin était leur méta-clé, qui est appelée “mck” sur le sous-domaine. account.dji.com.

Nous avons commencé par créer un compte DJI et nous y connecter. En analysant le processus de connexion, nous avons constaté qu’il utilise OAuth pour authentifier les utilisateurs entre les sous-domaines, par exemple entre accounts.dji.com à forum.dji.com et retour à dji.com.

Ainsi, chaque fois que DJI veut authentifier l’utilisateur, il envoie initData.do avec le gâteau “mck”, et la réponse sera l’URL de rappel avec le ticket.

En naviguant vers l’URL, l’utilisateur sera vérifié sans informations d’identification de cette manière.

Donc, pour voler le compte, nous avons dû:

  1. Connectez-vous en tant qu’attaquant sur dji.com, puis cliquez sur DJI.COM qui nous redirigera vers dji.com.
  2. Dans la demande initData.do, remplacez la valeur du cookie “mck” par la victime “mck” (que nous avons obtenue de la vulnérabilité XSS).
  3. Continuez le processus de demande et accédez au compte de la victime.

Vous trouverez ci-dessous la demande initData.do:

Figure 5: InitData.do Request

DJI App

Afin de créer un compte dans l’application mobile DJI, nous avons dû contourner certaines des atténuations qui s’appliquent dans l’application elle-même.

Nous avons dû intercepter les demandes allant de l’application au backkend DJI pour enquêter sur le processus de demande. Mais ici, nous sommes tombés sur un mécanisme d’épinglage SSL, qui nous empêchait d’intercepter le trafic des applications et de l’explorer.

Nous avons donc essayé de décompiler l’application pour comprendre comment contourner le mécanisme d’épinglage SSL. Malheureusement, la décomplication a échoué car l’application mobile de DJI est utilisée SecNeo (Protection des applications mobiles).

Selon SecNeu, les protections suivantes sont fournies:

  • Prévention du code source en amont et protection des données sensibles.
  • Appliquez des ajustements non autorisés, supprimez les rondelles et déboguez avec les fonctionnalités de fusion.
  • Empêcher l’injection de code dynamique et la décompilation / désassemblage.

En conséquence, nous avons essayé de contourner ces limitations en utilisant Frida. Nous avons en fait essayé de nous connecter à l’application dji.go.v4, mais sans succès.

Nous vérifions ensuite pourquoi nous n’avons pas pu nous connecter au processus dji.go.v4 et commençons par la commande: ‘frida-ps –U’ pour obtenir une liste de tous les processus en cours d’exécution sur notre appareil mobile.

En exécutant cette commande, nous avons remarqué qu’il n’y a qu’une seule procédure dji.go.v4. Cependant, après quelques secondes, nous avons vu une autre procédure dji.go.v4.

En regardant / proc / 11194 / status, nous pouvons voir que le nouveau processus de naissance est lié au premier processus et au débogage. C’est pourquoi nous n’avons pas pu corriger l’erreur dans le processus avec Frida – elle est déjà corrigée.

Figure 6: Un processus nouvellement répété attaché au premier processus dji.go.v4 comme vu dans Frida.

Nous avons constaté que le premier processus démarré n’était pas le débogage, mais l’application réelle. Le débogueur a en fait rejoint l’application réelle et a commencé à la protéger. Cela signifiait qu’il y avait une exigence de race que nous pouvions utiliser et fixer nos crochets dans le processus d’application et les détacher avant le processus de débogage.

Pour contourner ce problème, nous avons copié le certificat Burp Suit sur notre téléphone portable et avons donné naissance à l’application DJI nous-mêmes. Cela a démarré l’application en mode suspendu (avant l’initialisation du débogueur).

Ensuite, nous avons créé un script Frida qui a utilisé la logique suivante:

  1. Ouvrez notre certificat Burp Suit et passez-le à X509Certificate.
  2. Insérez le KeyStore et placez le certificat à l’intérieur.
  3. Créez un TrustManagerFactory et initialisez-le avec le KeyStore que nous venons de créer et qui contient notre certificat Burp Suit.
  4. Surchargez SSLContext et épinglez TrustManager avec notre TrustManager.

Une fois le crochet terminé, nous avons repris l’application suspendue et nous en sommes séparés. Maintenant, le redresseur pouvait déclencher la protection après que nous ayons fini avec tous nos crochets.

De cette façon, nous avons contourné l’épinglage SSL et le trafic est ensuite apparu dans notre suite Burp.

Figure 7: Trafic tel que vu dans Burp Suit après contournement des broches SSL.

Après avoir contourné les broches SSL, nous avons mis en place un proxy qui nous a permis d’intercepter le trafic des applications mobiles.

En analysant le processus de demande de l’application Web, nous avons constaté qu’après que l’utilisateur a inséré ses informations d’identification, l’application mobile envoie une demande à / apis / apprest / v1 / email_login. La réponse reçue ressemble à ceci:

{“Code”: 0, “Message”: “OK”, “Données”: {“NICK_NAME”: “XXXXXXXXX”, “Cookie_name”: “_ Meta_key”, “cookie_key“”NTUxNjM2ZTXXXXXXXXXXXXXXNmI2NjhmYTQ5NGMz“” Actif “: faux,” e “:”[email protected]””signe“”XXXXXXXXX2139“” Validité “: 15275XXXXX” user_id “:” 9629807625XXXXXX “,” register_phone “:” “,” AREA_CODE “:” “,” inner_email “: Faux” abonnement “: Fake” vipLevel “: null,” vipInfos “::[]}}

Deux paramètres importants à noter ici sont:

  • “Cookie_key” – C’est le méta-bouton / mck que nous connaissons déjà sur le forum DJI.
  • “Token” – ce paramètre peut être obtenu auprès de demande mobile.php que nous avons décrit au début de cette publication de recherche.

Processus de piratage de compte

La procédure de piratage de compte est la suivante:

  1. L’attaquant a d’abord besoin d’une méta-clé et d’un jeton pour remplacer la sienne. Il envoie donc la méta-clé qu’il veut pirater à mobile.php et reçoit le jeton correspondant.
  2. L’attaquant entre alors ses informations d’identification et une demande d’enregistrement est envoyée.
  3. Après avoir reçu la réponse de l’étape 2, l’attaquant remplace la valeur cookie_key par la méta-clé victime et son jeton par le jeton de l’étape 1.
  4. L’attaquant a désormais un accès complet au compte de la victime.

En exploitant la vulnérabilité DJI, comme décrit ci-dessus, un attaquant peut prendre le compte de la victime et accéder à tous ses vols enregistrés synchronisés, à des photos de drones, etc.

Nous avons également mené d’autres recherches et constaté qu’en analysant les fichiers journaux de vol, nous pouvons obtenir beaucoup plus d’informations comme l’emplacement et l’angle de chaque image prise pendant le vol du drone, l’emplacement d’origine des drones, le dernier emplacement connu et plus encore.

Pour accéder aux fichiers du journal de vol, tout attaquant doit synchroniser les journaux de vol avec son téléphone, et tous les journaux de vol entrés manuellement dans les serveurs cloud DJI seraient stockés localement sur son téléphone. Il peut alors simplement parcourir le dossier «DJI / dji.go.v4 / FlightRecord» et trouver tous les fichiers de vol, les télécharger sur le site Web et afficher une grande quantité de données de vol des utilisateurs.

(Remarque: des images des pistes ci-dessus et des images ont été prises grâce à Airdat, qui n’a pas participé à cette recherche et n’a pas été affecté par cette vulnérabilité.)

DJI-FlightHub

DJI-FlightHub est une application Web développée pour fournir aux utilisateurs d’entreprise une image visuelle complète et le contrôle de leurs drones. En fait, il permet aux utilisateurs de regarder leurs drones en temps réel de n’importe où dans le monde, y compris une vue cartographique, une vue en direct de la caméra avec la possibilité d’entendre le son et permet aux utilisateurs de voir l’emplacement exact de chacun de leurs drones afin de coordonner les missions.

DJI-FlightHub a une application de bureau pour accéder au panneau de contrôle, une application pilote pour les drones volants et, heureusement pour nous, un portail web pour accéder au contrôle de contrôle. Vous pouvez trouver le portail Web à l’URL suivante: www.dji-flighthub.com.

Dans DJI-FlightHub, il y a un administrateur, un capitaine et un pilote. Les administrateurs sont en charge du compte DJI-FlightHub et accèdent à la plateforme DJI-FlightHub, examinent les données de vol et créent de nouveaux capitaines ou pilotes. Les capitaines peuvent également se connecter à la plateforme DJI-FlightHub et créer de nouveaux pilotes. Les pilotes sont ceux qui pilotent le drone avec des applications pilotes et lient le drone au compte DJI-FlightHub.

Dans cet esprit, si nous pouvions accéder à un administrateur ou à un compte de capitaine, nous pourrions voir les opérations de drones en temps réel. Afin de détourner un compte administrateur ou capitaine DJI, nous avons dû comprendre le processus de connexion DJI-FlightHub.

Figure 8: Page de connexion DJI-FlightHub.

Nous avons constaté que lorsque vous cliquez sur “se connecter” initData.do la demande est envoyée, mais en réponse le ticket n’est pas accepté (similaire à ce que nous avons reçu sur le portail account.dji.com). Au lieu de cela, nous avons reçu le ticket en réponse login.do uniquement lorsque l’utilisateur entre ses informations d’identification. Comme ce n’est pas la même chose que l’habituel account.dji.com que nous utilisions pour détourner un compte via le portail Web, nous avons dû trouver une autre façon de détourner un compte dans DJI FlightHub.

Bien que nous savions qu’un ticket pouvait être généré à la demande de initData.do, pour une raison quelconque, ce n’était pas le cas chez DJI-FlightHub. Par conséquent, nous avons examiné la demande pour comprendre pourquoi et nous avons remarqué que dans DJI-FlightHub initData.do, la demande avait une application DJI-FlightHub, c’est pourquoi nous n’avons pas reçu de ticket en réponse. Dans cet esprit, nous avons pensé que nous pourrions être en mesure de remplacer l’application par quelque chose que nous savions pourrait fonctionner pour obtenir la carte. Une fois le billet obtenu, il ne nous restait plus qu’à vérifier s’ils achèteraient également un autre billet ici.

Ensuite, les étapes nécessaires étaient:

  1. Envoyez la demande initdata.do appId = store avec mck admin qui vise à détourner et obtenir la carte en réponse.
  2. Lorsque vous vous connectez à FlightHub, interceptez la demande, modifiez le mck dans la demande login.do et dans le commutateur de réponse sur la carte correspondante reçue dans la demande inidata.do. L’attaquant sera ensuite redirigé vers le compte administrateur / victime.

De plus, l’administrateur ne recevra aucune notification indiquant que l’attaquant a accédé à son compte. Pendant ce temps, l’attaquant aurait complètement désactivé l’accès à la connexion et inspecté le drone pendant les opérations en direct de tout vol en cours ou télécharger des enregistrements de vols précédemment enregistrés téléchargés sur la plateforme FlightHub.