Babyphone de Troie

Un Français a découvert début mars que le fournisseur chinois qui équipe des dizaines de modèles de caméras IP et babyphones vendus sur Amazon, Fnac, Cdiscount ou en marque blanche chez les opérateurs mobiles disposait d’un accès direct aux images de centaines de milliers d’appareils, au travers d’une infrastructure ouverte aux quatre vents. Deux mois plus tard, il publie l’ensemble de ses découvertes, qui dressent un tableau particulièrement inquiétant, et laissent supposer une utilisation à grande échelle des alertes émises par les caméras en question.

Quel meilleur cheval de Troie qu’un appareil dédié à la sécurité ? Le Français Sammy Azdoufal, développeur qui se présente comme spécialiste IA, a découvert début mars que plusieurs centaines de références de caméras IP, babyphones et autres accessoires dédiés à la surveillance domestique étaient susceptibles de présenter des failles béantes exposant les images capturées, et donc l’intimité des foyers concernés. En cause ? Une entreprise chinoise baptisée Meari, qui vend ses produits ou ses services principalement en marque blanche à des tiers.

Ces derniers distribuent ensuite les produits finaux concernés soit sous leurs propres couleurs, au travers notamment des places de marché de grands noms tels que Amazon, Fnac, Darty ou Cdiscount, mais aussi chez les opérateurs téléphoniques ou les acteurs de la télésurveillance, en marque blanche, à l’image du brésilien Intelbras.

Au total, le développeur affirme, liste à l’appui, avoir pu établir un lien direct entre Meari et 378 références distinctes de caméras, distribuées dans au moins 15 pays. Surtout, il explique à Next avoir pu directement compter plus de 1,1 million d’appareils vulnérables se connecter, en clair, aux serveurs de Meari, sur une simple période de 24 heures. « Si j’avais laissé tourner mon script une semaine, le volume d’appareils aurait sans doute été bien plus conséquent », estime-t-il.

Deux mois après sa découverte initiale, l’équipementier chinois est censé avoir sécurisé son backend, mais de nombreux comportements problématiques subsistent. « Disons que si j’avais un enfant, je n’achèterais pas une caméra équipée par Meari », résume Sammy Azdoufal.

Le précédent DJI

Si son nom vous dit quelque chose, c’est peut-être parce que l’intéressé n’en est pas à son coup d’essai. Mi-février, le développeur a eu les honneurs de la presse mondiale : il révèle avoir découvert de façon fortuite une faille de sécurité majeure affectant des milliers de robots aspirateurs DJI, alors qu’il bidouillait le sien pour voir s’il était possible de le commander à distance avec une manette de PS5.

Via cette porte dérobée, il devient en mesure de prendre le contrôle d’un robot aspirateur de son choix et donc d’accéder aux images que transmet le robot, simplement à l’aide de son numéro de série. Reproduite et racontée dans le détail par The Verge, sa découverte aboutit sur une conclusion effrayante : la prise de contrôle est possible parce que les robots de la marque communiquent en clair avec les serveurs MQTT de DJI, et que l’accès à ces derniers n’est pas dûment sécurisé.

Le 6 mars dernier, DJI a confirmé un problème de sécurité. Le constructeur a alors annoncé avoir corrigé une vulnérabilité au niveau de son infrastructure et évoqué, sans les nommer, la contribution de deux chercheurs indépendants. Sammy Azdoufal a de son côté indiqué avoir reçu la promesse d’un virement de 30 000 dollars dans le cadre du programme bug bounty de la marque.

Une application Android un peu trop bavarde

Ses travaux relatifs à Meari partent eux aussi d’une découverte fortuite, survenue le 2 mars dernier, avant même le dénouement de l’affaire DJI. « Je parlais de cette histoire d’aspirateur avec une collègue, elle m’explique qu’elle a acheté un babyphone sur Amazon, et se demande si c’est sûr de l’utiliser pour sa fille », nous raconte Sammy Azdoufal, contacté début mars. L’appareil fait partie des références premier prix vendues sur la plateforme.

Il ne dispose pas d’un environnement logiciel à ses couleurs mais fait appel à Cloudedge, une application « hub » dédiée aux objets connectés. En étudiant le code de l’application, le développeur découvre « plein de choses qui ne vont pas », dont des routes en clair vers des brokers MQTT : « J’essaie de me connecter pour voir, et là ça fonctionne ».

Avant d’aller plus loin, un petit point de vocabulaire s’impose peut-être. Dans le monde de l’Internet des objets (IoT), MQTT est un protocole de messagerie en étoile, qui sous-tend les échanges entre un serveur central (le broker MQTT dont il est question ici), et deux acteurs dont les rôles peuvent permuter : l’expéditeur (par exemple la caméra IP) et le destinataire (l’application mobile utilisée par son propriétaire). Quand votre caméra IP détecte un mouvement, elle envoie une alerte au broker MQTT, qui la relaie ensuite vers l’application mobile installée sur votre téléphone.

Dans le cas de l’application CloudEdge, nous avons pu vérifier début mars les affirmations de Sammy Azdoufal sur la base du client Android distribué via Google Play, et tout particulièrement la présence, en clair dans le code, d’une URL pointant vers la console d’administration du backend de Meari.

Le développeur pousse son investigation plus avant. « Après quelques tests, je me rends compte qu’ils ont laissé le mot de passe par défaut ». Une fois passée cette porte béante, « je réalise qu’il n’y a pas de vérification de la propriété par appareil, en m’abonnant à un broker je peux donc voir tout le monde ».

Dit autrement, une fois connecté au serveur, il est en mesure d’en observer l’activité, et par exemple d’y brancher le script grâce auquel il affirme avoir comptabilisé plus d’un million d’appareils connectés et donc vulnérables. Il indique également avoir pu accéder au CMS (l’outil de gestion du site Web) de Meari, utilisé notamment par les clients de l’entreprise pour gérer leurs propres flottes d’appareils ou leurs propres applications en marque blanche.

Errare microsoftum est

Microsoft prépare la mise en place d’une fonction intégrée à Windows Update capable de procéder à la récupération d’un pilote matériel si celui-ci n’offre pas le niveau de performances attendu. Cette récupération « initiée par le cloud » pourrait être déployée d’ici le mois de septembre.

S’il est indéniable que le processus des mises à jour de Windows 11 a souffert de quelques problèmes de contrôle qualité ces derniers mois, il faut reconnaître que les dysfonctionnements qui surviennent parfois lors d’une mise à jour ne sont pas toujours à mettre au crédit de Microsoft. Il n’est en effet pas rare que des problèmes de performance ou des plantages soient dus à la mise à jour d’un pilote matériel, dont la nouvelle version crée par exemple un conflit inédit sur la machine hôte.

On arguera légitimement que c’est précisément le rôle du contrôle qualité que d’éviter ces problèmes, mais nul n’étant infaillible, Microsoft vient d’annoncer la mise en place prochaine d’un dispositif automatisé de « récupération » de pilotes (recovery, soit une restauration vers une version fonctionnelle), initiée depuis ses serveurs, en cas de problème identifié pendant la phase de distribution d’une mise à jour.

Un retour à meilleure fortune déclenché à distance

Microsoft rappelle le fonctionnement du circuit de distribution actuel :

« Aujourd’hui, lorsqu’un pilote publié via Windows Update présente des problèmes de qualité après sa distribution, la solution repose soit sur le fournisseur de matériel qui soumet un pilote mis à jour, soit sur l’utilisateur final qui désinstalle manuellement le pilote problématique. Il en résulte un risque que des appareils restent avec un pilote de mauvaise qualité pendant une période prolongée ».

Le nouveau système vise à accélérer la réponse en cas de problème, et surtout à la rendre transparente pour l’utilisateur final.

« Grâce à la récupération de pilotes initiée par le cloud, Microsoft peut désormais déclencher une action de récupération directement depuis le centre de développement matériel et restaurer un pilote problématique à une version fonctionnelle antérieure via le pipeline Windows Update. Cette opération s’effectue par des mises à jour coordonnées de la pile de pilotes PnP [plug and play]et des services de déploiement et de publication des pilotes. »

Blocage préventif

Initiée par Microsoft, la récupération se fait donc soit sur la dernière version fonctionnelle, soit sur la meilleure alternative générique connue. Sur le papier, la réponse est élégante, mais son efficacité réelle va dépendre de la capacité de l’éditeur à détecter suffisamment tôt qu’un pilote dont le déploiement a été approuvé pose finalement des problèmes. C’est d’ailleurs tout l’objet du processus de déploiement progressif des pilotes et de ses différentes étapes de validation.

Microsoft explique par ailleurs introduire une protection supplémentaire au niveau de ce dispositif, avec la création d’une liste de blocage préventif des binaires ayant déjà posé des problèmes de fiabilité. « À l’avenir, si une soumission de signature contient un fichier figurant sur la liste de blocage de publication, elle sera rejetée avant la signature du pilote. Les partenaires recevront un message d’erreur identifiant le fichier problématique afin qu’ils puissent prendre les mesures correctives nécessaires », décrit l’éditeur.

La liste de blocage est censée entrer en vigueur courant mai 2026. La fonction de récupération de pilotes va quant à elle faire l’objet de tests entre mai et août, avant un déploiement programmé pour septembre 2026.

Rappelons que la fiabilité des pilotes sur Windows 11 est un sujet au long cours pour Microsoft. Il a notamment motivé le renforcement des conditions de validation WHCP (Windows Hardware Compatibility Program), un ménage dans les anciens pilotes, ainsi qu’une bascule encouragée (mais pas évidente) vers des pilotes écrits en Rust.

Errare microsoftum est

Microsoft prépare la mise en place d’une fonction intégrée à Windows Update capable de procéder à la récupération d’un pilote matériel si celui-ci n’offre pas le niveau de performances attendu. Cette récupération « initiée par le cloud » pourrait être déployée d’ici le mois de septembre.

S’il est indéniable que le processus des mises à jour de Windows 11 a souffert de quelques problèmes de contrôle qualité ces derniers mois, il faut reconnaître que les dysfonctionnements qui surviennent parfois lors d’une mise à jour ne sont pas toujours à mettre au crédit de Microsoft. Il n’est en effet pas rare que des problèmes de performance ou des plantages soient dus à la mise à jour d’un pilote matériel, dont la nouvelle version crée par exemple un conflit inédit sur la machine hôte.

On arguera légitimement que c’est précisément le rôle du contrôle qualité que d’éviter ces problèmes, mais nul n’étant infaillible, Microsoft vient d’annoncer la mise en place prochaine d’un dispositif automatisé de « récupération » de pilotes (recovery, soit une restauration vers une version fonctionnelle), initiée depuis ses serveurs, en cas de problème identifié pendant la phase de distribution d’une mise à jour.

Un retour à meilleure fortune déclenché à distance

Microsoft rappelle le fonctionnement du circuit de distribution actuel :

« Aujourd’hui, lorsqu’un pilote publié via Windows Update présente des problèmes de qualité après sa distribution, la solution repose soit sur le fournisseur de matériel qui soumet un pilote mis à jour, soit sur l’utilisateur final qui désinstalle manuellement le pilote problématique. Il en résulte un risque que des appareils restent avec un pilote de mauvaise qualité pendant une période prolongée ».

Le nouveau système vise à accélérer la réponse en cas de problème, et surtout à la rendre transparente pour l’utilisateur final.

« Grâce à la récupération de pilotes initiée par le cloud, Microsoft peut désormais déclencher une action de récupération directement depuis le centre de développement matériel et restaurer un pilote problématique à une version fonctionnelle antérieure via le pipeline Windows Update. Cette opération s’effectue par des mises à jour coordonnées de la pile de pilotes PnP [plug and play]et des services de déploiement et de publication des pilotes. »

Blocage préventif

Initiée par Microsoft, la récupération se fait donc soit sur la dernière version fonctionnelle, soit sur la meilleure alternative générique connue. Sur le papier, la réponse est élégante, mais son efficacité réelle va dépendre de la capacité de l’éditeur à détecter suffisamment tôt qu’un pilote dont le déploiement a été approuvé pose finalement des problèmes. C’est d’ailleurs tout l’objet du processus de déploiement progressif des pilotes et de ses différentes étapes de validation.

Microsoft explique par ailleurs introduire une protection supplémentaire au niveau de ce dispositif, avec la création d’une liste de blocage préventif des binaires ayant déjà posé des problèmes de fiabilité. « À l’avenir, si une soumission de signature contient un fichier figurant sur la liste de blocage de publication, elle sera rejetée avant la signature du pilote. Les partenaires recevront un message d’erreur identifiant le fichier problématique afin qu’ils puissent prendre les mesures correctives nécessaires », décrit l’éditeur.

La liste de blocage est censée entrer en vigueur courant mai 2026. La fonction de récupération de pilotes va quant à elle faire l’objet de tests entre mai et août, avant un déploiement programmé pour septembre 2026.

Rappelons que la fiabilité des pilotes sur Windows 11 est un sujet au long cours pour Microsoft. Il a notamment motivé le renforcement des conditions de validation WHCP (Windows Hardware Compatibility Program), un ménage dans les anciens pilotes, ainsi qu’une bascule encouragée (mais pas évidente) vers des pilotes écrits en Rust.