Un robot aspirateur paraît inoffensif: il nettoie, cartographie les pièces et retourne à sa base. L’affaire Shark montre qu’il peut aussi dépendre d’un système beaucoup moins visible: certificats d’appareil, MQTT, AWS IoT, application mobile, cartes du logement, parfois caméra, et règles cloud que l’utilisateur ne contrôle pas.

Robot aspirateur sans marque avec plan de logement, routeur Wi-Fi et symbole de protection cloud

Le 13 juillet, le chercheur tokay0 a publié une analyse de robots aspirateurs Shark. Selon lui, un certificat extrait d’un Shark RV2320EDUS permettait d’envoyer des commandes à d’autres appareils Shark dans la même région AWS, car la politique cloud n’était pas limitée au seul appareil. Le billet évoque des commandes AWS IoT shadow, de l’exécution de code, un flux caméra, le contrôle des moteurs, les cartes du domicile et une clé Wi-Fi stockée en plaintext.

Il ne faut pas transformer ce cas en panique générale. Le billet porte désormais une note indiquant que SharkNinja affirme avoir corrigé la vulnérabilité le 20 juillet. Mais la leçon demeure: une partie essentielle de la sécurité peut se trouver dans l’infrastructure du fabricant, loin du bouton « mettre à jour » visible par le propriétaire.

Ce que le rapport décrit

Dans une architecture IoT correctement cloisonnée, le certificat d’un appareil ne doit parler qu’aux sujets et états de cet appareil. La documentation AWS IoT Device Defender signale justement le risque des politiques trop permissives: un certificat compromis peut lire ou modifier des shadows, jobs ou messages pour un ensemble d’appareils plus large.

Tokay0 affirme que le certificat de son RV2320EDUS pouvait publier et s’abonner hors de son espace. Il dit avoir vérifié le problème avec un deuxième modèle, AV1102ARUS. Les médias spécialisés — The Hacker News, Malwarebytes, Tom’s Hardware, Digital Trends — ont repris les mêmes risques principaux. Les chiffres doivent rester nuancés: 1 517 605 numéros de série observés et 673 816 appareils avec Exec_Response dans une région en 24 heures ne signifient pas autant de foyers compromis.

Pourquoi cela concerne toute maison connectée

Les conseils habituels — mettre à jour le firmware, changer les mots de passe, isoler les objets connectés — restent utiles. Mais ils ne permettent pas à un utilisateur d’auditer une politique AWS IoT du fabricant. Si l’autorisation cloud est trop large, le propriétaire ne peut pas vérifier seul quels certificats ont été révoqués ni quelles régions ont été corrigées.

La communication du fabricant devient donc un élément de sécurité. SharkNinja dit avoir complètement traité la vulnérabilité, mais les consommateurs auraient besoin d’informations simples: modèles concernés, type de correction, nécessité ou non d’une mise à jour, éventuel accès à des données et portée géographique.

Mesures pratiques

Les propriétaires devraient vérifier l’application, le firmware, les avis de support et les paramètres de caméra ou de carte. En cas de doute sérieux, déconnecter temporairement l’aspirateur du Wi-Fi est possible, mais cela supprime souvent les fonctions à distance, les horaires et une partie de la cartographie. Changer le mot de passe Wi-Fi est une mesure lourde, à réserver à une vraie remise à zéro.

La meilleure habitude durable consiste à placer les appareils IoT sur un réseau invité, un SSID séparé ou un VLAN qui n’accède pas librement aux ordinateurs, NAS et machines de travail. Pour un prochain achat, demandez-vous si la caméra est indispensable, si le robot fonctionne sans cloud, si les cartes se suppriment et si le fabricant publie des avis de sécurité lisibles. La maison intelligente doit rester pratique, pas demander une confiance aveugle.