La vidéosurveillance est censée être un atout de sécurité du côté des honnêtes gens. Malheureusement, la propre sécurité de ces systèmes est parfois défaillante au point qu'ils se retournent contre leurs propriétaires. C'est ainsi que naissent des botnets de caméras connectées, ou la crainte légitime qu'un inconnu puisse vous surveiller avec votre propre matériel. CCTV, puis virage IP et Internet et finalement explosion de l'Internet of Things (IoT), chaque génération de vidéosurveillance comporte son lot de calamités. Passons en revue cette chronologie du pire.
1. Premières prises de vues
La genèse de la vidéosurveillance a lieu après la Deuxième Guerre mondiale, principalement à vocation militaire ou gouvernementale. Ces premiers systèmes n’offrent pas de possibilité d’enregistrement, un opérateur doit être constamment en poste derrière les moniteurs.
Puis, à partir du milieu des années 70, le développement de supports vidéos comme les cassettes permet d'enregistrer et détruire à volonté les images. La vidéosurveillance se « démocratise », et envahit les espaces publics et les grandes entreprises.
Les systèmes de vidéosurveillance analogique se basaient alors sur un ensemble de câbles, de type câbles coaxiaux, transmettant le signal analogique et reliés à un centre de contrôle doté de moniteurs ou d'enregistreurs. On parle alors de circuit fermé ou de Closed-Circuit TV (CCTV), la diffusion restant interne.
La plupart des attaques possibles requièrent un accès physique et permettent de couper, dupliquer ou remplacer le signal vidéo transitant sur les câbles. D'autre part, des attaques plus complexes à base de perturbations électromagnétiques peuvent permettre de brouiller le signal sans phase destructive. Dans un domaine similaire, l'écoute passive d'émissions de type [TEMPEST] (ce qui recouvre bien sûr les émanations électromagnétiques, mais aussi mécaniques ou acoustiques) peut permettre de reconstituer plus ou moins fidèlement les informations traitées à l'origine.
Faisant suite à l'essor des systèmes analogiques jusque dans les années 90, et avec la montée en puissance des réseaux informatiques et des technologies numériques, des systèmes de vidéosurveillance numériques ont vu le jour.
Une phase de transition a vu mixer les systèmes analogiques et numériques, puis petit à petit les caméras analogiques ont été remplacées par des caméras numériques IP permettant l’utilisation directe du réseau informatique pour la transmission des flux vidéos.
2. L'avènement de l'IP
Si l'usage qui est fait de la vidéosurveillance n'a fondamentalement pas changé, sa situation est désormais très différente. Les caméras fonctionnent désormais sur des réseaux aux multiples fonctionnalités : réseaux domestiques, d'entreprise, filaires ou sans fils, publics ou privés, etc.
Là où les caméras analogiques s'apparentaient à de simples sondes remontant de manière permanente un flux d'information à des équipements (enregistreurs, moniteurs) avec lesquels elles disposaient d'une connexion plus ou moins dédiée, les caméras IP s'intègrent au beau milieu de switches, routeurs, pare-feux, points d'accès wifi, connexions Internet personnelles ou professionnelles, lien sites à sites, serveurs et postes de travail, etc.
Par ailleurs, leur propre système est devenu plus complexe. La plupart des caméras IP disposent d'options de configuration relativement complexes, d'interfaces d'administration multiples (HTTP(S), SSH, Telnet, technos propriétaires), du support de multiples protocoles de diffusion vidéo. Il s'agit parfois même d'équipements constitués de plusieurs « sous-cartes » exécutant des systèmes d'exploitation différents et communicant entre elles. Par exemple, un système chargé de piloter la caméra et un système exécutant la partie services externes tels que streaming, Web ou SSH.
Elles s'apparentent donc désormais, de par leurs fonctionnalités et leurs moyens de communication, à beaucoup d'autres éléments du système d'information, et s'inscrivent donc dans les mêmes problématiques de sécurité : isolation des segments réseaux, gestion des correctifs, gestion de la configuration, réduction de la surface d'attaque, et bien plus encore.
2.1 Vulnérabilités classiques
Malheureusement, la sécurité de beaucoup de modèles semble avoir été quelque peu négligée. Les raisons peuvent être nombreuses : coûts, impératifs de time-to-marketsur le marché de l'IoT, etc. Quelles qu'elles soient, le constat est là, et voici quelques vulnérabilités classiques des caméras IP :
- flux vidéo ou d'administration en clair, avec tous les scénarios de Man-in-the-middle que cela implique ;
- absence d'authentification ou défaut d'implémentation, sur la partie administration, ou sur la partie vidéo avec des protocoles tels que RTP ou RSTP lisibles à ce moment-là avec un simple lecteur vidéo supportant le streaming comme VLC, comme dans cet exemple : [EDIMAX] ;
- mots de passe par défaut, souvent laissés tels quels par l'utilisateur ;
- toutes sortes de vulnérabilités web classiques, dont les plus importantes permettront l'exécution de code ou de commandes systèmes, parfois pré-authentification.
À titre d'illustration, sur un ancien modèle Network Camera de chez Axis, le concept de cookie de session était inexistant. Ainsi, un utilisateur non authentifié connaissant l'adresse des autres pages, et notamment la page d'administration, pouvait accéder aux contrôles de la caméra.
Plus récemment, la caméra SmartCam de chez Samsung, a souffert d'un défaut d'implémentation de son applicatif web permettant d'initialiser de nouveau le mot de passe d'administration sans disposer de celui en cours [SAMSUNG]. Il était en effet possible de refaire appel à la page permettant la première initialisation, simplement de la manière suivante :
curl 'http://<IP>/classes/class_admin_privatekey.php' --data 'data=NEW%3B<NEW-PASSWORD>'
2.2 Backdoors et autres joyeusetés
Outre des vulnérabilités dont on peut espérer qu'elles ne sont pas introduites volontairement, il arrive de tomber sur ce qui ressemble fort à des portes dérobées ménagées intentionnellement par le fabricant d'une caméra [SECCON]. D'autre fois, il peut s'agir d'un accès Telnet laissé pour des besoins de debug[VICON], ou des classiques mots de passe « en dur » que le fabricant ne semble pas souhaiter supprimer [IZON].
Outre les vulnérabilités exploitables depuis un sous-réseau commun, de nombreuses caméras sont de plus rendues disponibles sur Internet, plus ou moins volontairement, par leurs utilisateurs.
L'UPnP, qui permet à un équipement de demander à son routeur la mise en place d'une redirection de ports depuis l'interface publique, représente les premières tentatives de contourner automatiquement les limitations mises en place par le NAT, perçues comme un frein au bon fonctionnement de la vidéosurveillance connectée. Celui-ci assure pourtant une certaine sécurité et réduit l'exposition des équipements internes vis-à-vis de réseaux non sûrs comme Internet.
Une simple requête sur le moteur de recherche Shodan permet de prendre conscience du nombre de caméras non sécurisées accessibles sur Internet, comme le montre la figure 1.
Fig. 1 : Un modèle identifié comme exploitable à distance par un chercheur en sécurité. Plus de 200.000 résultats sur Shodan.
Abordons maintenant le cœur du sujet, i.e. comment les nouveautés de l'ère de l'IoT ont apporté de nouvelles pratiques et innovations technologiques, et donc leur lot de vulnérabilités associées.
3. Le virage de l'IoT et la vidéosurveillance
L'apparition de l'IoT s'est accompagnée de nouveaux protocoles de communication, de la multiplication des infrastructures de type Cloud, la mise à disposition de System on Chip (SoCs) ou de kits de développement à la fois moins chers, plus puissants et riches de fonctionnalités.
Une maison connectée peut désormais ressembler à une salle serveur complète, mais sans le personnel en charge de l'administration et de la sécurité, avec les conséquences que l'on peut imaginer.
Cette « massification » des objets connectés concerne également la vidéosurveillance. On trouve ainsi des caméras seules ou intégrées à des offres domotiques à visée grand public, des babyphones ou autres systèmes de surveillance de nounous, etc. La vidéosurveillance n'est donc plus réservée aux entreprises, aux services publics ou aux détenteurs de patrimoines importants.
Une autre tendance est la multiplication des moyens de connexion et l'envoi des données dans le cloud. La vidéosurveillance n'a bien sûr pas été épargnée, et il est fréquent qu'un de ces systèmes déporte ses options de configuration ainsi que ses flux vidéos sur les serveurs de l'éditeur, auquel l'utilisateur pourra accéder depuis n'importe quel endroit du monde au moyen d'un navigateur web ou d'une application mobile. Fort pratique, convenons-en.
Voici quelques cas observés par Digital Security lors d'audits de vidéosurveillance connectée ou vus dans l'actualité, qui permettront d'aborder un certain nombre de technologies et vulnérabilités courantes de ces systèmes.
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 3montre 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 dansune camera Sony : http://blog.sec-consult.com/2016/12/backdoor-in-sony-ipela-engine-ip-cameras.html
[VICON] Article du support Vicon, debugvia 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
