Dans quelle mesure votre caméra de "sécurité" est-elle sécurisée ?

Synthèse

Au début de 2020, sur mon ancien lieu de travail, j'ai eu l'occasion de participer à un événement interne de type pwn2own. Plusieurs cibles étaient disponibles, mais celle qui m'intéressait le plus était la caméra de sécurité sans fil Accfly. Malheureusement, je n'ai pas pu terminer mes recherches pour l'événement lui-même, mais comme personne d'autre n'avait tenté de s'attaquer à cet appareil, j'ai poursuivi mes travaux.

L'objectif principal de la recherche était les vulnérabilités pouvant mener à une exécution de code à distance (RCE). Ce type de vulnérabilité permet à un attaquant de prendre le contrôle total de l'appareil et, dans le cas d'une caméra vidéo, peut entraîner une compromission totale de la vie privée du propriétaire. Malheureusement, le firmware de l'appareil s'est avéré truffé de tels problèmes.

Premièrement, l'appareil ne fournit aucune authentification. Par conséquent, un attaquant capable de s'y connecter peut y accéder librement et le reconfigurer. Dans sa forme la plus simple, il est possible de redémarrer l'appareil en continu, le rendant totalement inutilisable pour l'utilisateur légitime. La portée de cette attaque est quelque peu limitée, car l'appareil est conçu pour être utilisé au sein d'un réseau WiFi, généralement derrière un NAT, donc pas directement accessible depuis Internet. Cependant, l'absence de chiffrement entre l'appareil et l'application smartphone de son propriétaire, ainsi que l'utilisation du serveur du fournisseur comme proxy pour la communication, crée une opportunité pour des attaques MitM ou de manipulation DNS, qui peuvent franchir la restriction NAT du WiFi.

De plus, l'application utilise un protocole binaire propriétaire pour la communication. Il a été implémenté dans un mélange de C et de C++ et s'est avéré plein de fonctions de gestion de chaînes non sécurisées. L'exécutable principal contient une énorme quantité de code inutilisé, ce qui suggère qu'il est réutilisé sur d'autres appareils. Cela rend la maintenance plus difficile et augmente la surface d'attaque. L'application n'active aucun mécanisme de sécurité moderne qui la protégerait contre de nombreuses techniques d'exploitation courantes. De plus, elle ne limite même pas les permissions utilisateur, tournant en root - avec les privilèges les plus élevés disponibles.

À la suite de ces recherches, les quatre vulnérabilités suivantes ont été documentées.

• CVE-2020-25782 - débordement de tampon basé sur la pile sans authentification dans la fonction CNetClientManage::ServerIP_Proto_Set lors du traitement des messages entrants
• CVE-2020-25783 - débordement de tampon basé sur le tas sans authentification dans la fonction CNetClientTalk::OprMsg lors du traitement des messages entrants
• CVE-2020-25784 - débordement de tampon basé sur la pile sans authentification dans la fonction CNetClientGuard::SubOprMsg lors du traitement des messages entrants
• CVE-2020-25785 - débordement de tampon basé sur la pile sans authentification dans la fonction CFtpProtocol::FtpLogin pendant la procédure de mise à jour

Pour trois d'entre elles, des exploits RCE ont été développés, permettant à un attaquant d'obtenir le contrôle total de l'appareil. Cependant, en raison de l'absence de réponse du fournisseur aux tentatives de signalement des vulnérabilités, ce dépôt ne contient que des exploits PoC limités, qui ne font que faire planter l'application.

Les problèmes ont été découverts dans la version logicielle V3.10.73 et vérifiés dans la version logicielle V4.15.77, la dernière disponible au moment de cette publication (26 janvier 2021).

Si vous avez des questions, n'hésitez pas à me contacter par e-mail (voir le commit git) ou via les issues Github. Si vous possédez un appareil IoT qui, selon vous, pourrait être intéressant à pirater, si vous recherchez un chercheur en sécurité ou si vous voulez simplement dire bonjour, je serai ravi de vous lire. Vous pouvez également m'offrir un café !

Introduction

L'appareil cible est une caméra vidéo contrôlée à partir de l'application mobile associée. Mon analyse a commencé par le trafic réseau de la caméra et s'est poursuivie dans le firmware de la caméra. Un protocole binaire propriétaire est utilisé pour toutes les communications. Les commandes sont soit envoyées directement à l'appareil mobile lorsqu'il est sur le même réseau, soit transmises via le serveur du fabricant de l'appareil. La caméra elle-même écoute sur plusieurs ports TCP (23456,34567) et UDP (34568, 34569). Il n'y a ni chiffrement ni authentification pour le trafic réseau, ce qui permet des attaques MitM ou un accès direct lorsque la caméra est exposée sur le réseau. Il semble probable qu'un accès au flux vidéo soit également possible sans authentification, mais je n'ai pas fait assez de rétro-ingénierie sur le protocole propriétaire pour tenter l'expérience.

Après un bref aperçu de la communication, l'étape suivante consistait à essayer d'accéder au firmware de l'appareil. Ma première tentative a été de le télécharger directement en détournant le processus de mise à jour de l'appareil, mais rien de tel n'est apparu dans le trafic réseau. Je serais resté bloqué à cette étape sans l'aide très précieuse d'un collègue qui a extrait le firmware de la mémoire flash, ce qui m'a permis de poursuivre ces recherches.

Le firmware exécute Linux sur un CPU MIPS little-endian. Il y a exactement un processus intéressant, appelé Alloca, responsable de la capture vidéo et qui gère également toutes les communications réseau. L'application est créée en C++ et contient beaucoup de code inutilisé sur cet appareil. Cela indique que le même logiciel est également utilisé sur différents appareils.

La fuite

Même si ce problème a été découvert en dernier, il est crucial pour l'exploitation effective de la plupart des autres, car ils découlent de l'utilisation de fonctions de chaînes C non sécurisées. Bien qu'il existe plusieurs techniques pouvant être utilisées pour une exécution de code réussie dans des scénarios similaires, l'application est créée de telle manière qu'elles sont pour la plupart inutiles. Le principal problème est que le code et les données d'Alloca sont alloués statiquement à des adresses basses ( <&nbsp;0x01000000). Ainsi, les tentatives de réutilisation de code existant (c'est-à-dire ROP et autres) ne sont pas utiles, car elles nécessitent la possibilité d'écrire des adresses dans la mémoire du programme. Parce que les chaînes C utilisent \x00 comme caractère de terminaison et que les fonctions de chaînes terminent le traitement au premier octet de ce type, il n'est pas possible d'utiliser plus d'un seul octet NULL. De plus, l'emplacement de la pile est aléatoire et l'application est fortement multi-threadée, ce qui rend les autres techniques beaucoup moins fiables.

Cette vulnérabilité résulte du partage de données entre plusieurs threads et de l'utilisation non sécurisée de strcpy. Bien que j'aie analysé ce problème particulier pendant longtemps, je n'ai repéré l'opportunité de l'utiliser comme vecteur de fuite de données que quelques semaines avant cette publication. Fait intéressant, grâce à la fuite de l'adresse du tas d'un objet C++, cette vulnérabilité permet également une exécution de code à distance. Cependant, cette attaque n'est pas incluse dans ce rapport.