Le chien de Pandore

Robots aspirateurs, tondeuses connectées, caméras, sonnettes, capteurs… le célèbre Internet des objets offre des possibilités fascinantes pour améliorer le confort du foyer au quotidien, mais il se gagne bien souvent au prix de compromis aussi inacceptables que passés sous silence en matière de sécurité et de vie privée. Le problème n’est toutefois pas inéluctable… pour peu qu’on s’en empare.

Si j’étais de mauvaise foi, je dirais que tout ça c’est la faute du chien, mais comme en vrai il n’y est pour rien, il vaut mieux que je vous explique. Il se trouve que dans la vraie vie, j’ai trois jeunes enfants très dynamiques, et depuis dix-huit mois environ, un chien. Un épagneul breton, pedigree SPA. Comme tous les épagneuls bretons, il est sympa, têtu et un brin hyperactif. C’est-à-dire qu’il pionce la moitié de la journée, mais quand il se réveille, il se transforme en tornade, et pour peu qu’une baie vitrée soit ouverte après la pluie, le parquet du salon se retrouve rapidement constellé de traces de patte.

Ajoutez à ça qu’il perd toute l’année autant de poils qu’un mammouth laineux en pleine mue, et vous comprendrez que mon sol intérieur n’est pas exactement d’une propreté clinique. Perso, j’ai un seuil de tolérance assez élevé et je trouve ce petit tapis de poils plutôt confortable sous les pieds, surtout en hiver, mais il se trouve que je partage ma vie avec quelqu’un d’un peu moins dilettante sur le sujet, et que certains enfants donnent des signes d’allergie. Accessoirement, il y a un consensus familial : tout le monde déteste passer le balai. Bref, la paix du ménage passe par l’achat d’un aspirateur robot.

Sur le principe, je n’ai rien contre. Il se trouve que cet été, j’ai déjà entrepris de connecter certains éléments de la maison, histoire de programmer l’ouverture des volets le matin, ou d’éteindre à distance les lumières laissées allumées par les enfants quand ils s’endorment le nez dans leur bouquin. Je fais ça via Home Assistant, qui tourne sur un petit serveur domestique, et comme je suis tombé dans un véritable rabbit hole, je serais ravi d’intégrer un aspirateur robot dans les automatisations en cours de construction.

Mais des principes, j’en ai quelques-uns. En matière de domotique, le premier d’entre eux consiste à protéger mordicus le caractère privé de mon foyer : tous mes équipements doivent fonctionner en local. Ça n’exclut pas des possibilités de contrôle à distance, notamment pour la sécurité, mais ces dernières doivent être strictement cantonnées aux deux adultes de la maison.

Control freak ?

Pourquoi ériger ça en principe cardinal ? Mettez ça sur le compte d’une déformation professionnelle. Sur Next et ailleurs, j’ai eu l’occasion de couvrir à de multiples reprises des incidents de sécurité impliquant des objets connectés, avec à chaque fois de graves implications potentielles en matière de vie privée. Le dernier exemple en date vient d’être publié : des failles de sécurité exposaient complètement la gamme de robots tondeuse Mammotion. Un peu plus tôt cette année, j’ai eu l’occasion de relater en détail la découverte de vulnérabilités béantes au niveau d’une infrastructure gérant des centaines de milliers de caméras IP et de babyphones connectés à l’échelle mondiale.

Impossible, faute de temps, de les traiter systématiquement, mais la rédaction voit passer presque toutes les semaines des alertes de sécurité relatives à des objets connectés du quotidien.

Le phénomène m’inquiète à au moins trois titres. Le premier, c’est qu’il concerne aussi bien les produits chinois premier prix que les appareils vendus à prix d’or par des marques renommées. Outre Mammotion, et ses tondeuses à 2 000 euros, vous avez peut-être vu passer en début d’année cette info selon laquelle un développeur a découvert presque par inadvertance qu’il pouvait prendre le contrôle à distance de près de 7 000 aspirateurs robots haut de gamme DJI.

Le deuxième motif d’inquiétude, c’est que les constructeurs concernés réagissent avec une diligence toute relative aux alertes. Si DJI a très vite corrigé les failles de ses robots en se coordonnant avec l’auteur de la découverte, d’autres lambinent, et mettent des semaines, voire des mois, à combler des failles pourtant béantes. L’examen des vulnérabilités en question participe de mes angoisses : on ne parle pas d’attaques sophistiquées, menées à grands coups de rootkits et de virus. Non, les portes sont souvent liées à des identifiants laissés en clair dans le code et à l’oubli de protections pourtant basiques dans le monde des réseaux.

Le troisième point découle du deuxième, en lien avec les possibilités offertes par l’IA. Je ne parle pas des Mythos, Fable, Atlas et autres modèles de pointe qui alimentent les discours ambigus des acteurs spécialisés en matière de cybersécurité. Non, je fais référence à un Claude ou ChatGPT courant qui, correctement interrogé, est capable en quelques prompts de disséquer le code d’une application mobile pour en identifier tous les éléments problématiques. Je parle en connaissance de cause, puisque je l’ai fait pour contrôler certaines des allégations relatives aux failles de sécurité mentionnées plus haut, ou pour vérifier l’histoire de ce prestataire des dispensaires de cannabis qui stockait en clair les pièces d’identité de ses clients…

Le piège de la simplicité

Dans la grande famille des objets connectés, plusieurs ont besoin de « voir » chez moi pour faire leur boulot, à commencer bien sûr par les caméras de vidéosurveillance. Les robots aspirateurs ou robots tondeuses s’y mettent aussi : pour mieux détecter leur environnement, les meubles ou les objets laissés au sol, ils s’appuient sur des batteries de capteurs, notamment optiques. Cette capacité est attendue, et bienvenue, mais elle s’accompagne d’une zone d’ombre : où sont opérés les traitements informatiques nécessaires à la détection de mouvement de la caméra, ou à l’analyse des objets observés par le robot aspirateur ?

La question n’est pas anodine. Comme beaucoup, j’ai attaqué le sujet de la vidéosurveillance chez moi avec une caméra IP Wi-Fi chopée à l’occasion d’une promo sur Internet il y a quelques années. Pour l’utiliser, je devais passer par l’application mobile du constructeur : c’est elle qui permet de recevoir les images ou les alertes à distance. Lors de l’installation, je suis passé rapidement sur les conditions d’utilisation et le parcours d’explications qui mentionnaient vaguement une possibilité de stockage dans le cloud, pressé que j’étais d’en tester le fonctionnement. C’est après coup, au moment de me connecter pour la première fois à distance à la caméra, que je me suis dit « hey, mais au fait, elles passent par où les images ? ».

Mon illumination est rhétorique : je sais très bien que ces images transitent par un serveur distant (le cloud du fabricant), qui gère ensuite l’envoi d’une alerte sur mon téléphone. Ce qui est moins évident en revanche, c’est ce qu’il advient des images ainsi envoyées : sont-elles stockées, analysées, utilisées à des fins d’entraînement, ou autre ? Et accessoirement, qui peut y accéder ? Compte tenu des nombreuses failles évoquées plus haut, il y a un risque, difficile à mesurer mais confirmé par l’expérience, que des images de mon intérieur circulent auprès de personnes malintentionnées. Bon, à la rigueur, s’il s’agit du portrait d’un cambrioleur ou de la langue pendante du chien, je m’en remettrai. Mais si ce sont mes enfants qui déclenchent la détection de mouvement, c’est une autre paire de manches. Exit la caméra premier prix.

Il se trouve que moi, comme bon nombre de lecteurs de Next sans doute, je suis sensibilisé à ces questions. Je suis aussi en mesure de circonvenir le problème. Je dispose chez moi de l’équipement nécessaire pour créer un réseau local privé, coupé d’Internet. Mes nouvelles caméras IP envoient désormais leurs images vers mon serveur domestique, sur lequel un logiciel déconnecté d’Internet, Frigate, réalise la détection de mouvement et peut, au besoin, déclencher via Home Assistant une alerte vers nos deux téléphones.

Pour un geek, cette configuration n’est pas particulièrement complexe (un routeur capable de gérer plusieurs réseaux locaux, des caméras choisies pour leur capacité à travailler en local, un serveur domestique chargé de coordonner l’ensemble), mais elle n’est pas triviale. D’abord parce qu’elle suppose une réflexion préalable, et quelques heures de paramétrage. Ensuite, parce qu’elle représente un investissement financier non négligeable, de l’ordre de quelques centaines d’euros.

Revenons-en à nos poils de chien

Revenons à nos moutons, ou plutôt à nos poils de chien. Ce n’est jamais expliqué très clairement dans les modes d’emploi, mais les aspirateurs robots fonctionnent un peu comme les caméras IP : ils disposent de commandes locales (les boutons physiques par exemple) et parfois d’intégrations dans des applications domotiques (Home Assistant, Apple HomeKit), mais le plus souvent, les fonctions avancées (détection d’objets, programmation pièce par pièce) ne sont accessibles qu’au travers de l’application mobile du fabricant, soi-disant parce qu’elles supposent des traitements réalisés à distance, sur ses propres infrastructures informatiques.

Qu’à cela ne tienne, je vais faire comme avec mes caméras : chercher un modèle d’aspirateur répondant à mes attentes (capacité à vider son bac à poussières à sa base, serpillière, gestion d’une programmation à distance pièce par pièce, cartographie de la maison pour optimiser le parcours, intégration dans Home Assistant pour éviter l’enfermement dans un écosystème propriétaire), mais avec un fonctionnement exclusivement en local, c’est-à-dire isolé d’Internet.

La démarche est aussi un enjeu de pérennité : s’il tourne uniquement en local, mon robot est à l’abri d’une éventuelle panne du cloud, ou d’une fermeture décidée arbitrairement par son fabricant (n’est-ce pas, les éditeurs de jeux vidéo ?).

Bref, deux-trois recherches sur Internet devraient bien me permettre de trouver ça ? Que nenni.

J’ai d’abord consulté quelques tests récents de médias tech, pour essayer d’isoler un ou deux robots considérés comme de bons rapports qualité-prix, sachant que je ne souhaite pas dépenser une somme à quatre chiffres pour une serpillière à roulettes. J’ai bien noté quelques références intéressantes saluées pour leur autonomie, leur aspiration ou leur gestion des obstacles, mais aucun des articles concernés n’abordait la question de la confidentialité. Seule exception : les tests et actus consacrés à l’entreprise états-unienne Matic, qui revendique une approche privacy first, mais ne distribue pas ses robots sur le Vieux Continent.

Je me suis donc tourné vers les forums et Reddit, où d’autres se sont déjà posé la même question. Et j’ai découvert, un peu surpris, qu’il n’y avait pas de solution évidente. Ou plutôt, pas de solution sans compromis.

Je vous la fais courte : la quasi-totalité des robots du marché qui disposent de fonctionnalités avancées imposent l’utilisation de l’application dédiée, et donc l’exploitation de données dans le cloud. Les fabricants présentent généralement ça comme une nécessité technique, et assurent offrir des garanties de pseudonymisation, voire des flux chiffrés, mais ils refusent que l’on coupe le cordon.

À défaut, le robot est limité à des fonctions de base (qui peuvent se révéler suffisantes mais ne répondent pas à mes attentes). Certains modèles récents affichent une compatibilité avec la norme Matter pour permettre un contrôle local natif plus étendu, en Wi-Fi ou en Thread, mais là aussi le niveau de contrôle reste limité.

Pour celui ou celle qui voudrait aller plus loin, la voie la plus complète, mais aussi la plus complexe, consiste à rooter l’appareil (remplacer son logiciel par une alternative non officielle). Plusieurs modèles courants (Dreame, Ecovacs, Roborock, Eureka) peuvent être déverrouillés au moyen du firmware Valetudo, mais la manipulation revêt plus ou moins de complexité selon les robots.

Pour certains, un simple flash via un PC sous Linux suffit. Pour d’autres, il faut intervenir physiquement sur la carte mère et donc rompre les scellés de garantie. Il y a quelque chose d’assez satisfaisant dans le fait de voir qu’une initiative particulière permet de court-circuiter le verrouillage orchestré par toute une industrie, mais celle-ci n’est valable que sur certains modèles (et parfois même uniquement sur certaines générations d’un modèle donné), et la manipulation a de quoi refroidir bon nombre d’utilisateurs néophytes.

Si l’on écarte cette piste « expert », l’acquéreur potentiel de robot aspirateur se retrouve confronté à trois choix : accepter de laisser ses données circuler vers un cloud extérieur, tirer un trait sur une partie des fonctionnalités associées, ou tout simplement continuer à passer l’aspirateur à la main. En ces temps qui imposent de réfléchir à l’impact environnemental de la tech, la dernière n’est probablement pas la plus mauvaise des solutions.

Reste que si l’on souhaite tout de même s’équiper, l’industrie nous place face à un choix cornélien : fonctions avancées ou vie privée ? De mon côté, je sais que je ne transigerai pas. Je me prépare donc soit à chercher un robot à prix raisonnable susceptible de passer par la case Valetudo, soit à compromettre les relations diplomatiques familiales en opposant mon veto au robot.

De la nécessité d’informer correctement

Chacun prend bien les risques qu’il souhaite, tant qu’il les a correctement soupesés. Avant de m’équiper plus sérieusement, j’ai utilisé pendant quelques semaines mes caméras connectées avec la Chine, parce qu’elles me rendaient un service dont j’estimais avoir besoin, mais je l’ai fait de façon précautionneuse, en veillant à n’activer les appareils que quand la maison était vide de tout occupant.

Ce qui m’ennuie, et motive en réalité ce long laïus, ce sont tous les utilisateurs d’objets connectés qui acceptent tacitement d’exposer leur vie privée à un risque parce qu’on ne leur a pas expliqué la nature du risque en question. J’ai posé quelques questions naïves à des gens de mon entourage ces dernières semaines, en mode : « Au fait, tu es sûr que c’est sécurisé ton robot ? Il a quand même une caméra et des fonctions qui permettent d’en prendre le contrôle à distance ? ». Dans certains cas, j’ai eu droit à des réponses de type : « Ho ben oui, l’application est sur mon téléphone protégé par mot de passe, donc c’est sûr ».

Mauvaise réponse :/

La situation n’a cependant rien d’inéluctable.

Du côté des particuliers, il me semble primordial de sensibiliser sans relâche sur le sujet, et c’est bien sûr l’objectif premier de cet édito. Je prêche probablement des convaincus parmi les lecteurs assidus de Next, mais puisse ce texte contribuer à informer des internautes moins au fait des subtilités techniques de nos objets connectés.

Je profite de l’occasion pour en appeler à mes consœurs et confrères de la presse : bon nombre de médias consacrent d’innombrables news, tests et bons plans aux aspirateurs robots. Pourquoi ne pas intégrer à vos revues un paragraphe et des éléments de notation spécifiques au respect de la vie privée et à la confidentialité des données ? Vos tests y gagneraient en qualité, et n’y perdraient probablement pas tant que ça en conversion vers des liens affiliés.

Le dernier message s’adresse aux fabricants, avec un premier appel évident : quand allez-vous enfin prendre le mors aux dents et faire une passe complète d’audits sur vos outils afin d’en améliorer la sécurité ? Au-delà de cette simple mesure de bon sens, vous avez une carte à jouer en proposant des produits intelligents, mais véritablement respectueux de la vie privée. Plutôt que de simplement respecter a minima les exigences du RGPD ou du futur Cyber Resilience Act (CRA), faites de la confidentialité un argument commercial.

Si vous ne le faites pas pour vous, faites-le pour la paix de mon ménage !

Le chien de Pandore

Robots aspirateurs, tondeuses connectées, caméras, sonnettes, capteurs… le célèbre Internet des objets offre des possibilités fascinantes pour améliorer le confort du foyer au quotidien, mais il se gagne bien souvent au prix de compromis aussi inacceptables que passés sous silence en matière de sécurité et de vie privée. Le problème n’est toutefois pas inéluctable… pour peu qu’on s’en empare.

Si j’étais de mauvaise foi, je dirais que tout ça c’est la faute du chien, mais comme en vrai il n’y est pour rien, il vaut mieux que je vous explique. Il se trouve que dans la vraie vie, j’ai trois jeunes enfants très dynamiques, et depuis dix-huit mois environ, un chien. Un épagneul breton, pedigree SPA. Comme tous les épagneuls bretons, il est sympa, têtu et un brin hyperactif. C’est-à-dire qu’il pionce la moitié de la journée, mais quand il se réveille, il se transforme en tornade, et pour peu qu’une baie vitrée soit ouverte après la pluie, le parquet du salon se retrouve rapidement constellé de traces de patte.

Ajoutez à ça qu’il perd toute l’année autant de poils qu’un mammouth laineux en pleine mue, et vous comprendrez que mon sol intérieur n’est pas exactement d’une propreté clinique. Perso, j’ai un seuil de tolérance assez élevé et je trouve ce petit tapis de poils plutôt confortable sous les pieds, surtout en hiver, mais il se trouve que je partage ma vie avec quelqu’un d’un peu moins dilettante sur le sujet, et que certains enfants donnent des signes d’allergie. Accessoirement, il y a un consensus familial : tout le monde déteste passer le balai. Bref, la paix du ménage passe par l’achat d’un aspirateur robot.

Sur le principe, je n’ai rien contre. Il se trouve que cet été, j’ai déjà entrepris de connecter certains éléments de la maison, histoire de programmer l’ouverture des volets le matin, ou d’éteindre à distance les lumières laissées allumées par les enfants quand ils s’endorment le nez dans leur bouquin. Je fais ça via Home Assistant, qui tourne sur un petit serveur domestique, et comme je suis tombé dans un véritable rabbit hole, je serais ravi d’intégrer un aspirateur robot dans les automatisations en cours de construction.

Mais des principes, j’en ai quelques-uns. En matière de domotique, le premier d’entre eux consiste à protéger mordicus le caractère privé de mon foyer : tous mes équipements doivent fonctionner en local. Ça n’exclut pas des possibilités de contrôle à distance, notamment pour la sécurité, mais ces dernières doivent être strictement cantonnées aux deux adultes de la maison.

Control freak ?

Pourquoi ériger ça en principe cardinal ? Mettez ça sur le compte d’une déformation professionnelle. Sur Next et ailleurs, j’ai eu l’occasion de couvrir à de multiples reprises des incidents de sécurité impliquant des objets connectés, avec à chaque fois de graves implications potentielles en matière de vie privée. Le dernier exemple en date vient d’être publié : des failles de sécurité exposaient complètement la gamme de robots tondeuse Mammotion. Un peu plus tôt cette année, j’ai eu l’occasion de relater en détail la découverte de vulnérabilités béantes au niveau d’une infrastructure gérant des centaines de milliers de caméras IP et de babyphones connectés à l’échelle mondiale.

Impossible, faute de temps, de les traiter systématiquement, mais la rédaction voit passer presque toutes les semaines des alertes de sécurité relatives à des objets connectés du quotidien.

Le phénomène m’inquiète à au moins trois titres. Le premier, c’est qu’il concerne aussi bien les produits chinois premier prix que les appareils vendus à prix d’or par des marques renommées. Outre Mammotion, et ses tondeuses à 2 000 euros, vous avez peut-être vu passer en début d’année cette info selon laquelle un développeur a découvert presque par inadvertance qu’il pouvait prendre le contrôle à distance de près de 7 000 aspirateurs robots haut de gamme DJI.

Le deuxième motif d’inquiétude, c’est que les constructeurs concernés réagissent avec une diligence toute relative aux alertes. Si DJI a très vite corrigé les failles de ses robots en se coordonnant avec l’auteur de la découverte, d’autres lambinent, et mettent des semaines, voire des mois, à combler des failles pourtant béantes. L’examen des vulnérabilités en question participe de mes angoisses : on ne parle pas d’attaques sophistiquées, menées à grands coups de rootkits et de virus. Non, les portes sont souvent liées à des identifiants laissés en clair dans le code et à l’oubli de protections pourtant basiques dans le monde des réseaux.

Le troisième point découle du deuxième, en lien avec les possibilités offertes par l’IA. Je ne parle pas des Mythos, Fable, Atlas et autres modèles de pointe qui alimentent les discours ambigus des acteurs spécialisés en matière de cybersécurité. Non, je fais référence à un Claude ou ChatGPT courant qui, correctement interrogé, est capable en quelques prompts de disséquer le code d’une application mobile pour en identifier tous les éléments problématiques. Je parle en connaissance de cause, puisque je l’ai fait pour contrôler certaines des allégations relatives aux failles de sécurité mentionnées plus haut, ou pour vérifier l’histoire de ce prestataire des dispensaires de cannabis qui stockait en clair les pièces d’identité de ses clients…

Le piège de la simplicité

Dans la grande famille des objets connectés, plusieurs ont besoin de « voir » chez moi pour faire leur boulot, à commencer bien sûr par les caméras de vidéosurveillance. Les robots aspirateurs ou robots tondeuses s’y mettent aussi : pour mieux détecter leur environnement, les meubles ou les objets laissés au sol, ils s’appuient sur des batteries de capteurs, notamment optiques. Cette capacité est attendue, et bienvenue, mais elle s’accompagne d’une zone d’ombre : où sont opérés les traitements informatiques nécessaires à la détection de mouvement de la caméra, ou à l’analyse des objets observés par le robot aspirateur ?

La question n’est pas anodine. Comme beaucoup, j’ai attaqué le sujet de la vidéosurveillance chez moi avec une caméra IP Wi-Fi chopée à l’occasion d’une promo sur Internet il y a quelques années. Pour l’utiliser, je devais passer par l’application mobile du constructeur : c’est elle qui permet de recevoir les images ou les alertes à distance. Lors de l’installation, je suis passé rapidement sur les conditions d’utilisation et le parcours d’explications qui mentionnaient vaguement une possibilité de stockage dans le cloud, pressé que j’étais d’en tester le fonctionnement. C’est après coup, au moment de me connecter pour la première fois à distance à la caméra, que je me suis dit « hey, mais au fait, elles passent par où les images ? ».

Mon illumination est rhétorique : je sais très bien que ces images transitent par un serveur distant (le cloud du fabricant), qui gère ensuite l’envoi d’une alerte sur mon téléphone. Ce qui est moins évident en revanche, c’est ce qu’il advient des images ainsi envoyées : sont-elles stockées, analysées, utilisées à des fins d’entraînement, ou autre ? Et accessoirement, qui peut y accéder ? Compte tenu des nombreuses failles évoquées plus haut, il y a un risque, difficile à mesurer mais confirmé par l’expérience, que des images de mon intérieur circulent auprès de personnes malintentionnées. Bon, à la rigueur, s’il s’agit du portrait d’un cambrioleur ou de la langue pendante du chien, je m’en remettrai. Mais si ce sont mes enfants qui déclenchent la détection de mouvement, c’est une autre paire de manches. Exit la caméra premier prix.

Il se trouve que moi, comme bon nombre de lecteurs de Next sans doute, je suis sensibilisé à ces questions. Je suis aussi en mesure de circonvenir le problème. Je dispose chez moi de l’équipement nécessaire pour créer un réseau local privé, coupé d’Internet. Mes nouvelles caméras IP envoient désormais leurs images vers mon serveur domestique, sur lequel un logiciel déconnecté d’Internet, Frigate, réalise la détection de mouvement et peut, au besoin, déclencher via Home Assistant une alerte vers nos deux téléphones.

Pour un geek, cette configuration n’est pas particulièrement complexe (un routeur capable de gérer plusieurs réseaux locaux, des caméras choisies pour leur capacité à travailler en local, un serveur domestique chargé de coordonner l’ensemble), mais elle n’est pas triviale. D’abord parce qu’elle suppose une réflexion préalable, et quelques heures de paramétrage. Ensuite, parce qu’elle représente un investissement financier non négligeable, de l’ordre de quelques centaines d’euros.

Revenons-en à nos poils de chien

Revenons à nos moutons, ou plutôt à nos poils de chien. Ce n’est jamais expliqué très clairement dans les modes d’emploi, mais les aspirateurs robots fonctionnent un peu comme les caméras IP : ils disposent de commandes locales (les boutons physiques par exemple) et parfois d’intégrations dans des applications domotiques (Home Assistant, Apple HomeKit), mais le plus souvent, les fonctions avancées (détection d’objets, programmation pièce par pièce) ne sont accessibles qu’au travers de l’application mobile du fabricant, soi-disant parce qu’elles supposent des traitements réalisés à distance, sur ses propres infrastructures informatiques.

Qu’à cela ne tienne, je vais faire comme avec mes caméras : chercher un modèle d’aspirateur répondant à mes attentes (capacité à vider son bac à poussières à sa base, serpillière, gestion d’une programmation à distance pièce par pièce, cartographie de la maison pour optimiser le parcours, intégration dans Home Assistant pour éviter l’enfermement dans un écosystème propriétaire), mais avec un fonctionnement exclusivement en local, c’est-à-dire isolé d’Internet.

La démarche est aussi un enjeu de pérennité : s’il tourne uniquement en local, mon robot est à l’abri d’une éventuelle panne du cloud, ou d’une fermeture décidée arbitrairement par son fabricant (n’est-ce pas, les éditeurs de jeux vidéo ?).

Bref, deux-trois recherches sur Internet devraient bien me permettre de trouver ça ? Que nenni.

J’ai d’abord consulté quelques tests récents de médias tech, pour essayer d’isoler un ou deux robots considérés comme de bons rapports qualité-prix, sachant que je ne souhaite pas dépenser une somme à quatre chiffres pour une serpillière à roulettes. J’ai bien noté quelques références intéressantes saluées pour leur autonomie, leur aspiration ou leur gestion des obstacles, mais aucun des articles concernés n’abordait la question de la confidentialité. Seule exception : les tests et actus consacrés à l’entreprise états-unienne Matic, qui revendique une approche privacy first, mais ne distribue pas ses robots sur le Vieux Continent.

Je me suis donc tourné vers les forums et Reddit, où d’autres se sont déjà posé la même question. Et j’ai découvert, un peu surpris, qu’il n’y avait pas de solution évidente. Ou plutôt, pas de solution sans compromis.

Je vous la fais courte : la quasi-totalité des robots du marché qui disposent de fonctionnalités avancées imposent l’utilisation de l’application dédiée, et donc l’exploitation de données dans le cloud. Les fabricants présentent généralement ça comme une nécessité technique, et assurent offrir des garanties de pseudonymisation, voire des flux chiffrés, mais ils refusent que l’on coupe le cordon.

À défaut, le robot est limité à des fonctions de base (qui peuvent se révéler suffisantes mais ne répondent pas à mes attentes). Certains modèles récents affichent une compatibilité avec la norme Matter pour permettre un contrôle local natif plus étendu, en Wi-Fi ou en Thread, mais là aussi le niveau de contrôle reste limité.

Pour celui ou celle qui voudrait aller plus loin, la voie la plus complète, mais aussi la plus complexe, consiste à rooter l’appareil (remplacer son logiciel par une alternative non officielle). Plusieurs modèles courants (Dreame, Ecovacs, Roborock, Eureka) peuvent être déverrouillés au moyen du firmware Valetudo, mais la manipulation revêt plus ou moins de complexité selon les robots.

Pour certains, un simple flash via un PC sous Linux suffit. Pour d’autres, il faut intervenir physiquement sur la carte mère et donc rompre les scellés de garantie. Il y a quelque chose d’assez satisfaisant dans le fait de voir qu’une initiative particulière permet de court-circuiter le verrouillage orchestré par toute une industrie, mais celle-ci n’est valable que sur certains modèles (et parfois même uniquement sur certaines générations d’un modèle donné), et la manipulation a de quoi refroidir bon nombre d’utilisateurs néophytes.

Si l’on écarte cette piste « expert », l’acquéreur potentiel de robot aspirateur se retrouve confronté à trois choix : accepter de laisser ses données circuler vers un cloud extérieur, tirer un trait sur une partie des fonctionnalités associées, ou tout simplement continuer à passer l’aspirateur à la main. En ces temps qui imposent de réfléchir à l’impact environnemental de la tech, la dernière n’est probablement pas la plus mauvaise des solutions.

Reste que si l’on souhaite tout de même s’équiper, l’industrie nous place face à un choix cornélien : fonctions avancées ou vie privée ? De mon côté, je sais que je ne transigerai pas. Je me prépare donc soit à chercher un robot à prix raisonnable susceptible de passer par la case Valetudo, soit à compromettre les relations diplomatiques familiales en opposant mon veto au robot.

De la nécessité d’informer correctement

Chacun prend bien les risques qu’il souhaite, tant qu’il les a correctement soupesés. Avant de m’équiper plus sérieusement, j’ai utilisé pendant quelques semaines mes caméras connectées avec la Chine, parce qu’elles me rendaient un service dont j’estimais avoir besoin, mais je l’ai fait de façon précautionneuse, en veillant à n’activer les appareils que quand la maison était vide de tout occupant.

Ce qui m’ennuie, et motive en réalité ce long laïus, ce sont tous les utilisateurs d’objets connectés qui acceptent tacitement d’exposer leur vie privée à un risque parce qu’on ne leur a pas expliqué la nature du risque en question. J’ai posé quelques questions naïves à des gens de mon entourage ces dernières semaines, en mode : « Au fait, tu es sûr que c’est sécurisé ton robot ? Il a quand même une caméra et des fonctions qui permettent d’en prendre le contrôle à distance ? ». Dans certains cas, j’ai eu droit à des réponses de type : « Ho ben oui, l’application est sur mon téléphone protégé par mot de passe, donc c’est sûr ».

Mauvaise réponse :/

La situation n’a cependant rien d’inéluctable.

Du côté des particuliers, il me semble primordial de sensibiliser sans relâche sur le sujet, et c’est bien sûr l’objectif premier de cet édito. Je prêche probablement des convaincus parmi les lecteurs assidus de Next, mais puisse ce texte contribuer à informer des internautes moins au fait des subtilités techniques de nos objets connectés.

Je profite de l’occasion pour en appeler à mes consœurs et confrères de la presse : bon nombre de médias consacrent d’innombrables news, tests et bons plans aux aspirateurs robots. Pourquoi ne pas intégrer à vos revues un paragraphe et des éléments de notation spécifiques au respect de la vie privée et à la confidentialité des données ? Vos tests y gagneraient en qualité, et n’y perdraient probablement pas tant que ça en conversion vers des liens affiliés.

Le dernier message s’adresse aux fabricants, avec un premier appel évident : quand allez-vous enfin prendre le mors aux dents et faire une passe complète d’audits sur vos outils afin d’en améliorer la sécurité ? Au-delà de cette simple mesure de bon sens, vous avez une carte à jouer en proposant des produits intelligents, mais véritablement respectueux de la vie privée. Plutôt que de simplement respecter a minima les exigences du RGPD ou du futur Cyber Resilience Act (CRA), faites de la confidentialité un argument commercial.

Si vous ne le faites pas pour vous, faites-le pour la paix de mon ménage !

• lien nᵒ 1 : April
• lien nᵒ 2 : Revue de presse de l'April
• lien nᵒ 3 : Revue de presse de la semaine précédente
• lien nᵒ 4 : 🕸 Fils du Net

Commentaires : voir le flux Atom ouvrir dans le navigateur

Trois actualités à retenir cette semaine dans le cyberespace : une cyberattaque qui prive de télésurveillance les nouveaux pacemakers d'un géant de la santé, l'infrastructure de Linux à bout de souffle face aux scrapers IA, et des sessions Claude piratées qui alimentent un marché parallèle.

L’enquête lancée par la section cybercriminalité du parquet de Paris et confiée à l’office anti-cybercriminalité (Ofac) suite au piratage de la plateforme cet été de la Direction générale des finances publiques a débouché sur l’interpellation de deux suspects, rapporte Franceinfo.

Suite à son interpellation le 18 août, un homme de 18 ans a été mis en examen le 20 août et placé en détention provisoire. Un second suspect âgé de 16 ans, interpellé le 26 août, a été libéré après sa garde à vue. Son matériel sera cependant utilisé par les enquêteurs. Le premier suspect, domicilié en région parisienne, ferait partie du groupe de pirates ZeroBytes bien connu des services. Outre la DGFiP, il serait derrière les piratages ces derniers mois de l’Éducation nationale, France Travail, ou encore SFR.

Le suspect n’est pas un perdreau de l’année : il avait en effet été mis en examen en juin 2024 et janvier 2025 dans deux dossiers concernant des attaques informatiques, et placé sous contrôle judiciaire dans ces deux cas.

Il a été mis en examen pour les chefs d’accusation d’« accès et maintien frauduleux dans un système de traitement automatisé de données (STAD) à caractère personnel en bande organisée », pour « modification frauduleuse, extraction, transmission, reproduction et détention de données contenues dans un STAD à caractère personnel en bande organisée », ainsi que pour « participation à une association de malfaiteurs en vue de la préparation d’un délit puni de 10 ans d’emprisonnement ».

L’enquête se poursuit pour interpeller les autres personnes mises en cause dans le piratage du fisc.

• Troisième fuite confirmée aux impôts, Bercy détaille sa réponse aux attaques

L’enquête lancée par la section cybercriminalité du parquet de Paris et confiée à l’office anti-cybercriminalité (Ofac) suite au piratage de la plateforme cet été de la Direction générale des finances publiques a débouché sur l’interpellation de deux suspects, rapporte Franceinfo.

Suite à son interpellation le 18 août, un homme de 18 ans a été mis en examen le 20 août et placé en détention provisoire. Un second suspect âgé de 16 ans, interpellé le 26 août, a été libéré après sa garde à vue. Son matériel sera cependant utilisé par les enquêteurs. Le premier suspect, domicilié en région parisienne, ferait partie du groupe de pirates ZeroBytes bien connu des services. Outre la DGFiP, il serait derrière les piratages ces derniers mois de l’Éducation nationale, France Travail, ou encore SFR.

Le suspect n’est pas un perdreau de l’année : il avait en effet été mis en examen en juin 2024 et janvier 2025 dans deux dossiers concernant des attaques informatiques, et placé sous contrôle judiciaire dans ces deux cas.

Il a été mis en examen pour les chefs d’accusation d’« accès et maintien frauduleux dans un système de traitement automatisé de données (STAD) à caractère personnel en bande organisée », pour « modification frauduleuse, extraction, transmission, reproduction et détention de données contenues dans un STAD à caractère personnel en bande organisée », ainsi que pour « participation à une association de malfaiteurs en vue de la préparation d’un délit puni de 10 ans d’emprisonnement ».

L’enquête se poursuit pour interpeller les autres personnes mises en cause dans le piratage du fisc.

• Troisième fuite confirmée aux impôts, Bercy détaille sa réponse aux attaques

Fake IT crowd

Les scammers migrent de plus en plus de l’email vers les plateformes de collaboration d’entreprise comme Microsoft Teams pour mettre en place leurs attaques. En se faisant passer pour le support informatique, ils peuvent aller très loin dans l’infrastructure de l’entreprise visée.

Le laboratoire de recherche en cybersécurité Unit 42 de l’entreprise Palo Alto Networks a alerté ce mardi 1er septembre : des pirates ont mis en place des campagnes pour cibler le système informatique d’entreprises via des appels vocaux sur Microsoft Teams.

Comme souvent quand il s’agit de scam, les pirates utilisent leurs compétences en social engineering. « Ce qui semble être une conversation anodine est en réalité un appel de hameçonnage vocal (vishing), au cours duquel les cybercriminels tentent de contraindre leurs victimes à exécuter des outils de surveillance et de gestion à distance (RMM) ou des virus sur mesure », explique Unit 42.

Utiliser le pouvoir social du support informatique

Notamment, pour que l’utilisateur se laisse manipuler, les pirates se font passer pour le support informatique de l’entreprise. Les chercheurs de Palo Alto Networks signalent avoir repéré une campagne particulière, qu’ils nomment Spring Ring, qui a ciblé entre janvier et avril 2026 plus de 150 employés d’au moins 10 entreprises. Pour certains, les pirates sont allés jusqu’à essayer d’atteindre le contrôleur de domaine de l’entreprise, le serveur qui permet de répondre aux demandes d’authentification et donne les accès aux employés.

Pour Unit 42, cette campagne illustre « la manière dont les plateformes de communication sont utilisées comme armes, l’identité devenant un vecteur d’attaque majeur ».

Les chercheurs de Unit 42 expliquent qu’ils ont détecté cette campagne après avoir observé un schéma suspect de création de discussions. De fait, l’attaque passe d’abord en chat où l’attaquant crée une discussion sous une identité qui semble demander une attention particulière (service d’assistance informatique ou personnel de support) avec un email au domaine proche de Microsoft (ici .onmicrosoft[.]com) et dont il maitrise le sous-domaine (par exemple : ithelp@InternalSystemsDaily[.]onmicrosoft[.]com).

L’attaquant lançait ensuite un appel audio pour lui faire faire des actions présentées comme de l’assistance technique. En fait, l’utilisateur lui donnait le contrôle à distance ou exécutait un virus sans le savoir. Pour mettre la pression sur l’utilisateur, l’attaquant peut appeler plusieurs fois si l’utilisateur ne répond pas.

Deux formes d’attaques : le contrôle à distance ou l’envoi vers un faux cloud de l’entreprise

Lors de la campagne Spring Ring, Unit 42 a repéré deux formes d’attaques. Dans la première, l’attaquant incite la victime à exécuter le logiciel de gestion à distance de son entreprise et ensuite à lui donner le contrôle à distance de son ordinateur. Après avoir vérifié les informations sur l’environnement, il utilise PowerShell pour télécharger un cheval de Troie à distance qui désactive l’antivirus, envoie des données de l’utilisateur et récupère ensuite d’autres virus.

Dans l’autre forme d’attaque, le pirate envoie l’employé vers un lien pointant vers un faux cloud de son entreprise, téléchargeant un virus dont l’exécutable mentionnait le nom de cette entreprise (par exemple : nomdelentreprise-org-filters-update-nomdelavictime.exe). Dès que celui-ci est exécuté, il assure sa persistance dans le système de Windows. Puis il lance une instance cachée et sans interface graphique de Edge pour installer une extension du navigateur de Microsoft. Un script Python est enfin lancé pour scanner les ports SMB, cibler le contrôleur de domaine de l’entreprise via Microsoft NT LAN Manager et tenter « une attaque avec PetitPotam [une preuve de concept (PoC) permettant de forcer des hôtes Windows à s’authentifier auprès d’autres machines, ndlr] afin de contraindre le contrôleur de domaine à s’authentifier auprès d’une machine contrôlée par l’attaquant ».

Pour l’Unit 42, cette campagne montre un « tournant stratégique en matière d’ingénierie sociale, les attaquants allant désormais au-delà du hameçonnage par e-mail pour cibler les outils de collaboration d’entreprise ».

Microsoft alerte aussi

Cela semble aussi le cas du côté de Microsoft. En effet, quelques jours plus tard, les chercheurs de l’entreprise de Redmond ont décrit le même genre d’attaques utilisant les outils de surveillance et de gestion à distance. Ici, PowerShell était utilisé pour télécharger un paquet MSI malveillant qui met ensuite en place un environnement Node.js et un script JavaScript permettant, de façon persistante, l’exécution de commandes.

L’éditeur de Teams semble désemparé devant ce genre d’attaques, affirmant que « cette campagne repose moins sur l’exploitation de la plateforme que sur la persuasion des utilisateurs de mettre en place des processus d’accès à distance sécurisés au sein d’outils de collaboration légitimes ». Microsoft ajoute que les entreprises « doivent considérer toute demande d’assistance externe non sollicitée comme intrinsèquement suspecte et mettre en place des défenses à plusieurs niveaux, couvrant l’identité, les terminaux et la collaboration ».

Dans ses conseils, en plus du renfort de la sensibilisation des employés, Microsoft pousse quand même à utiliser des outils contre les attaques de type « ingénierie sociale », contre le phishing en général, et d’activer les règles ASR de réduction de la surface d’attaque « qui bloquent le contenu exécutable provenant des e-mails et des interpréteurs de scripts, la création de processus à partir de PowerShell/WScript/cmd, ainsi que l’exécution de contenu téléchargé, afin d’empêcher la mise en place de scripts et de fichiers MSI ». L’éditeur pousse aussi les DSI des entreprises à limiter ou surveiller l’utilisation des logiciels de gestion (et d’assistance) à distance et à contrôler quels outils sont autorisés dans leurs environnements.

Fake IT crowd

Les scammers migrent de plus en plus de l’email vers les plateformes de collaboration d’entreprise comme Microsoft Teams pour mettre en place leurs attaques. En se faisant passer pour le support informatique, ils peuvent aller très loin dans l’infrastructure de l’entreprise visée.

Le laboratoire de recherche en cybersécurité Unit 42 de l’entreprise Palo Alto Networks a alerté ce mardi 1er septembre : des pirates ont mis en place des campagnes pour cibler le système informatique d’entreprises via des appels vocaux sur Microsoft Teams.

Comme souvent quand il s’agit de scam, les pirates utilisent leurs compétences en social engineering. « Ce qui semble être une conversation anodine est en réalité un appel de hameçonnage vocal (vishing), au cours duquel les cybercriminels tentent de contraindre leurs victimes à exécuter des outils de surveillance et de gestion à distance (RMM) ou des virus sur mesure », explique Unit 42.

Utiliser le pouvoir social du support informatique

Notamment, pour que l’utilisateur se laisse manipuler, les pirates se font passer pour le support informatique de l’entreprise. Les chercheurs de Palo Alto Networks signalent avoir repéré une campagne particulière, qu’ils nomment Spring Ring, qui a ciblé entre janvier et avril 2026 plus de 150 employés d’au moins 10 entreprises. Pour certains, les pirates sont allés jusqu’à essayer d’atteindre le contrôleur de domaine de l’entreprise, le serveur qui permet de répondre aux demandes d’authentification et donne les accès aux employés.

Pour Unit 42, cette campagne illustre « la manière dont les plateformes de communication sont utilisées comme armes, l’identité devenant un vecteur d’attaque majeur ».

Les chercheurs de Unit 42 expliquent qu’ils ont détecté cette campagne après avoir observé un schéma suspect de création de discussions. De fait, l’attaque passe d’abord en chat où l’attaquant crée une discussion sous une identité qui semble demander une attention particulière (service d’assistance informatique ou personnel de support) avec un email au domaine proche de Microsoft (ici .onmicrosoft[.]com) et dont il maitrise le sous-domaine (par exemple : ithelp@InternalSystemsDaily[.]onmicrosoft[.]com).

L’attaquant lançait ensuite un appel audio pour lui faire faire des actions présentées comme de l’assistance technique. En fait, l’utilisateur lui donnait le contrôle à distance ou exécutait un virus sans le savoir. Pour mettre la pression sur l’utilisateur, l’attaquant peut appeler plusieurs fois si l’utilisateur ne répond pas.

Deux formes d’attaques : le contrôle à distance ou l’envoi vers un faux cloud de l’entreprise

Lors de la campagne Spring Ring, Unit 42 a repéré deux formes d’attaques. Dans la première, l’attaquant incite la victime à exécuter le logiciel de gestion à distance de son entreprise et ensuite à lui donner le contrôle à distance de son ordinateur. Après avoir vérifié les informations sur l’environnement, il utilise PowerShell pour télécharger un cheval de Troie à distance qui désactive l’antivirus, envoie des données de l’utilisateur et récupère ensuite d’autres virus.

Dans l’autre forme d’attaque, le pirate envoie l’employé vers un lien pointant vers un faux cloud de son entreprise, téléchargeant un virus dont l’exécutable mentionnait le nom de cette entreprise (par exemple : nomdelentreprise-org-filters-update-nomdelavictime.exe). Dès que celui-ci est exécuté, il assure sa persistance dans le système de Windows. Puis il lance une instance cachée et sans interface graphique de Edge pour installer une extension du navigateur de Microsoft. Un script Python est enfin lancé pour scanner les ports SMB, cibler le contrôleur de domaine de l’entreprise via Microsoft NT LAN Manager et tenter « une attaque avec PetitPotam [une preuve de concept (PoC) permettant de forcer des hôtes Windows à s’authentifier auprès d’autres machines, ndlr] afin de contraindre le contrôleur de domaine à s’authentifier auprès d’une machine contrôlée par l’attaquant ».

Pour l’Unit 42, cette campagne montre un « tournant stratégique en matière d’ingénierie sociale, les attaquants allant désormais au-delà du hameçonnage par e-mail pour cibler les outils de collaboration d’entreprise ».

Microsoft alerte aussi

Cela semble aussi le cas du côté de Microsoft. En effet, quelques jours plus tard, les chercheurs de l’entreprise de Redmond ont décrit le même genre d’attaques utilisant les outils de surveillance et de gestion à distance. Ici, PowerShell était utilisé pour télécharger un paquet MSI malveillant qui met ensuite en place un environnement Node.js et un script JavaScript permettant, de façon persistante, l’exécution de commandes.

L’éditeur de Teams semble désemparé devant ce genre d’attaques, affirmant que « cette campagne repose moins sur l’exploitation de la plateforme que sur la persuasion des utilisateurs de mettre en place des processus d’accès à distance sécurisés au sein d’outils de collaboration légitimes ». Microsoft ajoute que les entreprises « doivent considérer toute demande d’assistance externe non sollicitée comme intrinsèquement suspecte et mettre en place des défenses à plusieurs niveaux, couvrant l’identité, les terminaux et la collaboration ».

Dans ses conseils, en plus du renfort de la sensibilisation des employés, Microsoft pousse quand même à utiliser des outils contre les attaques de type « ingénierie sociale », contre le phishing en général, et d’activer les règles ASR de réduction de la surface d’attaque « qui bloquent le contenu exécutable provenant des e-mails et des interpréteurs de scripts, la création de processus à partir de PowerShell/WScript/cmd, ainsi que l’exécution de contenu téléchargé, afin d’empêcher la mise en place de scripts et de fichiers MSI ». L’éditeur pousse aussi les DSI des entreprises à limiter ou surveiller l’utilisation des logiciels de gestion (et d’assistance) à distance et à contrôler quels outils sont autorisés dans leurs environnements.

Christine de Stephen King, version tondeuse à gazon

Trois chercheurs indépendants en cybersécurité ont découvert 14 failles de sécurité critiques au sein de l’infrastructure qui sous-tend le fonctionnement des robots tondeuses Mammotion. Elles exposaient potentiellement jusqu’à 337 000 comptes utilisateurs, ouvraient l’accès aux infos des réseaux connectés, et permettaient accessoirement la prise de contrôle à distance.

Un gazon sans doute coupé au cordeau, mais une véritable porte ouverte sur le jardin. Trois chercheurs en cybersécurité se sont penchés sur l’application mobile fournie par Mammotion pour le pilotage de ses robots tondeuses.

Ils y ont découvert comment accéder en seulement deux requêtes à un compte admin branché sur l’infrastructure cloud qui en sous tend les fonctions connectées. De là, les failles se sont enchaînées, jusqu’à représenter un total de 14 vulnérabilités, présentées dans un rapport dédié.

Des robots ouverts aux quatre vents

À l’appui de leurs travaux, les trois chercheurs, Sammy Azdoufal (@n0tsa), Andreas Makris (@Bin4ryDigit) et Kevin Finisterre (@d0tslash), ont réalisé une attaque par piratage de compte sur un robot tondeuse détenu en propre. Ils revendiquent une prise de contrôle quasi totale, avec possibilité de piloter le robot à distance et visualiser les images transmises par la caméra.

S’ils affirment ne pas avoir avoir parcouru l’ensemble des services cloud exposés, ils donnent un aperçu de la surface potentielle de l’attaque, estimée à 337 000 comptes utilisateurs énumérables sans authentification, répartis sur quatre serveurs régionaux, dont un serveur EU servant 85 pays, avec une « forte concentration en Allemagne, France et Suède ». Sammy Azdoufal, qui avait déjà mis au jour les failles de sécurité béantes des babyphones et caméras IP Meari et dix CVE dans des produits connectés Aqara, précise à Next qu’environ 49 000 comptes correspondent à des utilisateurs français.

Pour chaque appareil, l’accès découvert donnait selon eux la possibilité d’interroger le robot à distance et d’en faire remonter, sans vérification de propriété, les informations réseau telles que les coordonnées GPS, l’adresse IP sur le réseau local, l’adresse MAC, ou l’IMEI de la connexion mobile, mais aussi le SSID du Wi-Fi domestique, et le numéro IMSI de la carte SIM utilisée pour les communications en cas d’absence de Wi-Fi.

Les chercheurs affirment par ailleurs avoir pu énumérer 46 785 stations RTK dont les clés de chiffrement RSA-2048 étaient récupérables sans vérification de propriété. Ces stations sont un accessoire commercialisé par Mammotion (et d’autres fabricants) pour offrir une référence de positionnement plus précise que celle du GPS et donc améliorer la capacité du robot tondeuse à s’orienter dans le jardin ou respecter les instructions de tonte.

« La flotte RTK européenne de Mammotion fonctionne avec des cartes SIM M2M d’Orange France. Chaque station de base équipée d’un module 4G (IMSI 208012xxxxxxx) transmet des données d’identité cellulaire à tout utilisateur authentifié de l’application », affirment à ce sujet les chercheurs.

Si les données GPS d’un robot individuel suffisent pour localiser son emplacement, les chercheurs suggèrent, sans l’affirmer explicitement, que l’exposition de cette infrastructure de communication mobile ouvrait la voie à des attaques à plus grande échelle.

Une communication assez limitée

La première et peut-être la plus inquiétante découverte tient à la façon dont les chercheurs ont pu accéder au cloud de Mammotion. D’après leur rapport, le fabricant référençait dans son application un endpoint (un point de terminaison pour se connecter à l’infra) lié à son serveur situé en Chine qui retournait, sans authentification ou token préalable, un mot de passe à usage unique (on parle de code OTP, pour One-Time Password), qui en réalité n’expirait pas.

Ce code à usage unique est lié à la récupération en cas de mot de passe oublié. Pour un utilisateur lambda, il faut en principe une demande de réinitialisation pour que ce code soit généré, puis reconnu au niveau du endpoint. « Pour admin@mammotion.com, la situation était différente. L’administrateur n’avait apparemment jamais déclenché sa propre procédure de mot de passe oublié ; son code OTP enregistré n’avait donc ni durée de vie ni renouvellement. Il était juste là », décrivent les trois auteurs, avant de résumer : « Deux requêtes HTTP non authentifiées et vous possédez le compte administrateur Mammotion ».

Le dépôt GitHub créé pour l’occasion liste également les échanges par écrit entre les trois chercheurs et les services techniques de Mammotion. La conversation achoppe principalement sur des questions de forme, peut-être motivées par le passif de Kevin Finisterre avec la marque, quelques années plus tôt. Ce dernier s’était en effet inquiété de voir un service SSH tourner sur son robot, et avait donc demandé à la marque le mot de passe permettant de s’y connecter pour investiguer le sujet. Il s’était vu opposer une fin de non recevoir.

D’après la transcription publiée dans ce rapport, Mammotion indique avoir pris en compte les remarques des chercheurs et implémenté des « mesures de protection » adaptées. Affirmant travailler avec des institutions externes dédiées à la sécurité, elle a en revanche refusé d’ouvrir un canal technique avec les intéressés qui réclamaient la mise en place d’un processus de divulgation responsable. Elle ne livre par ailleurs aucune réponse sur le fond, mais a tout de même fini par corriger les failles les plus sérieuses. C’est ce constat qui a conduit les trois auteurs à publier leur rapport, daté du 21 août et mis en ligne sur GitHub le 24 août dernier.

Leurs conclusions relèvent d’ailleurs que trois problèmes restent en suspens : un secret codé en dur dans un élément JavaScript public, un processus d’auto-enregistrement de clients avec une adresse de redirection arbitraire ouvrant, par exemple, la voie à des tentatives de phishing, et des sous domaines internes résolus via des DNS publics.

Sur sa page de support, Mammotion s’engage à assurer des mises à jour de sécurité continues pour tous ses produits pendant les cinq ans qui suivent leur mise sur le marché. Contactée par nos soins le 24 août et relancée depuis, l’entreprise n’a pas répondu à nos questions.

Christine de Stephen King, version tondeuse à gazon

Trois chercheurs indépendants en cybersécurité ont découvert 14 failles de sécurité critiques au sein de l’infrastructure qui sous-tend le fonctionnement des robots tondeuses Mammotion. Elles exposaient potentiellement jusqu’à 337 000 comptes utilisateurs, ouvraient l’accès aux infos des réseaux connectés, et permettaient accessoirement la prise de contrôle à distance.

Un gazon sans doute coupé au cordeau, mais une véritable porte ouverte sur le jardin. Trois chercheurs en cybersécurité se sont penchés sur l’application mobile fournie par Mammotion pour le pilotage de ses robots tondeuses.

Ils y ont découvert comment accéder en seulement deux requêtes à un compte admin branché sur l’infrastructure cloud qui en sous tend les fonctions connectées. De là, les failles se sont enchaînées, jusqu’à représenter un total de 14 vulnérabilités, présentées dans un rapport dédié.

Des robots ouverts aux quatre vents

À l’appui de leurs travaux, les trois chercheurs, Sammy Azdoufal (@n0tsa), Andreas Makris (@Bin4ryDigit) et Kevin Finisterre (@d0tslash), ont réalisé une attaque par piratage de compte sur un robot tondeuse détenu en propre. Ils revendiquent une prise de contrôle quasi totale, avec possibilité de piloter le robot à distance et visualiser les images transmises par la caméra.

S’ils affirment ne pas avoir avoir parcouru l’ensemble des services cloud exposés, ils donnent un aperçu de la surface potentielle de l’attaque, estimée à 337 000 comptes utilisateurs énumérables sans authentification, répartis sur quatre serveurs régionaux, dont un serveur EU servant 85 pays, avec une « forte concentration en Allemagne, France et Suède ». Sammy Azdoufal, qui avait déjà mis au jour les failles de sécurité béantes des babyphones et caméras IP Meari et dix CVE dans des produits connectés Aqara, précise à Next qu’environ 49 000 comptes correspondent à des utilisateurs français.

Pour chaque appareil, l’accès découvert donnait selon eux la possibilité d’interroger le robot à distance et d’en faire remonter, sans vérification de propriété, les informations réseau telles que les coordonnées GPS, l’adresse IP sur le réseau local, l’adresse MAC, ou l’IMEI de la connexion mobile, mais aussi le SSID du Wi-Fi domestique, et le numéro IMSI de la carte SIM utilisée pour les communications en cas d’absence de Wi-Fi.

Les chercheurs affirment par ailleurs avoir pu énumérer 46 785 stations RTK dont les clés de chiffrement RSA-2048 étaient récupérables sans vérification de propriété. Ces stations sont un accessoire commercialisé par Mammotion (et d’autres fabricants) pour offrir une référence de positionnement plus précise que celle du GPS et donc améliorer la capacité du robot tondeuse à s’orienter dans le jardin ou respecter les instructions de tonte.

« La flotte RTK européenne de Mammotion fonctionne avec des cartes SIM M2M d’Orange France. Chaque station de base équipée d’un module 4G (IMSI 208012xxxxxxx) transmet des données d’identité cellulaire à tout utilisateur authentifié de l’application », affirment à ce sujet les chercheurs.

Si les données GPS d’un robot individuel suffisent pour localiser son emplacement, les chercheurs suggèrent, sans l’affirmer explicitement, que l’exposition de cette infrastructure de communication mobile ouvrait la voie à des attaques à plus grande échelle.

Une communication assez limitée

La première et peut-être la plus inquiétante découverte tient à la façon dont les chercheurs ont pu accéder au cloud de Mammotion. D’après leur rapport, le fabricant référençait dans son application un endpoint (un point de terminaison pour se connecter à l’infra) lié à son serveur situé en Chine qui retournait, sans authentification ou token préalable, un mot de passe à usage unique (on parle de code OTP, pour One-Time Password), qui en réalité n’expirait pas.

Ce code à usage unique est lié à la récupération en cas de mot de passe oublié. Pour un utilisateur lambda, il faut en principe une demande de réinitialisation pour que ce code soit généré, puis reconnu au niveau du endpoint. « Pour admin@mammotion.com, la situation était différente. L’administrateur n’avait apparemment jamais déclenché sa propre procédure de mot de passe oublié ; son code OTP enregistré n’avait donc ni durée de vie ni renouvellement. Il était juste là », décrivent les trois auteurs, avant de résumer : « Deux requêtes HTTP non authentifiées et vous possédez le compte administrateur Mammotion ».

Le dépôt GitHub créé pour l’occasion liste également les échanges par écrit entre les trois chercheurs et les services techniques de Mammotion. La conversation achoppe principalement sur des questions de forme, peut-être motivées par le passif de Kevin Finisterre avec la marque, quelques années plus tôt. Ce dernier s’était en effet inquiété de voir un service SSH tourner sur son robot, et avait donc demandé à la marque le mot de passe permettant de s’y connecter pour investiguer le sujet. Il s’était vu opposer une fin de non recevoir.

D’après la transcription publiée dans ce rapport, Mammotion indique avoir pris en compte les remarques des chercheurs et implémenté des « mesures de protection » adaptées. Affirmant travailler avec des institutions externes dédiées à la sécurité, elle a en revanche refusé d’ouvrir un canal technique avec les intéressés qui réclamaient la mise en place d’un processus de divulgation responsable. Elle ne livre par ailleurs aucune réponse sur le fond, mais a tout de même fini par corriger les failles les plus sérieuses. C’est ce constat qui a conduit les trois auteurs à publier leur rapport, daté du 21 août et mis en ligne sur GitHub le 24 août dernier.

Leurs conclusions relèvent d’ailleurs que trois problèmes restent en suspens : un secret codé en dur dans un élément JavaScript public, un processus d’auto-enregistrement de clients avec une adresse de redirection arbitraire ouvrant, par exemple, la voie à des tentatives de phishing, et des sous domaines internes résolus via des DNS publics.

Sur sa page de support, Mammotion s’engage à assurer des mises à jour de sécurité continues pour tous ses produits pendant les cinq ans qui suivent leur mise sur le marché. Contactée par nos soins le 24 août et relancée depuis, l’entreprise n’a pas répondu à nos questions.

C'est l'hôpital qui se fout de la sécurité

Il y a un an, un pirate a pu accéder aux données de 524 867 patients et 202 246 tiers de confiance de l’Hôpital privé de Loire via son système de dossier patient informatisé. La CNIL a choisi de sanctionner cet établissement de soin privé car celui-ci a été particulièrement négligent : absence de VPN, de moyen d’authentification multifacteur, mais aussi mot de passe temporaire identique pour l’ensemble des praticiens après la violation de données.

C’est une sanction de 500 000 euros d’amende que la CNIL a infligée ce jeudi 3 septembre à l’Hôpital privé de la Loire, un établissement du groupe Ramsay Santé.

La CNIL n’a pas pour habitude de sanctionner fortement des structures comme les hôpitaux, elle préfère souvent les accompagner dans une démarche de meilleure sécurisation de leurs infrastructures. Mais là, il semble que les manquements de sécurité de cet hôpital aient largement dépassé les bornes de ce que l’autorité peut laisser passer sans sanction concernant la mauvaise protection de données de santé.

Dans sa délibération, la CNIL explique que cet hôpital a été victime d’une violation de données de son dossier patient informatisé (DPI) en juin 2025. L’attaquant s’est connecté au DPI via les identifiants d’un médecin libéral rattaché à la structure.

Entre le 26 juin et le 1er juillet 2025, il a « procédé à l’exfiltration de 524 867 fiches patients contenant des informations telles que l’état civil, le numéro de sécurité sociale, les coordonnées postales et électroniques et le numéro d’identifiant permanent des patients concernés ». Plus de 46 000 de ces fiches étaient aussi associées au recto de la carte d’identité et plus de 202 000 comportaient des données relatives à la personne de confiance désignée par le patient. Enfin, 43 fiches comportaient des données de santé.

Pas de VPN ni d’authentification à 2 facteurs

Dans sa décision, la CNIL souligne « que l’obligation de sécurité prévue par l’article 32 du RGPD est une obligation de moyens ». Or, sa rapporteure « reproche à l’hôpital de ne pas avoir mis en place des mesures appropriées pour sécuriser l’accès au DPI des utilisateurs externes ». En effet, au moment de la violation de données, cet accès s’effectuait grâce à un identifiant et un mot de passe mais « sans connexion préalable à un VPN, ni moyen d’identification électronique à deux facteurs ».

Un référentiel de sécurité relatif à l’identification électronique des utilisateurs des services numériques en santé existe pourtant depuis la publication d’un arrêté le 28 mars 2022. Et celui-ci demande bien expressément de mettre en place ces dispositifs pour sécuriser les connexions extérieures.

La rapporteure souligne que, justement, l’attaquant a exploité cette vulnérabilité pour accéder au dossier patient informatisé de l’hôpital et extraire les données qu’il contenait.

Pas de surveillance automatique des logs

Autre reproche : l’hôpital n’avait pris aucune mesure d’analyse automatisée des journaux d’évènements permettant de repérer des activités inhabituelles sur le DPI. En effet, si la structure hospitalière avait mis en place un centre des opérations de sécurité (SOC), un système de supervision et un système de journalisation avec enregistrement des traces applicatives, elle n’avait pas activé l’analyse automatique en temps réel des traces applicatives du DPI.

« Cette carence de surveillance a permis à l’attaquant d’effectuer un nombre extrêmement élevé de requêtes au sein du DPI de l’hôpital pendant près d’une semaine », souligne la rapporteure. La CNIL montre d’ailleurs, après analyse des logs, que l’activité de l’attaquant aurait sans doute été détectée par un système automatisé : pendant la phase d’extraction automatique mise en place par l’attaquant, son système consultait une moyenne de 73 fiches de patients par minute.

Un mot de passe temporaire pour tous

Et ce n’est pas tout. La CNIL pointe une mauvaise pratique mise en place par l’hôpital pour atténuer les effets de l’attaque. En effet, celui-ci a enclenché une procédure de réinitialisation des mots de passe. Mais celle-ci était pour le moins problématique : elle a consisté « à attribuer un mot de passe temporaire identique à l’ensemble des praticiens, qui de surcroit ne leur a pas été transmis directement, mais a été communiqué au président de la commission médicale d’établissement, à charge pour lui de le leur retransmettre ». L’hôpital a reconnu le problème mais a insisté sur le caractère d’urgence de cette mesure.

Précisons quand même que ce mot de passe temporaire n’était valable « que » pendant une semaine. Mais la CNIL rappelle que, même temporaire, les mots de passe « doivent être confidentiels et personnels à chaque utilisateur ». L’autorité remarque que l’hôpital « a au demeurant fourni à l’ensemble des utilisateurs les moyens de se connecter à des comptes de tiers, dès lors que tous avaient durant plusieurs jours le même mot de passe, et d’accéder ainsi à toutes les données à caractère personnel auxquels ces tiers pouvaient accéder ».

La rapporteure de la CNIL reproche encore à l’hôpital d’avoir laissé à la société éditrice du logiciel de gestion de son DPI un accès permanent aux données à caractère personnel des patients. Si l’hôpital a tenté de mettre en avant le besoin de cet accès pour un support rapide et efficace, l’autorité considère que l’accès permanent et sans contrôle au DPI de l’hôpital et aux données des patients « n’est pas nécessaire au regard de la mission d’assistance technique et de maintenance de la société éditrice du logiciel ». Elle ajoute même qu’au contraire, « les salariés de l’éditeur du logiciel auraient dû systématiquement solliciter l’autorisation préalable de l’hôpital » pour effectuer une opération de maintenance.

Enfin, l’hôpital se voit reprocher sa mauvaise communication envers les personnes concernées. En effet, si son effort pour contacter ses patients n’est pas remis en cause, la CNIL considère qu’il aurait dû contacter les 202 246 personnes concernées désignées comme tiers de confiance par des patients de l’hôpital.

Outre l’amende de 500 000 euros prononcée par la CNIL, l’autorité enjoint l’Hôpital privé de la Loire de mettre en conformité ses outils de sécurité et à n’ouvrir l’accès de l’éditeur du logiciel Expert Santé au DPI que sur autorisation préalable de l’hôpital sous menace de peines de jours-amende. Comme dans pareille décision de la CNIL, l’Hôpital privé de la Loire peut faire un recours devant le Conseil d’État dans un délai de deux mois.

C'est l'hôpital qui se fout de la sécurité

Il y a un an, un pirate a pu accéder aux données de 524 867 patients et 202 246 tiers de confiance de l’Hôpital privé de Loire via son système de dossier patient informatisé. La CNIL a choisi de sanctionner cet établissement de soin privé car celui-ci a été particulièrement négligent : absence de VPN, de moyen d’authentification multifacteur, mais aussi mot de passe temporaire identique pour l’ensemble des praticiens après la violation de données.

C’est une sanction de 500 000 euros d’amende que la CNIL a infligée ce jeudi 3 septembre à l’Hôpital privé de la Loire, un établissement du groupe Ramsay Santé.

La CNIL n’a pas pour habitude de sanctionner fortement des structures comme les hôpitaux, elle préfère souvent les accompagner dans une démarche de meilleure sécurisation de leurs infrastructures. Mais là, il semble que les manquements de sécurité de cet hôpital aient largement dépassé les bornes de ce que l’autorité peut laisser passer sans sanction concernant la mauvaise protection de données de santé.

Dans sa délibération, la CNIL explique que cet hôpital a été victime d’une violation de données de son dossier patient informatisé (DPI) en juin 2025. L’attaquant s’est connecté au DPI via les identifiants d’un médecin libéral rattaché à la structure.

Entre le 26 juin et le 1er juillet 2025, il a « procédé à l’exfiltration de 524 867 fiches patients contenant des informations telles que l’état civil, le numéro de sécurité sociale, les coordonnées postales et électroniques et le numéro d’identifiant permanent des patients concernés ». Plus de 46 000 de ces fiches étaient aussi associées au recto de la carte d’identité et plus de 202 000 comportaient des données relatives à la personne de confiance désignée par le patient. Enfin, 43 fiches comportaient des données de santé.

Pas de VPN ni d’authentification à 2 facteurs

Dans sa décision, la CNIL souligne « que l’obligation de sécurité prévue par l’article 32 du RGPD est une obligation de moyens ». Or, sa rapporteure « reproche à l’hôpital de ne pas avoir mis en place des mesures appropriées pour sécuriser l’accès au DPI des utilisateurs externes ». En effet, au moment de la violation de données, cet accès s’effectuait grâce à un identifiant et un mot de passe mais « sans connexion préalable à un VPN, ni moyen d’identification électronique à deux facteurs ».

Un référentiel de sécurité relatif à l’identification électronique des utilisateurs des services numériques en santé existe pourtant depuis la publication d’un arrêté le 28 mars 2022. Et celui-ci demande bien expressément de mettre en place ces dispositifs pour sécuriser les connexions extérieures.

La rapporteure souligne que, justement, l’attaquant a exploité cette vulnérabilité pour accéder au dossier patient informatisé de l’hôpital et extraire les données qu’il contenait.

Pas de surveillance automatique des logs

Autre reproche : l’hôpital n’avait pris aucune mesure d’analyse automatisée des journaux d’évènements permettant de repérer des activités inhabituelles sur le DPI. En effet, si la structure hospitalière avait mis en place un centre des opérations de sécurité (SOC), un système de supervision et un système de journalisation avec enregistrement des traces applicatives, elle n’avait pas activé l’analyse automatique en temps réel des traces applicatives du DPI.

« Cette carence de surveillance a permis à l’attaquant d’effectuer un nombre extrêmement élevé de requêtes au sein du DPI de l’hôpital pendant près d’une semaine », souligne la rapporteure. La CNIL montre d’ailleurs, après analyse des logs, que l’activité de l’attaquant aurait sans doute été détectée par un système automatisé : pendant la phase d’extraction automatique mise en place par l’attaquant, son système consultait une moyenne de 73 fiches de patients par minute.

Un mot de passe temporaire pour tous

Et ce n’est pas tout. La CNIL pointe une mauvaise pratique mise en place par l’hôpital pour atténuer les effets de l’attaque. En effet, celui-ci a enclenché une procédure de réinitialisation des mots de passe. Mais celle-ci était pour le moins problématique : elle a consisté « à attribuer un mot de passe temporaire identique à l’ensemble des praticiens, qui de surcroit ne leur a pas été transmis directement, mais a été communiqué au président de la commission médicale d’établissement, à charge pour lui de le leur retransmettre ». L’hôpital a reconnu le problème mais a insisté sur le caractère d’urgence de cette mesure.

Précisons quand même que ce mot de passe temporaire n’était valable « que » pendant une semaine. Mais la CNIL rappelle que, même temporaire, les mots de passe « doivent être confidentiels et personnels à chaque utilisateur ». L’autorité remarque que l’hôpital « a au demeurant fourni à l’ensemble des utilisateurs les moyens de se connecter à des comptes de tiers, dès lors que tous avaient durant plusieurs jours le même mot de passe, et d’accéder ainsi à toutes les données à caractère personnel auxquels ces tiers pouvaient accéder ».

La rapporteure de la CNIL reproche encore à l’hôpital d’avoir laissé à la société éditrice du logiciel de gestion de son DPI un accès permanent aux données à caractère personnel des patients. Si l’hôpital a tenté de mettre en avant le besoin de cet accès pour un support rapide et efficace, l’autorité considère que l’accès permanent et sans contrôle au DPI de l’hôpital et aux données des patients « n’est pas nécessaire au regard de la mission d’assistance technique et de maintenance de la société éditrice du logiciel ». Elle ajoute même qu’au contraire, « les salariés de l’éditeur du logiciel auraient dû systématiquement solliciter l’autorisation préalable de l’hôpital » pour effectuer une opération de maintenance.

Enfin, l’hôpital se voit reprocher sa mauvaise communication envers les personnes concernées. En effet, si son effort pour contacter ses patients n’est pas remis en cause, la CNIL considère qu’il aurait dû contacter les 202 246 personnes concernées désignées comme tiers de confiance par des patients de l’hôpital.

Outre l’amende de 500 000 euros prononcée par la CNIL, l’autorité enjoint l’Hôpital privé de la Loire de mettre en conformité ses outils de sécurité et à n’ouvrir l’accès de l’éditeur du logiciel Expert Santé au DPI que sur autorisation préalable de l’hôpital sous menace de peines de jours-amende. Comme dans pareille décision de la CNIL, l’Hôpital privé de la Loire peut faire un recours devant le Conseil d’État dans un délai de deux mois.

La transparence des salaires oui, mais pas à ce point !

Il y a toute une panoplie de types de fuites de données. Celle du jour n’était pas directement accessible depuis Internet, mais des « milliers de salariés » d’Orano pouvaient consulter les données RH et salariales très détaillées de leurs collègues. Elles étaient librement accessibles sur un serveur partagé sur son réseau interne. « Près de 4 700 collaborateurs » sont concernés, nous confirme l’entreprise.

Dans un message interne envoyé par la direction de BU Recyclage et que nous avons pu consulter, Orano reconnait que « des dossiers de travail numériques relatifs à la rémunération et aux avantages sociaux avaient été rendus accessibles en interne au-delà des personnes autorisées sur un serveur informatique partagé d’Orano Recyclage ».

« L’ensemble des salariés des activités Recyclage d’Orano » sont concernés

Contacté par Next, Orano confirme et nous précise que « les données concernaient l’ensemble des salariés des activités Recyclage d’Orano, soit près de 4 700 collaborateurs ». Les accès au répertoire partagé ont évidemment été bloqués « dès que cette situation a été portée à notre connaissance ». La société ajoute que, « par mesure de précaution, tous les serveurs RH ont été déconnecté. Leur accès est fermé et toutes les restrictions d’accès font actuellement l’objet d’une analyse approfondie ».

Comme toujours en pareille situation, nous avons droit au chapelet habituel sur le sérieux des procédures et le renforcement de la sécurité : « Nous avons toujours eu à cœur de mettre en place des process et procédures destinés à garantir la meilleure protection des données personnelles. À ce titre, les données hébergées sur ce serveur sont protégées par des règles de stricte confidentialité et de limitation d’accès. Ces règles ont d’ailleurs été renforcées à la suite d’une alerte en décembre 2025 ».

La direction en profite pour mettre en garde ses employés dans son courrier aux employés : « la copie, la diffusion, la conservation et/ou l’exploitation de ces informations par un salarié sans y être expressément autorisé constitue un traitement illicite puni par la loi. Les éventuelles copies qui auraient pu être faites doivent donc être immédiatement détruites ». Une autre manière de lire cette mise en garde : Orano reconnait donc que les documents n’auraient jamais dû être accessibles si largement.

Salaires, performances, retours de congé maternité…

Depuis quelques jours, une manipulation circule sur les réseaux sociaux : elle permettrait d'accéder à toute la galerie photo d'un téléphone Android via WhatsApp, sans même connaître le code de verrouillage. Nous l'avons testée, elle fonctionne.

Tous dans la même passoire

L’ancien journaliste spécialisé dans la cybersécurité Bryan Krebs raconte comment il a découvert un service illégal donnant accès à la bagatelle de 153 millions de permis de conduire enregistrés aux États-Unis et au Canada. Ses recherches indiquent que les données semblent avoir été extraites depuis les systèmes d’un prestataire spécialisé dans la vérification d’identité. Le FBI a lancé une enquête.

N’en déplaise aux Cassandre, voilà une découverte qui rappelle que la problématique des fuites de données n’est pas exclusive à la France. Bryan Krebs, ancien journaliste reconverti dans le conseil en cybersécurité, vient ainsi de raconter comment il a découvert la mise à disposition, via un outil dédié baptisé Nexus, d’un jeu de données revendiquant quelque 170 millions de documents d’identité provenant des États-Unis et du Canada. L’outil était mis à disposition au travers d’un forum russe dédié à la revente de données, et semble avoir été placé hors ligne suite à la divulgation de son existence.

Un guichet ouvert sur 153 millions de permis de conduire

Krebs explique avoir été alerté lundi 31 août par une source qui, pour faire bonne mesure, lui a transmis une capture d’écran des informations relatives à son propre permis de conduire. Dans la foulée, il accède à l’outil. D’après les résultats de recherche retournés par ce dernier, la base de données afférente listait donc 153 millions de permis de conduire, mais aussi 10 millions de cartes d’identité, près de 2 millions de documents de voyage, et près de 600 000 cartes médicales.

Le chercheur remarque, au fil de ses investigations, que les compteurs ne cessent de s’incrémenter, ce qui laisse supposer une base alimentée en continu, et donc une source de données qui ne s’est pas tarie. Il affirme ainsi avoir constaté l’ajout de 400 000 nouveaux permis de conduire sur une fenêtre de 24 heures.

Une dynamique confirmée par les auteurs de l’outil. Sur l’annonce qui présente leurs services, ils affirment ainsi : « Depuis plus d’un an, nous enrichissons continuellement notre base de données privée avec de nouvelles données », selon les propos rapportés par Krebs.

D’où viennent les données en question ? L’ancien journaliste indique avoir sollicité douze de ses contacts en leur demandant l’autorisation de vérifier si leurs documents figuraient dans la base. La recherche a retourné des résultats positifs pour neuf d’entre eux.

Après recoupements, Bryan Krebs associe la présence de leurs documents à des voyages récents, et notamment à des locations de voiture chez Hertz, mais pas uniquement. C’est le cas par exemple d’un autre chercheur en cybersécurité alerté par ses soins, selon qui les captures visibles via Nexus et l’horodatage associé correspondent à une location de voiture lors de vacances récentes. Zach Edwards, un autre chercheur en cybersécurité sur lequel Krebs a mené une recherche fructueuse, indique n’avoir fourni son permis de conduire qu’à l’enregistrement dans un hôtel de Las Vegas et à l’entrée d’un dispensaire de cannabis à l’occasion d’un déplacement à la Defcon.

Identifier le single point of failure

De fil en aiguille, Bryan Krebs trouve le point commun aux différents services concernés : un prestataire états-unien spécialisé dans la vérification d’identité, IDScan, qui se présente comme le leader dans la lutte contre la fraude aux fausses pièces d’identité, et revendique une longue liste de clients, dont Hertz et la chaîne de dispensaires concernée, mais aussi FedEx, plusieurs constructeurs automobiles, Shell et sans doute d’autres acteurs du monde du transport dont le nom reste confidentiel. Contactée par ses soins, l’entreprise n’a pour l’instant pas commenté ou confirmé la possibilité d’une fuite de données.

Le sujet a, quoi qu’il en soit, très vite attiré l’attention du FBI. Bryan Krebs raconte avoir été ajouté à une conférence téléphonique avec plusieurs agents spécialisés dans la cybercriminalité du Bureau. « Ils ont probablement été mis au courant lorsque j’ai révélé à une source fiable que Nexus vendait également les informations relatives au permis de conduire du directeur adjoint du FBI (je n’ai pas trouvé le permis de conduire du directeur du FBI, Kash Patel, sur Nexus) », glisse-t-il.

Reste à voir quelle sera la réponse apportée par ID Scan, et sous quel délai l’accès temps réel aux données sera coupé ? Un commentaire laissé sous le billet de Krebs laisse entendre que l’entreprise a commencé à alerter ses clients entreprise mercredi 2 septembre, sans qu’il soit possible à ce stade de vérifier la légitimité du message.

• Cannabis clubs et coffee shops : 1 million de pièces d’identité exposées sur Internet

Tous dans la même passoire

L’ancien journaliste spécialisé dans la cybersécurité Bryan Krebs raconte comment il a découvert un service illégal donnant accès à la bagatelle de 153 millions de permis de conduire enregistrés aux États-Unis et au Canada. Ses recherches indiquent que les données semblent avoir été extraites depuis les systèmes d’un prestataire spécialisé dans la vérification d’identité. Le FBI a lancé une enquête.

N’en déplaise aux Cassandre, voilà une découverte qui rappelle que la problématique des fuites de données n’est pas exclusive à la France. Bryan Krebs, ancien journaliste reconverti dans le conseil en cybersécurité, vient ainsi de raconter comment il a découvert la mise à disposition, via un outil dédié baptisé Nexus, d’un jeu de données revendiquant quelque 170 millions de documents d’identité provenant des États-Unis et du Canada. L’outil était mis à disposition au travers d’un forum russe dédié à la revente de données, et semble avoir été placé hors ligne suite à la divulgation de son existence.

Un guichet ouvert sur 153 millions de permis de conduire

Krebs explique avoir été alerté lundi 31 août par une source qui, pour faire bonne mesure, lui a transmis une capture d’écran des informations relatives à son propre permis de conduire. Dans la foulée, il accède à l’outil. D’après les résultats de recherche retournés par ce dernier, la base de données afférente listait donc 153 millions de permis de conduire, mais aussi 10 millions de cartes d’identité, près de 2 millions de documents de voyage, et près de 600 000 cartes médicales.

Le chercheur remarque, au fil de ses investigations, que les compteurs ne cessent de s’incrémenter, ce qui laisse supposer une base alimentée en continu, et donc une source de données qui ne s’est pas tarie. Il affirme ainsi avoir constaté l’ajout de 400 000 nouveaux permis de conduire sur une fenêtre de 24 heures.

Une dynamique confirmée par les auteurs de l’outil. Sur l’annonce qui présente leurs services, ils affirment ainsi : « Depuis plus d’un an, nous enrichissons continuellement notre base de données privée avec de nouvelles données », selon les propos rapportés par Krebs.

D’où viennent les données en question ? L’ancien journaliste indique avoir sollicité douze de ses contacts en leur demandant l’autorisation de vérifier si leurs documents figuraient dans la base. La recherche a retourné des résultats positifs pour neuf d’entre eux.

Après recoupements, Bryan Krebs associe la présence de leurs documents à des voyages récents, et notamment à des locations de voiture chez Hertz, mais pas uniquement. C’est le cas par exemple d’un autre chercheur en cybersécurité alerté par ses soins, selon qui les captures visibles via Nexus et l’horodatage associé correspondent à une location de voiture lors de vacances récentes. Zach Edwards, un autre chercheur en cybersécurité sur lequel Krebs a mené une recherche fructueuse, indique n’avoir fourni son permis de conduire qu’à l’enregistrement dans un hôtel de Las Vegas et à l’entrée d’un dispensaire de cannabis à l’occasion d’un déplacement à la Defcon.

Identifier le single point of failure

De fil en aiguille, Bryan Krebs trouve le point commun aux différents services concernés : un prestataire états-unien spécialisé dans la vérification d’identité, IDScan, qui se présente comme le leader dans la lutte contre la fraude aux fausses pièces d’identité, et revendique une longue liste de clients, dont Hertz et la chaîne de dispensaires concernée, mais aussi FedEx, plusieurs constructeurs automobiles, Shell et sans doute d’autres acteurs du monde du transport dont le nom reste confidentiel. Contactée par ses soins, l’entreprise n’a pour l’instant pas commenté ou confirmé la possibilité d’une fuite de données.

Le sujet a, quoi qu’il en soit, très vite attiré l’attention du FBI. Bryan Krebs raconte avoir été ajouté à une conférence téléphonique avec plusieurs agents spécialisés dans la cybercriminalité du Bureau. « Ils ont probablement été mis au courant lorsque j’ai révélé à une source fiable que Nexus vendait également les informations relatives au permis de conduire du directeur adjoint du FBI (je n’ai pas trouvé le permis de conduire du directeur du FBI, Kash Patel, sur Nexus) », glisse-t-il.

Reste à voir quelle sera la réponse apportée par ID Scan, et sous quel délai l’accès temps réel aux données sera coupé ? Un commentaire laissé sous le billet de Krebs laisse entendre que l’entreprise a commencé à alerter ses clients entreprise mercredi 2 septembre, sans qu’il soit possible à ce stade de vérifier la légitimité du message.

• Cannabis clubs et coffee shops : 1 million de pièces d’identité exposées sur Internet

Deux pas en avant, un gros pas en arrière

Le système d’exploitation mobile GrapheneOS, connu pour ses positions franches sur la sécurité, fera très probablement l’impasse sur les Pixel 11. La faute, selon les développeurs, à un choix inopportun de Google : l’absence de prise en charge de la Memory Tagging Extension, une fonction de sécurité utilisée abondamment dans le système.

Le 29 août, la fondation GrapheneOS a annoncé sur X, Bluesky et Mastodon qu’elle avait en sa possession un portage partiel de son système sur les Pixel 11 de Google, les derniers smartphones de l’entreprise. La fondation explique que ce portage a été réalisé en une semaine, mais le travail s’était arrêté. Les développeurs ont indiqué être bloqués, faute de support de la Memory Tagging Extension, ou MTE.

Celle-ci est une fonction de marquage de la mémoire proposée par le jeu d’instructions ARM. Elle associe une étiquette aléatoire à chaque zone de mémoire allouée. Si un accès mémoire présente une étiquette qui ne correspond pas, le système détecte une violation. Dans ce cas, selon les choix faits dans le système, le processus est immédiatement interrompu. Cette fonction est utilisée pour bloquer les éventuelles attaques dirigées contre la mémoire, dans l’idée de renforcer l’intégrité du système.

Le cas des Pixel 11

Dans le cas de GrapheneOS, le système s’appuie lourdement sur la MTE. Une position très différente de Google. La firme a intégré la fonction dès la puce Tensor G3 du Pixel en octobre 2023, mais elle s’en sert peu. Sur les Pixel, la MTE n’est en effet utilisée que dans les fonctions de « protection avancée », optionnelles. Il s’agit pour rappel du fameux mode conseillé à certains profils spécifiques (activistes, personnalités politiques, journalistes, etc.) qui élève le niveau général de sécurité en réduisant la surface d’attaque, au prix de certaines fonctions. Ce mode est apparu dans Android 16 en réponse à Apple, qui avait dégainé la première dans ce domaine.

Dans GrapheneOS, l’emploi de la MTE est systémique, aussi bien dans le noyau que dans les processus. Apple possède ici aussi un équivalent, baptisé Memory Integrity Enforcement (MIE), mais l’ajout est plus récent (iPhone 17 et Mac équipés d’une puce M5 au moins). La fondation indique à ce sujet que le MIE d’Apple est une « implémentation de haute qualité de MTE », même si elle n’est pas utilisée par défaut par les applications installées par l’utilisateur, à moins qu’elles aient opté spécifiquement pour cette protection.

Le choix de Google interroge, d’autant que l’entreprise ne s’est pas exprimée publiquement sur le sujet. Les Pixel 11 ont pourtant plusieurs arguments sur la sécurité, dont la puce Titan M3 pour améliorer la protection contre l’extraction de données à l’état verrouillé avant premier déverrouillage. On y trouve aussi une vérification post-quantique du démarrage (basée sur ML-DSA) ou encore un remplacement du sous-système IMS Samsung Shannon par une implémentation AOSP (Android Open Source Project).

Plus d'une centaine d'entreprises tech, dont les principaux laboratoires d'IA, viennent de publier une lettre ouverte appelant à une mobilisation mondiale contre les cyberattaques assistées par IA. Une démarche qui tient autant de l'alerte que de l'auto-diagnostic.