Les systèmes de vidéosurveillance et l’IoT : protocoles et vulnérabilités – Partie 2/2

3.1 Premier cas d’audit : moins fort ensemble

Notre première victime sera une caméra de vidéosurveillance gérable depuis le site Internet de l’éditeur et à travers une application mobile dédiée.

La caméra monte une connexion VPN vers l’infrastructure cloud de l’éditeur, ce qui permet à cette infrastructure de se connecter dans le sens inverse à la caméra pour gérer sa configuration ou récupérer son flux vidéo, afin de le rendre disponible à l’utilisateur par l’intermédiaire du site web et de l’application mobile.

Une interface console UART donnant accès à un bootloader non sécurisé est découverte sur le PCB de la caméra. Certaines commandes bootloader peuvent alors être scriptées afin de récupérer les images présentes dans la mémoire flash, comme le kernel ou le système de fichiers. Il est alors possible d’installer une porte dérobée dans l’image correspondant au système de fichiers, avant de la réinstaller dans la mémoire flash. L’absence de vérification des images, par exemple par signature, permet ainsi de gagner un accès root à la caméra.

On a alors accès notamment aux informations d’authentification VPN ou aux informations d’authentification à l’interface d’administration de la caméra, qui ne semblent pas pouvoir être changées par l’utilisateur de la solution.

Après connexion au VPN, il apparaît que l’éditeur a omis le cloisonnement des clients connectés. Ce qui permet, tirant avantage des informations obtenues précédemment, d’accéder à la configuration et surtout aux flux vidéos de toutes les caméras connectées au réseau privé. Bonjour Monsieur assis dans son salon ! (Figure 2).

Fig. 2 : Une victime de sa propre caméra de vidéosurveillance, observée à son insu par un attaquant ayant réussi une intrusion sur l’infrastructure VPN du fabricant.


3.2 Deuxième cas d’audit : la vie secrète d’une caméra ordinaire

Cette deuxième caméra, administrable à l’aide d’une application mobile, repose sur deux types de flux : un flux vidéo envoyé vers le cloud de l’éditeur, celui-ci servant d’intermédiaire à l’application mobile lors de la visualisation des images et un flux XMPP servant à contrôler la configuration et l’activité de la caméra.

XMPP, protocole de présence et de messagerie destiné à l’origine au « t’chat », trouve ainsi une tout autre utilité en tant que canal de contrôle d’équipements IoT. L’application mobile comme la caméra se comportent toutes deux comme des clients du service de messagerie instantanée et s’échangent ainsi des messages de contrôle. On peut donc considérer que ces caméras se réunissent toutes sur un salon Jabber pour pouvoir discuter.

Après avoir extrait un login et un mot de passe de l’application mobile, il est possible de se connecter au service XMPP avec un simple logiciel de messagerie comme Pidgin. Un défaut de configuration du service est alors apparu évident : le service d’annuaire était activé, et il était dès lors aisé d’énumérer l’ensemble des comptes actuellement connectés, ce qui inclut les caméras et les clients mobiles, puis d’ajouter à volonté une caméra à son Roster XMPP avant de lui envoyer des messages instantanés.

Ce canal de contrôle permet alors de redémarrer la caméra, ou plus intéressant, de changer ses paramètres de connexion wifi ou lister les réseaux wifi à portée. Elle semble par contre rester insensible aux « smileys » et aux « buzz » 🙂

Le contenu des messages instantanés est écrit en JSON. L’exemple en figure 3 montre l’échange avec une caméra pour obtenir la liste des réseaux Wifi à portée. La liste des actions possibles peut être obtenue en effectuant la rétro-ingénierie de l’application mobile.

Fig. 3 : Discussion jabber avec une caméra, obtention des réseaux Wifi à sa portée.

3.3 Troisième cas : the one gateway to rule them all

En plus de la vidéosurveillance fonctionnant de manière autonome, cette dernière peut faire partie d’une offre domotique plus complète, comprenant une passerelle IoT à installer sur le réseau local de sa box Internet par exemple. La connexion de cette passerelle vers le réseau du fabricant peut parfois également être exploitée afin de compromettre non seulement les caméras, mais aussi tous les autres objets connectés réunis sous le même contrôle.

Un audit concernant une offre domotique connectée, permettant de fédérer des objets connectés provenant de nombreux fabricants, a donné l’occasion de s’intéresser à la sécurité d’un protocole assez courant dans l’IoT : MQTT.

Les comptes clients s’authentifient auprès d’un webservice, mais le reste du fonctionnement de l’application est organisé autour du protocole MQTT. L’identifiant et le mot de passe de connexion au service MQTT étaient partagés entre tous les clients, et enregistrés « en dur » dans les sources de l’application smartphone du fabricant. Le « cloisonnement » est réalisé côté application mobile en effectuant une souscription aux seuls flux (ou topics) MQTT correspondants à l’ID de l’utilisateur authentifié sur le webservice.

Cette mesure de sécurité est évidemment insuffisante, et rien n’empêche un client malveillant de souscrire ou de publier sur des flux arbitraires. De cette façon, il a été possible de souscrire aux flux de la passerelle d’un autre client grâce à la simple connaissance de son identifiant, et d’utiliser l’API exposée au travers du service MQTT pour prendre le contrôle de ses objets connectés, incluant certaines options de configuration relatives aux caméras de surveillance.

3.4 Dans l’actualité

D’autres cas du même acabit peuvent être observés dans l’actualité sécurité. Tout récemment, le chercheur Pierre Kim a publié un bulletin [PIERREKIM] relatif à des caméras de fabrication chinoise. Une même base vulnérable semble utilisée dans plus de 1200 modèles. Depuis un réseau local, tout y passe : backdoor constructeur, accès au flux vidéo sans authentification, exécution de code en tant que root de manière anonyme, etc. Et une nouvelle fois, une connexion cloud désastreuse expose la caméra encore davantage. D’après le chercheur, la caméra et l’application smartphone de contrôle se connectent toutes les deux en UDP aux serveurs du fabricant. L’application demande simplement un accès à une caméra grâce à son numéro de série, et si la caméra portant ce numéro est disponible, un tunnel UDP est établi entre l’application et la caméra, le serveur cloud servant de proxy. Il est alors possible de faire une attaque par force brute pour découvrir les informations d’authentification et prendre le contrôle.

Le chercheur Iraklis Mathiopoulos [IRAKLIS] s’attaque également au cloud d’un fabricant répandu, et parvient à exploiter une définition d’entités externes XML afin de lire, avec les droits root, n’importe quel fichier présent sur les serveurs d’API distants. Son article conclut qu’il aurait été aisé de gagner un accès aux milliers de caméras connectées du fabricant.

4. Pourquoi ça #fail ?

On constate plusieurs dénominateurs communs à ces vulnérabilités affectant la vidéosurveillance connectée.

Premièrement, la mise en échec de mesures de sécurité en place comme le NAT ou les pare-feux périmétriques, à cause de l’initiation de la connexion de la caméra vers le cloud distant. En effet, les flux sortants sont généralement moins, voire pas filtrés, et de plus la connexion au cloud peut être explicitement autorisée par les administrateurs réseaux pour le bon fonctionnement des équipements.

Dès lors, une vulnérabilité affectant le cloud peut permettre de compromettre l’intégralité des caméras de vidéosurveillance qui y sont connectées, puis potentiellement de s’attaquer aux réseaux privés normalement non exposés sur lesquels elles se trouvent. Et c’est précisément ce qu’on a pu observer, car l’absence de mesures de cloisonnement sur le cloud, permet fréquemment, une fois un pied dans la porte, de compromettre les objets de tous les clients.

Autre point commun, une trop grande confiance des éditeurs dans la sécurité locale de leur objet ou de leurs applications mobiles : dans plusieurs de ces cas, la caméra (ou l’application) stockait des données sensibles permettant d’accéder au cloud. Pratiquer la sécurité par l’obscurité pour protéger l’accès à des centaines de milliers d’objets connectés peut facilement tourner au désastre.

Ensuite, les protocoles mis à la mode par l’IoT ne sont pas toujours bien maîtrisés et des sécurités basiques comme l’authentification ou le cloisonnement des données peuvent être totalement défectueuses. Outre XMPP abordé précédemment, nous pouvons également citer les protocoles de message-queuing comme MQTT, dont nous avons observé à plusieurs reprises des configurations laissant libre champ aux malveillances de toutes sortes.

Les protocoles radio dédiés à l’IoT ont également un rôle dans la sécurité de la vidéosurveillance. Pour des caméras capables de faire de la détection de mouvements et lever des alertes, pouvoir communiquer sur des réseaux maillés M2M (machine to machine) comme SigFox ou LoRa permet une meilleure résilience du canal de communication d’envoi des alertes par rapport à une connexion Internet domestique. Hélas, la recherche en sécurité a déjà plusieurs fois démontré que la sécurité de ces nouveaux réseaux laisse parfois à désirer. Notamment, le chiffrement des échanges est mis en cause. Partiellement ou totalement laissé à la discrétion des éditeurs ou fabricants d’objets connectés, ou souffrant de faiblesses d’implémentation, celui-ci peut selon les cas permettre des attaques de captures de messages (sniffing) ou d’usurpation [SIGFOX] [LORAWAN].

Bien malheureusement, ce qui est vrai pour l’IoT se vérifie parfois aussi pour des technologies établies depuis longtemps et qui devraient être maîtrisées. Nous observons toujours les mêmes erreurs qu’aux débuts du passage sur IP de la vidéosurveillance : caméras disposant d’IP publiques, protocoles en clair, HTTP et Telnet à foison, absence d’authentification pour la lecture de flux vidéo, mots de passe par défaut voire portes dérobées, etc.

Pour finir, si tout cela n’était pas déjà suffisant, le facteur humain n’est pas en reste, avec la fâcheuse habitude de « déployer et oublier » qui fait qu’une caméra une fois mise en place pourra ne jamais bénéficier de mise à jour, si toutefois son fabricant a bien voulu prévoir cette fonctionnalité, ou encore la non moins fâcheuse habitude d’exposer sur Internet l’interface d’une caméra sans avoir modifié les mots de passe par défaut.

Parallèlement à ces faiblesses, la recherche de vulnérabilités est devenue plus aisée d’une certaine façon : le hacking « matériel » est plus accessible avec une bonne disponibilité d’outils pour communiquer avec divers protocoles de debug ou de communication série (JTAG, SPI, I2C, etc.), et un savoir-faire diffusé par la communauté sécurité. Les caméras elles-mêmes sont souvent suffisamment puissantes et disposent d’assez d’espace de stockage pour y installer un outillage d’analyse conséquent. La quantité de systèmes Linux s’exécutant sur des plateformes courantes dans l’IoT, à base MIPS ou ARM, fait que beaucoup d’outillage précompilé peut être utilisé directement.

Conclusion

L’IoT d’une manière générale et la vidéosurveillance en particulier semblent vouloir rester le parent pauvre de la sécurité informatique. La vidéosurveillance est d’ailleurs régulièrement mise en défaut depuis sa connexion aux réseaux notamment sur Internet, bien avant que l’on parle d’IoT.

Cela a pour conséquence que ces objets connectés deviennent sporadiquement le terrain de jeu de chercheurs en sécurité en théorie bien intentionnés, mais aussi de groupes criminels qui le sont nettement moins. Ainsi, des botnets d’objets connectés comme le fameux « Mirai » ont pu être observés récemment. Les caméras de vidéosurveillance présentent à ce titre un intérêt supplémentaire, en effet, la transmission d’un flux vidéo nécessitant une connexion de qualité, elles constituent des candidats parfaits pour rejoindre un botnet puisque bénéficiant normalement d’une bande passante et d’un temps de réponse corrects.

Elles peuvent constituer également un véritable « trou dans la raquette », un point d’entrée vers un réseau interne inaccessible par ailleurs, l’attaque pouvant parfois se faire par l’intermédiaire du cloud des fabricants.

Il est permis d’imaginer, des scénarios plus audacieux comme un cambrioleur technophile détournant la vidéosurveillance et la domotique de ses victimes pour s’assurer que leur maison est vide, un chantage à la sextape, ou encore toutes sortes de scénarios d’espionnage, industriel ou politique. Néanmoins, les faits avérés à ces sujets manquent.

Les causes du mal n’ont donc pas changé : ces nouveaux équipements sont connectés par les utilisateurs sans être contraints ou informés de suivre des bonnes pratiques de sécurité, du changement des mots de passe par défaut à l’application des mises à jour de sécurité. Et si les principaux éditeurs de système d’exploitation bureautique incitent ou contraignent désormais les utilisateurs à appliquer des correctifs [W10], peu de solutions IoT que nous avons pu étudier s’inscrivent pour le moment dans cette démarche.

Pourtant, le salut ne pourra venir que des éditeurs qui doivent adopter une véritable démarche de sécurité pour minimiser les risques. Si bon nombre de professionnels de sécurité obstruent l’objectif de leur webcam avec des caches physiques, illustration de la confiance qu’ils accordent à leurs propres équipements, il faut imaginer qu’il sera individuellement difficile demain de faire de même avec les milliards de caméras surveillant les voitures, domiciles et l’ensemble des espaces publics des smart cities…

Références

[TEMPEST] ANSSI, « La protection contre les signaux compromettants » : http://www.ssi.gouv.fr/uploads/IMG/pdf/II300_tempest_anssi.pdf
[EDIMAX] Vulnérabilité RTSP sur une caméra Edimax : https://www.coresecurity.com/advisories/vivotek-ip-cameras-rtsp-authentication-bypass
[SAMSUNG] Vulnérabilité de contournement d’authentification chez Samsung : https://www.exploitee.rs/index.php/Samsung_SmartCam%E2%80%8B
[SECCON] SEC Consult, Backdoor dans une camera Sony : http://blog.sec-consult.com/2016/12/backdoor-in-sony-ipela-engine-ip-cameras.html
[VICON] Article du support Vicon, debug via Telnet : https://vicon-security.zendesk.com/hc/en-us/articles/210735023-Telnet-into-an-IQeye-camera-to-get-debug-information-
[IZON] Identifiants en dur sur une caméra Izon : http://www.securityspace.com/smysecure/catid.html?id=1.3.6.1.4.1.25623.1.0.103824
[PIERREKIM] Pierre Kim « Multiple vulnerabilities found in Wireless IP Camera » : https://pierrekim.github.io/blog/2017-03-08-camera-goahead-0day.html
[IRAKLIS] Iraklis Mathiopoulos, XXE in Hikvision camera cloud : https://medium.com/@iraklis/an-unlikely-xxe-in-hikvisions-remote-access-camera-cloud-d57faf99620f
[SIGFOX] Gilbert Kallenborn, « Objets connectés : polémique sur la sécurité du réseau français Sigfox » http://www.01net.com/actualites/objets-connectes-le-reseau-francais-sigfox-une-passoire-en-matiere-de-securite-957875.html
[LORAWAN] Gilbert Kallenborn, « Objets connectés : les réseaux LoRaWAN, vulnérables aux attaques de hackers » http://www.01net.com/actualites/objets-connectes-les-reseaux-lorawan-vulnerables-aux-attaques-de-hackers-1042538.html
[W10] Article « New details emerge about forced Windows 10 upgrade » : http://www.infoworld.com/article/3029613/microsoft-windows/new-details-emerge-about-forced-windows-10-upgrade-and-how-to-block-it.html

Nha-Khanh NGUYEN (@N1aKan),
Romain CASTEL (@Berenseke),
Florent POULAIN
Auditeurs sécurité, Digital Security

Retrouvez cet article (et bien d’autres) dans MISC n°91, disponible sur la boutique et sur la plateforme de lecture en ligne Connect !