Tempête à l'horizon : L'écosystème AJCloud IoT

Introduction

Les caméras Wi-Fi font partie des dispositifs IdO les plus courants dans les foyers, les entreprises et les autres espaces publics. Ils sont généralement assez abordables et permettent aux utilisateurs d'accéder facilement à un flux vidéo en direct sur leur appareil mobile, où qu'ils se trouvent sur la planète. Comme c'est souvent le cas avec les appareils IoT, la sécurité a tendance à être négligée dans ces caméras, ce qui les expose à des vulnérabilités critiques. Si elles sont exploitées, ces vulnérabilités peuvent avoir des effets dévastateurs sur les caméras et les réseaux au sein desquels elles sont déployées. Ils peuvent conduire à la compromission des informations confidentielles de leurs utilisateurs.

Une récente semaine Elastic ON nous a donné l'occasion d'explorer la surface d'attaque de ces types d'appareils afin de mieux comprendre comment ils sont compromis. Nous nous sommes principalement concentrés sur la recherche de vulnérabilités sur le Wansview Q5 (ainsi que sur le Q6, presque identique), l'un des appareils photo les plus populaires et les plus abordables vendus sur Amazon. Wansview est un fournisseur de produits de sécurité basé à Shenzhen, en Chine, et l'un des principaux distributeurs de caméras Wi-Fi d'Amazon.

Le Q5 offre les mêmes fonctions de base que la plupart des appareils photo :

Pan / tilt / zoom
Vision nocturne
Audio bidirectionnel
Enregistrement vidéo sur carte SD
Intégration avec les assistants IA de la maison intelligente (par ex. Alexa)
ONVIF pour l'interopérabilité avec d'autres produits de sécurité
RTSP pour un accès direct au flux vidéo au sein du réseau local
Mises à jour automatisées du micrologiciel à partir du nuage
Assistance technique à distance
Accès partagé à l'appareil avec d'autres comptes
Abonnement mensuel facultatif pour le stockage dans le nuage et la détection de mouvement

Comme la plupart des autres caméras Wi-Fi, ces modèles nécessitent une connexion active à l'infrastructure en nuage de leur fournisseur pour un fonctionnement de base ; sans accès à Internet, ils ne fonctionnent tout simplement pas. Avant qu'une caméra puisse être mise en service, elle doit être associée à un compte utilisateur enregistré via l'application mobile officielle de Wansview et un processus d'installation standard basé sur un code QR. Une fois ce processus terminé, la caméra sera entièrement en ligne et opérationnelle.

AJCloud : Une brève introduction

Bien que Wansview soit en activité depuis 2009, il semble pour l'instant qu'il s'agisse principalement d'un revendeur d'appareils photo fabriqués par une autre société basée à Nanjing, en Chine : AJCloud.

AJCloud permet aux vendeurs d'accéder aux dispositifs de sécurité fabriqués, aux microprogrammes nécessaires, aux applications utilisateur mobiles et de bureau, à la plateforme de gestion en nuage et aux services qui relient le tout. Depuis la création d'AJCloud en 2018, l'entreprise s'est associée à plusieurs fournisseurs, petits et grands, dont voici quelques exemples :

Un examen rapide des applications mobiles et de bureau développées et publiées par AJCloud sur Google Play, l' App Store d'Apple et le Microsoft Store révèle leurs liens avec chacun de ces fournisseurs. Hormis la marque superficielle de l'entreprise, ces applications sont identiques dans leur forme et leur fonction, et elles nécessitent toutes une connectivité avec la plateforme de gestion AJCloud.

En ce qui concerne les caméras, il est évident que ces fournisseurs vendent des modèles similaires avec seulement des modifications mineures au niveau du boîtier de la caméra et du matériel sous-jacent.

La ressemblance entre le Faleemi 886 et le Wansview Q6 (1080p) est évidente.

La réutilisation des ressources de fabrication de matériel et de développement de logiciels permet probablement de contrôler les coûts et de simplifier la logistique pour AJCloud et ses revendeurs. Toutefois, cette rationalisation des actifs signifie également que les failles de sécurité découvertes dans un modèle d'appareil photo se répercuteront probablement sur tous les produits associés à AJCloud.

Malgré son rôle essentiel dans la mise à disposition de ces appareils aux consommateurs, AJCloud est relativement peu connu du public. Cependant, les chercheurs de l'IPVM ont récemment publié une recherche sur une vulnérabilité importante (qui a depuis été résolue) dans le dépôt GitLab d'AJCloud. Cette vulnérabilité permettrait à n'importe quel utilisateur d'accéder au code source, aux informations d'identification, aux certificats et à d'autres données sensibles sans nécessiter d'authentification.

Bien qu'il soit difficile d'obtenir des chiffres de vente totaux pour Wansview et d'autres fournisseurs de caméras Wi-Fi, IPVM a estimé qu'au moins un million d'appareils étaient connectés à la plateforme AJCloud au moment de la publication de son rapport. Les ventes d'appareils photo continuant de grimper en flèche pour atteindre des centaines de millions, on peut supposer que les appareils d'AJCloud seront de plus en plus nombreux à être connectés dans les foyers du monde entier au cours des années à venir.

Premiers efforts de recherche sur la vulnérabilité

Pour mieux comprendre le dispositif de sécurité du Wansview Q5, nous l'avons attaqué sous plusieurs angles :

Dans un premier temps, nos efforts se sont concentrés sur la reconnaissance active et passive du réseau de la caméra et de la version Android de Wansview Cloud, l'application mobile officielle de Wansview. Nous avons recherché les ports ouverts, écouté les communications réseau par le biais d'attaques de type "man-in-the-middle" (MitM), tenté de contraindre les caméras à adopter un comportement imprévisible par le biais d'une mauvaise configuration intentionnelle de l'application, et perturbé le fonctionnement des caméras en abusant du format du code QR et en interagissant physiquement avec la caméra. Les appareils et leur infrastructure étaient étonnamment résistants à ces types d'attaques superficielles, et nos premiers efforts n'ont donné lieu qu'à quelques succès notables.

Nous avons été particulièrement surpris de ne pas réussir à intercepter les communications réseau de la caméra et de l'application. Nous avons rencontré à plusieurs reprises des dispositifs de sécurité robustes (par exemple, l'épinglage de certificats, les restrictions de versions d'applications et de systèmes d'exploitation, et les connexions TLS correctement sécurisées) qui ont perturbé nos tentatives.

Les outils de rétro-ingénierie nous ont permis d'analyser l'APK de plus près, bien que la complexité de l'obscurcissement du code observée dans le code source Java décompilé nécessiterait beaucoup de temps pour être entièrement reconstituée.

Notre succès initial limité nous obligerait à explorer d'autres options qui nous permettraient d'avoir une vision plus nuancée du Q5 et de son fonctionnement.

Piratage initial du matériel

Pour mieux comprendre le fonctionnement de l'appareil photo, nous avons décidé d'examiner de plus près le micrologiciel de l'appareil. Bien que certains microprogrammes soient disponibles en ligne, nous voulions voir le code directement et pouvoir le contrôler ainsi que les journaux qui en résultent lorsque la caméra fonctionne. Pour ce faire, nous avons d'abord examiné le diagramme matériel du système sur puce (SoC) pour voir s'il y avait des pistes matérielles que nous pourrions exploiter. Le Wansview Q5 utilise un SoC Ingenic Xburst T31, dont le schéma fonctionnel est décrit ci-dessous.

Le bloc d'E/S SPI I2Cx3/UARTx2/SPIx2 nous a paru particulièrement intéressant. S'ils sont accessibles, ces blocs d'E/S fournissent souvent des interfaces de sortie de journal et/ou des interfaces shell, qui peuvent être utilisées pour le débogage et l'interaction avec le SoC. Comme cela semblait prometteur, nous avons ensuite effectué un démontage matériel de l'appareil photo et avons trouvé ce qui semblait être une interface série UART vers le SoC, illustrée ci-dessous.

Ensuite, nous avons connecté un analyseur logique pour voir quel protocole était utilisé sur ces broches et, après décodage, le signal était bien UART.

Maintenant que nous pouvons accéder à une interface UART exposée, nous avons cherché à établir une connexion shell avec le SoC via UART. Il existe un certain nombre de mécanismes logiciels différents pour ce faire, mais pour nos besoins, nous avons utilisé l'utilitaire Unix screen avec le débit en bauds détecté par l'analyseur logique.

Lors de l'ouverture et du contrôle de la séquence de démarrage, nous avons découvert que le démarrage sécurisé n'était pas activé bien qu'il soit pris en charge par le SoC. Nous avons ensuite modifié la configuration pour démarrer en mode mono-utilisateur, ce qui nous a permis de disposer d'un shell root pour examiner le firmware avant que les processus d'initialisation ne soient exécutés (voir ci-dessous).

Une fois en mode mono-utilisateur, nous avons pu extraire les fichiers du micrologiciel pour une analyse statique à l'aide de l'utilitaire binwalk, comme indiqué ci-dessous.

À ce stade, le système de fichiers est généralement en lecture seule ; cependant, nous voulions être en mesure d'effectuer des modifications et de n'instancier que des parties spécifiques de l'initialisation du micrologiciel en fonction des besoins, nous avons donc effectué quelques configurations rapides pour une persistance supplémentaire au-delà de l'accès en mode mono-utilisateur. Cela peut se faire de plusieurs manières, mais il y a deux méthodes principales que l'on peut souhaiter utiliser. D'une manière générale, dans les deux cas, il s'agit de modifier le moins possible la configuration existante. Cette méthode est généralement préférée lors de l'exécution d'une analyse dynamique, si possible, car elle a le moins d'impact possible sur l'environnement d'exécution. Une méthode que nous avons utilisée pour cette approche consiste à créer une partition tmpfs pour l'accès en lecture/écriture dans la mémoire et à la monter via fstab. Dans notre cas, le site fstab a déjà été envisagé de manière à soutenir cette démarche et, de ce fait, il s'agit d'un changement très minime. Vous trouverez ci-dessous les commandes et les résultats de cette approche.

Une autre méthode consiste à récupérer les informations d'identification de l'utilisateur existant et à tenter de les utiliser pour se connecter. Cette approche a également été couronnée de succès. Le hachage du mot de passe de l'utilisateur root peut être trouvé dans le fichier etc/passwd et décrypté à l'aide d'un outil comme John the Ripper. Dans les exemples ci-dessus, nous avons transféré des données et des fichiers entièrement via la connexion série. L'appareil photo dispose également d'un emplacement pour carte SD qui peut être monté et utilisé pour transférer des fichiers. À l'avenir, nous utiliserons la carte SD ou le réseau local pour déplacer les fichiers, car la bande passante permet un transfert plus rapide et plus facile ; cependant, le port série peut toujours être utilisé pour toutes les communications pour la configuration du matériel et le débogage, si vous le souhaitez.

Nous avons maintenant un accès de niveau racine à la caméra, ce qui nous permet d'accéder au micrologiciel et aux journaux dmesg lorsque le logiciel est en cours d'exécution. En utilisant le micrologiciel et les journaux comme référence, nous avons ensuite cherché à examiner plus avant les interfaces utilisateur de la caméra pour voir s'il y avait un bon point d'entrée que nous pourrions utiliser pour obtenir plus d'informations.

Wansview Cloud pour Windows

Après que les applications mobiles se sont avérées plus sûres que prévu, nous avons porté notre attention sur une ancienne version de l'application Wansview Cloud conçue pour Windows 7. Cette application, qui est toujours disponible au téléchargement, nous donnerait un aperçu direct des communications réseau impliquées avec les caméras connectées à la plateforme AJCloud.

Grâce en grande partie à l'enregistrement excessif des données de débogage de la part des développeurs, l'application Windows dévoile ses secrets avec une insouciance rarement vue dans les logiciels commerciaux. Le premier signe que les choses ne vont pas bien est que les identifiants de connexion des utilisateurs sont enregistrés en clair.

La rétro-ingénierie de l'exécutable principal et des DLL (qui ne sont pas emballés, contrairement à l'APK de Wansview Cloud) a été accélérée grâce à l'utilisation fréquente de messages de journal verbeux contenant des chaînes de caractères uniques. L'identification des références à des fichiers et des lignes spécifiques dans la base de code sous-jacente nous a permis d'identifier rapidement les principaux composants de l'application et d'établir le flux de contrôle de haut niveau.

Les communications réseau, que nous avons eu du mal à intercepter sur Android, sont toujours transmises via TLS, bien qu'elles soient commodément enregistrées en clair sur le disque. Avec un accès total à toutes les données de requête et de réponse HTTP POST (emballées dans des objets JSON), il n'était plus nécessaire de poursuivre les attaques MitM du côté de l'application.

Dans les réponses POST, nous avons trouvé des métadonnées sensibles, notamment des liens vers des captures d'écran accessibles au public, ainsi que des informations sur l'emplacement de la caméra, la configuration du réseau et la version du micrologiciel.

Après avoir documenté toutes les requêtes POST et les réponses trouvées dans les données du journal, nous avons commencé à expérimenter la manipulation de différents champs dans chaque requête afin d'essayer d'accéder à des données non associées à notre caméra ou à notre compte. Nous utiliserons éventuellement un débogueur pour changer le deviceId en celui d'une caméra cible qui n'est pas associée au compte actuellement connecté. L'identifiant d'un appareil photo fait office de numéro de série et se trouve imprimé sur une étiquette située à l'arrière ou sous l'appareil photo.

Nous avons trouvé la cible la plus appropriée pour notre attaque dans une section de code où le deviceId est transmis pour la première fois dans une requête POST à https://sdc-us.ajcloud.net/api/v1/dev-config:

Notre plan consistait à placer un point d'arrêt à l'instruction mise en évidence dans la capture d'écran ci-dessus, à échanger le deviceId dans la mémoire, puis à permettre à l'application de reprendre l'exécution.

Aussi étonnant que cela puisse paraître, cette approche naïve a non seulement permis de récupérer des données sensibles stockées dans la plateforme AJCloud associée à la caméra cible et au compte auquel elle est liée, mais elle nous a également permis de nous connecter à la caméra elle-même. Cela nous a permis d'accéder à ses flux vidéo et audio et de la contrôler à distance via l'application, comme s'il s'agissait de notre propre caméra.

En exploitant cette vulnérabilité et en la testant sur plusieurs modèles de différents fournisseurs, nous avons déterminé que tous les appareils connectés à la plateforme AJCloud pouvaient être accédés à distance et contrôlés de cette manière. Nous avons écrit un script d'exploitation PoC pour automatiser ce processus et démontrer efficacement la facilité avec laquelle cette vulnérabilité de contrôle d'accès au sein de l'infrastructure d'AJCloud peut être exploitée de manière triviale.

Explorer les communications en réseau

Bien que nous ayons pu créer et déclencher de manière fiable un exploit contre une vulnérabilité critique de la plateforme AJCloud, nous devrions creuser davantage pour mieux comprendre le fonctionnement interne des applications, du micrologiciel de la caméra et de l'infrastructure en nuage.

Au-delà des requêtes et réponses POST observées tout au long de la procédure de connexion, nous avons remarqué une pléthore de requêtes et réponses UDP provenant d'un large éventail d'adresses IP. Peu de données en clair ont pu être trouvées dans ces communications, et les numéros de port UDP ciblés pour les requêtes sortantes semblaient varier. Un examen plus approfondi a révélé que cette activité UDP indiquait la présence de PPPP, un protocole IoT peer-to-peer (P2P) qui a été analysé et démontré de manière approfondie par Paul Marrapesse lors de sa présentation à DEF CON 28. Nous conclurons plus tard que la manière dont nous avons exploité la vulnérabilité que nous avons découverte a été facilitée par des requêtes P2P modifiées, ce qui nous a amenés à explorer plus avant le rôle critique que le P2P joue dans la plateforme AJCloud.

L'objectif principal du P2P est de faciliter la communication entre les applications et les appareils IoT, quelles que soient les configurations de réseau concernées. Le P2P utilise principalement une approche basée sur la perforation de trous UDP pour créer des voies de communication temporaires qui permettent aux requêtes d'atteindre leur cible soit directement, soit par l'intermédiaire d'un serveur relais situé dans un environnement réseau plus accessible. L'ensemble des commandes P2P intégrées dans les applications AJCloud permet d'accéder aux flux vidéo et audio, ainsi qu'au microphone et aux fonctions panoramique/inclinaison/zoom.

Piratage avancé du matériel

Après avoir mieux compris les communications P2P, il était temps d'examiner de plus près la caméra elle-même au cours de ces conversations P2P, notamment en exécutant le logiciel de la caméra dans un débogueur. Pour commencer, nous avons configuré la caméra avec une sortie d'enregistrement en direct via la connexion série UART que nous avons établie précédemment, comme indiqué ci-dessous.

Cela nous a permis de voir en direct les messages des applications ainsi que toutes les sources de journalisation supplémentaires dont nous avions besoin. À partir de ces informations, nous avons identifié le binaire principal utilisé pour établir la communication entre la caméra et le nuage ainsi que pour fournir les interfaces permettant d'accéder à la caméra via le P2P.

Ce binaire est appelé localement initApp, et il s'exécute une fois que la caméra a été entièrement initialisée et que la séquence de démarrage est terminée. Dans ces conditions, nous avons entrepris d'exécuter ce binaire avec un débogueur afin de mieux évaluer les fonctions locales. En essayant de le faire, nous avons rencontré un chien de garde du noyau qui détectait quand initApp n'était pas en cours d'exécution et redémarrait de force la caméra s'il détectait un problème. Ce chien de garde vérifie les écritures sur /dev/watchdog et, si ces écritures cessent, déclenche une minuterie qui redémarre la caméra si les écritures ne reprennent pas. Cela rend le débogage plus difficile car lorsque l'on interrompt l'exécution de initApp, les écritures sur le chien de garde s'interrompent également. Vous trouverez ci-dessous un exemple de ce comportement d'arrêt :

Pour éviter cela, on peut simplement essayer d'écrire dans le chien de garde à chaque fois que initApp s'arrête pour empêcher le redémarrage. Cependant, une autre option plus propre consiste à utiliser la fonction de fermeture magique de l'API du pilote de chien de garde du noyau Linux. En bref, si vous écrivez un caractère magique spécifique 'V'/dev/watchdog, le chien de garde sera désactivé. Il existe également d'autres méthodes pour neutraliser le chien de garde, mais c'est celle que nous avons choisie pour nos recherches, car elle permet d'activer et de désactiver facilement le chien de garde à volonté.

Avec le chien de garde désactivé, la configuration du débogage d'initApp est assez simple. Nous voulions exécuter le code directement sur la caméra, si possible, au lieu d'utiliser un émulateur. L'architecture de la caméra est un MIPS Little Endian (MIPSEL). Nous avons eu la chance que les binaires GDB et GDBServer préconstruits puissent fonctionner sans modification ; cependant, nous ne le savions pas au départ, et nous avons donc également mis en place une chaîne d'outils pour compiler GDBServer spécifiquement pour la caméra. Une technique qui peut s'avérer utile si vous vous trouvez dans une situation similaire consiste à utiliser un outil de compilation tel que gcc pour compiler un code source en fonction de l'architecture cible présumée et voir s'il fonctionne ; voir l'exemple ci-dessous.

Dans notre cas, comme nous connaissions notre SoC, nous étions relativement certains de l'architecture cible ; cependant, dans certaines situations, cela peut ne pas être aussi simple à découvrir, et travailler à partir de binaires "hello world" peut s'avérer utile pour établir une compréhension initiale. Une fois que nous avons pu compiler les binaires, nous avons compilé GDBServer pour notre caméra et l'avons utilisé pour attacher et lancer initApp. Nous nous y sommes ensuite connectés à partir d'un autre ordinateur situé sur le même réseau local que la caméra. Un exemple est donné ci-dessous :

Dans l'exemple ci-dessus, nous utilisons le paramètre -x pour passer quelques commandes par commodité, mais elles ne sont pas nécessaires pour le débogage. Pour plus d'informations sur l'un des fichiers ou l'une des commandes, veuillez consulter notre dépôt GitHub elastic/camera-hacks. Pour que initApp se charge correctement, nous devons également nous assurer que les bibliothèques utilisées par le binaire sont accessibles via les variables d'environnement PATH et LD_LIBARY_PATH. Avec cette configuration, nous avons pu déboguer le binaire comme nous le souhaitions. Puisque nous avons également utilisé la méthode du personnage magique pour vaincre le chien de garde, nous devrons également nous assurer de contrôler les instances où le chien de garde peut être réactivé. Dans la plupart des cas, nous ne voulons pas que cela se produise. Nous avons donc écrasé les appels au chien de garde dans initApp afin que le chien de garde ne soit pas réactivé pendant que nous déboguons, comme le montre le schéma ci-dessous.

La vidéo suivante montre le processus d'installation complet, depuis le démarrage jusqu'à l'exécution de GDBServer. Dans la vidéo, nous démarrons également un nouveau processus initApp et, à ce titre, nous devons tuer à la fois le processus d'origine et le script shell daemon.sh qui créera un nouveau processus initApp s'il est tué.

Création d'un client P2P

Afin d'explorer plus avant l'étendue des capacités que P2P fournit aux appareils IoT d'AJCloud et la manière dont les attaquants peuvent en abuser, nous avons entrepris de construire notre propre client autonome. Cette approche supprimerait la manipulation de l'application Wansview Cloud Windows tout en nous permettant de nous connecter plus rapidement aux caméras et de tester les commandes que nous avons dérivées de la rétro-ingénierie du micrologiciel.

Grâce aux données de configuration que nous avons obtenues précédemment à partir des journaux de l'application Windows, nous savions qu'un client envoie des demandes à trois serveurs différents au maximum dans le cadre du processus de connexion. Ces serveurs fournissent des instructions aux clients sur la manière dont le trafic doit être acheminé pour accéder à une caméra donnée. Si vous souhaitez découvrir un plus grand nombre de ces serveurs au grand jour, vous pouvez scanner l'Internet en utilisant la charge utile UDP de quatre octets suivante sur le port 60722. Paul Marrapese a utilisé cette technique à bon escient dans le cadre de ses recherches.

Pour établir correctement une connexion P2P, un client doit d'abord envoyer un simple message d'accueil (MSG_HELLO), qui doit être acquitté (MSG_HELLO_ACK) par un serveur pair-à-pair. Le client demande alors au serveur (MSG_P2P_REQ) un numéro d'identification particulier. Si le serveur est au courant de l'existence de ce dispositif, il répondra (MSG_PUNCH_TO) au client en lui indiquant une adresse IP cible et un numéro de port UDP. Le client tentera alors de se connecter (MSG_PUNCH_PKT) à la paire IP et port ainsi qu'à d'autres ports dans une plage prédéterminée dans le cadre d'une routine de perforation UDP. En cas de succès, la cible renvoie un message (MSG_PUNCH_PKT) au client ainsi qu'un message final (MSG_P2P_RDY) pour confirmer que la connexion a été établie.

Après la connexion à une caméra, nous nous intéressons principalement à l'envoi de différents paquets MSG_DRW et à l'observation de leur comportement. Ces paquets contiennent des commandes qui nous permettent de manipuler physiquement la caméra, de visualiser et d'écouter ses flux vidéo et audio, d'accéder aux données qui y sont stockées ou de modifier sa configuration. La commande la plus simple avec laquelle nous avons commencé consistait à faire pivoter la caméra dans le sens inverse des aiguilles d'une montre, ce qui nous a permis d'identifier facilement la transmission d'un seul message.

Les messages de débogage de la caméra nous ont permis de localiser facilement l'endroit où cette commande a été traitée dans le micrologiciel.

La localisation de la source de ce message particulier nous a placés dans la routine principale qui traite les messages MSG_DRW, ce qui nous a permis de comprendre comment cette commande est invoquée et quelles autres commandes sont prises en charge par le microprogramme.

Une rétro-ingénierie et des tests approfondis nous ont permis de construire un client P2P PoC qui permet aux utilisateurs de se connecter à n'importe quelle caméra sur la plateforme AJCloud, à condition qu'ils aient accès à son deviceId. Les commandes de base prises en charge par le client comprennent le panoramique et l'inclinaison de la caméra, le redémarrage, la réinitialisation, la lecture de clips audio et même le plantage du micrologiciel.

La capacité la plus dangereuse que nous avons pu mettre en œuvre est une commande qui modifie un fichier de configuration du dispositif central : /var/syscfg/config_default/app_ajy_sn.ini. Sur notre appareil photo de test, le contenu du fichier était à l'origine le suivant :

[common]
product_name=Q5
model=NAV
vendor=WVC
serialnum=WVCD7HUJWJNXEKXF
macaddress=
wifimacaddress=

Bien qu'il semble contenir des métadonnées de base sur l'appareil, ce fichier est le seul moyen pour l'appareil photo de s'identifier. Au démarrage, la caméra lit le contenu de ce fichier et tente ensuite de se connecter à la plateforme AJCloud par le biais d'une série de requêtes curl vers différents points d'extrémité API. Ces requêtes curl transmettent le nom du produit, le modèle de l'appareil photo, le code du fournisseur et le numéro de série extraits du fichier INI en tant qu'arguments de la chaîne de requête. Nous avons utilisé notre client pour délivrer un message qui écrase le contenu comme suit :

[common]
product_name=
model=OPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrstuvwxyz{|}~HH01
vendor=YZ[\]^_`abcdefghijklmnopqrstuvwxyz{|}~HH01
serialnum=defghijklmnopqrstuvwxyz{|}~HH01
macaddress=
wifimacaddress=

Après la réinitialisation de la caméra, toutes les requêtes curl émises vers les points d'extrémité de l'API de la plateforme AJCloud dans le cadre de la routine de démarrage échoueront en raison des données malformées contenues dans le fichier INI. Ces demandes continueront d'être envoyées périodiquement, mais elles n'aboutiront jamais et l'appareil photo restera inactif et inaccessible par le biais de n'importe quelle application. Malheureusement, il n'existe aucun moyen simple de restaurer le contenu des fichiers précédents en réinitialisant l'appareil photo, en mettant à jour son microprogramme ou en rétablissant les paramètres d'usine. Les modifications de fichiers effectuées à l'aide de cette commande ont pour effet de briquer l'appareil photo et de le rendre inutilisable.

En examinant de plus près la fonction décompilée (syscfg_setAjySnParams) qui écrase les valeurs stockées dans app_ajy_sn.ini, nous pouvons voir que les paramètres d'entrée, extraits de la commande MSG_DRW, sont utilisés pour transmettre des données sous forme de chaîne qui seront utilisées pour écraser les champs du modèle, du fournisseur et du numéro de série dans le fichier. memset est utilisé pour écraser trois variables globales, destinées à stocker ces chaînes d'entrée, avec des octets nuls. strcpy est ensuite utilisé pour transférer les paramètres d'entrée dans ces globaux. Dans chaque cas, des octets seront copiés directement à partir du tampon de commande MSG_DRW jusqu'à ce qu'il rencontre un caractère nul.

Étant donné qu'aucune validation n'est appliquée à la longueur de ces paramètres d'entrée extraits de la commande, il est trivial de créer un message suffisamment long pour déclencher un dépassement de la mémoire tampon. Bien que nous n'ayons pas exploité cette vulnérabilité dans le cadre de notre attaque pour briquer la caméra, il semble qu'il s'agisse d'un cas où un pirate pourrait développer un programme d'exploitation qui lui permettrait d'exécuter un code à distance sur la caméra.

Impact

Nous avons confirmé qu'un large éventail d'appareils de plusieurs fournisseurs affiliés à AJCloud et plusieurs versions différentes de micrologiciels sont affectés par ces vulnérabilités et failles. Dans l'ensemble, nous avons réussi à démontrer nos attaques contre quinze caméras différentes de Wansview, Galayou, Cinnado et Faleemi. Sur la base de nos conclusions, on peut supposer que tous les appareils qui utilisent le micrologiciel AJCloud et se connectent à la plateforme AJCloud sont concernés.

Toutes les tentatives pour contacter AJCloud et Wansview afin de divulguer ces vulnérabilités et failles ont été infructueuses.

Qu'est-ce que les vendeurs ont fait de bien ?

Malgré les vulnérabilités que nous avons découvertes et discutées précédemment, AJCloud et les vendeurs de caméras ont bien mis en œuvre un certain nombre de contrôles de sécurité. Pour un dispositif aussi peu coûteux, de nombreuses bonnes pratiques ont été mises en œuvre. Tout d'abord, les communications réseau sont bien sécurisées grâce à l'authentification WebSocket basée sur des certificats. Outre l'ajout du chiffrement, le fait de placer de nombreux points d'extrémité de l'API derrière le certificat d'authentification rend les attaques de l'homme du milieu beaucoup plus difficiles. En outre, les APK des applications mobiles étaient signés et obscurcis, ce qui rendait la manipulation de ces applications très fastidieuse.

En outre, les fournisseurs ont également pris des décisions judicieuses en ce qui concerne le matériel et le micrologiciel de l'appareil photo. Le système d'exploitation local de l'appareil photo est effectivement limité, se concentrant uniquement sur les fonctionnalités nécessaires au produit. Le système de fichiers est configuré pour être en lecture seule, en dehors de la journalisation, et le chien de garde du noyau est une méthode efficace pour garantir le temps de fonctionnement et réduire le risque d'être bloqué dans un état d'échec. Le SoC Xburst T31 d'Ingenic constitue une plateforme capable de prendre en charge un large éventail de fonctions, notamment le démarrage sécurisé, un chien de garde pour la réinitialisation à la mise sous tension (POR) et un processeur RISC-V séparé capable d'exécuter un apprentissage automatique rudimentaire sur l'entrée de l'appareil photo.

Qu'est-ce que les vendeurs ont fait de mal ?

Malheureusement, un certain nombre d'occasions ont été manquées en ce qui concerne les fonctionnalités disponibles. L'accès non authentifié au nuage est probablement le plus grave. Compte tenu des contrôles d'accès à l'API établis pour de nombreux points finaux, le fait que les points finaux d'accès à l'utilisateur de la caméra soient disponibles par le biais d'un numéro de série sans authentification est une erreur énorme et évitable. Le protocole P2P est également vulnérable, comme nous l'avons montré, mais comparé à l'accès à l'API qui devrait pouvoir être corrigé immédiatement, la correction du protocole pourrait prendre un peu plus de temps. Il s'agit d'une vulnérabilité très dangereuse, mais elle est un peu plus compréhensible, car sa découverte et sa correction nécessitent beaucoup plus de temps.

Du côté de l'application, le principal problème est lié à l'application Windows, qui comporte une importante journalisation de débogage qui aurait dû être supprimée avant d'être rendue publique. Quant au matériel, il peut être facilement manipulé par un accès physique (bouton de réinitialisation exposé, etc.). Ce n'est pas tellement un problème étant donné le public cible. On s'attend à ce qu'il privilégie la facilité d'utilisation plutôt que la sécurité, notamment en raison de l'accès physique à l'appareil. Dans le même ordre d'idées, le démarrage sécurisé devrait être activé, d'autant plus que le SoC T31 le prend en charge. Bien que cela ne soit pas strictement nécessaire, il serait alors beaucoup plus difficile de déboguer directement le code source et le micrologiciel de l'appareil, ce qui compliquerait la découverte des vulnérabilités éventuellement présentes. Idéalement, il faudrait que le chargeur de démarrage puisse charger un système d'exploitation non signé pour faciliter le bricolage et le développement, mais qu'il empêche le système d'exploitation signé de se charger jusqu'à ce que la configuration du chargeur de démarrage soit rétablie. Toutefois, l'un des principaux défauts du micrologiciel actuel est qu'il dépend du numéro de série original, qui n'est pas stocké dans un point de montage en lecture seule lorsque le système fonctionne. La manipulation du numéro de série ne devrait pas bloquer l'appareil de manière permanente. Il doit disposer d'un mécanisme permettant de demander un nouveau numéro de série (ou de restaurer son numéro de série initial) en cas d'écrasement de son numéro de série, ou le numéro de série doit être immuable.

Atténuations

Certaines mesures peuvent être prises pour réduire la surface d'attaque et limiter les effets négatifs potentiels en cas d'attaque, bien qu'elles soient plus ou moins efficaces.

Segmenter les caméras Wi-Fi et autres appareils IoT du reste de votre réseau est une contre-mesure fortement recommandée qui empêchera les attaquants de pivoter latéralement vers des systèmes plus critiques. Cependant, cette approche n'empêche pas un attaquant d'obtenir des données utilisateur sensibles en exploitant la vulnérabilité du contrôle d'accès que nous avons découverte dans la plateforme AJCloud. En outre, compte tenu de la facilité avec laquelle nous avons pu démontrer comment il était possible d'accéder aux caméras et de les manipuler à distance via le P2P, tout appareil connecté à la plateforme AJCloud est toujours exposé à un risque important de compromission, quelle que soit la configuration de son réseau local.

Il ne serait pas possible de restreindre toutes les communications réseau à destination et en provenance de ces caméras, car la connectivité à la plateforme AJCloud est essentielle à leur fonctionnement. Comme indiqué précédemment, les appareils ne fonctionneront tout simplement pas s'ils ne sont pas en mesure de se connecter aux différents points de terminaison de l'API au démarrage.

Une approche viable pourrait consister à restreindre les communications au-delà de la routine de démarrage initiale. Toutefois, cela empêcherait l'accès et le contrôle à distance via des applications mobiles et de bureau, ce qui irait à l'encontre de l'objectif premier de ces caméras. Pour de plus amples recherches dans ce domaine, veuillez vous référer à "Blocking Without Breaking : Identification and Mitigation of Non-Essential IoT Traffic", qui explore cette approche plus en profondeur à travers une myriade d'appareils IoT et de fournisseurs.

La meilleure approche pour sécuriser une caméra Wi-Fi, quel que soit le fournisseur, tout en conservant ses fonctionnalités de base, consiste à la flasher avec un micrologiciel open source alternatif tel qu'OpenIPC ou thingino. Le passage à un firmware open source évite les maux de tête associés à la connectivité forcée aux plateformes cloud des fournisseurs en offrant aux utilisateurs un contrôle fin de la configuration de l'appareil et de l'accessibilité au réseau à distance. Le libre accès à la source du micrologiciel permet de s'assurer que les failles et les vulnérabilités critiques sont rapidement identifiées et corrigées par les contributeurs diligents du projet.

Principaux points abordés

Nos recherches ont révélé plusieurs vulnérabilités critiques qui couvrent tous les aspects des caméras fonctionnant avec le micrologiciel AJCloud et qui sont connectées à leur plateforme. Des failles importantes dans la gestion du contrôle d'accès sur leur plateforme et le protocole PPPP constituent une surface d'attaque étendue qui affecte des millions d'appareils actifs à travers le monde. L'exploitation de ces failles et vulnérabilités conduit à l'exposition de données sensibles de l'utilisateur et permet aux attaquants de contrôler à distance toutes les caméras connectées à la plateforme AJCloud. En outre, une commande P2P intégrée, qui fournit intentionnellement un accès arbitraire en écriture à un fichier de configuration clé, peut être utilisée pour désactiver les caméras de manière permanente ou faciliter l'exécution de code à distance en déclenchant un débordement de mémoire tampon.

Veuillez consulter notre dépôt GitHub pour les outils et les scripts personnalisés que nous avons créés, ainsi que les données et les notes que nous avons saisies et qui, selon nous, seraient les plus utiles à la communauté des chercheurs en sécurité.

Tempête à l'horizon : A l'intérieur de l'écosystème AJCloud IoT