673 816 aspirateurs Shark qui répondent à une commande envoyée depuis un seul certificat, en 24 heures, dans une seule région AWS. Un chercheur affirme pouvoir prendre le contrôle des robots Shark d’autres personnes : caméra, pilotage à distance, plan du logement et mot de passe Wi-Fi en clair. Quatre mois après le signalement à SharkNinja, toujours aucun correctif et aucune CVE.

D’après un rapport publié par un chercheur surnommé tokay0, il y aurait un gros problème de sécurité avec les aspirateurs robots Shark. 2026. Il affirme que si vous exfiltrez le certificat logé dans la mémoire flash d’un aspirateur Shark vulnérable, vous pouvez ensuite exécuter des commandes en tant que root sur d’autres aspirateurs Shark de la même région AWS. Il dit n’avoir testé son attaque que sur des appareils achetés par ses soins, et avoir alerté les marques Shark et Ninja dès le mois de mars. En vain.

Un certificat, et tout le parc d’aspirateurs robots est à votre portée

Pas de corruption mémoire, pas d’élévation de privilèges, pas de mot de passe à deviner. Ici, ce qui pose problème, c’est la politique AWS IoT rattachée au certificat utilisé par les aspirateurs robots. En effet, elle n’est jamais limitée à l’appareil qui le détient. En pratique, ce certificat serait accepté quelle que soit la cible visée et la commande à exécuter ne serait qu’un champ () associé à l’état de l’appareil sur AWS. Sur le robot, le démon lirait ce champ et le passerait à une fonction , qui exécuterait tout contenu inférieur à 1 000 octets. Ceci permet alors de piloter à distance les robots vulnérables.

Visiblement rien n’est fait pour empêcher la bidouille puisque pour récupérer le fameux certificat, un accès physique suffit. Mais bon, si c’est votre robot, c’est facile. Le chercheur explique que l’opération est facilitée pour plusieurs raisons :

• La carte mère expose des broches UART.
• La console ne réclamerait aucun mot de passe.
• L’argument de démarrage ouvrirait un shell root.
• Le certificat et sa clé traînent dans , en simples fichiers.

Pour autant, il suffit de regarder l’image ci-dessous pour comprendre que ce n’est pas à la portée de tout le monde non plus.

Ensuite, tout aspirateur qui exécute le champ est une cible potentielle, peu importe le certificat qu’il détient. Le chercheur tokay0 affirme avoir obtenu un reverse shell sur un modèle AV1102ARUS acheté uniquement pour en faire une cible, puis il a récupéré le flux de sa caméra pendant que le robot roulait. La seule vraie limite serait géographique, les certificats étant rattachés à leur région AWS.

Un gros problème de sécurité, et pourtant, AWS le met en défaut. En effet, le service Device Defender d’AWS, via le contrôle classé critique, signale les politiques qui accordent des permissions excessives. Ce qui est le cas ici, et la documentation d’AWS précise : un certificat compromis associé à une telle politique laisse un attaquant « lire ou modifier les shadows, les jobs ou les exécutions de jobs de tous vos appareils ».

Difficile de savoir combien d’appareils sont réellement vulnérables, d’autant plus qu’il y a un cloisonnement par région AWS. Le titre du rapport publié par tokay0 évoque des millions d’appareils et, en observant une seule région AWS pendant 24 heures, il dit avoir compté 1 517 605 numéros de série uniques. Parmi eux, 673 816 (44 %) aspirateurs robots ayant émis un , signe que le gestionnaire de commandes tourne bien.

Comment se protéger de cette vulnérabilité ?

Il faut déjà remettre les choses dans leur contexte : le chercheur a pris contact avec Shark il y a 4 mois et, à l’heure actuelle, le problème de sécurité est toujours présent. En effet, voici la chronologie des événements :

• 1er mars : premier contact avec SharkNinja, détails techniques transmis le 11 mars et accusé de réception le 12.
• 25 avril : relance. Le 27, SharkNinja répond que le rapport est en cours d’examen.
• 7 juin : nouvelle relance. Le 9, la fenêtre de divulgation responsable de 90 jours expire.
• 11 juin : réservation d’un auprès de MITRE, via l’assignateur de dernier recours (), pour tenter d’obtenir une CVE.
• 28 juin : le chercheur prévient SharkNinja qu’il compte divulguer la faille.
• 3 juillet : SharkNinja annonce que ce sera finalisé pour le vendredi 10 juillet.
• 10 juillet : aucun e-mail.
• 13 juillet : publication du rapport par tokay0.

Le chercheur affirme que le fabricant aurait minimisé la gravité et se serait interrogé sur la pertinence d’attribuer une CVE. À ce jour, cette faille n’a pas d’identifiant, ni de score CVSS et pas le moindre avis officiel du côté de cette marque.

Si vous avez un aspirateur robot Shark, vous n’avez rien à faire. Le correctif doit être mis en place par les équipes techniques de Shark, au sein de l’environnement AWS, pas dans le firmware du robot. Si cela prend autant de temps, c’est peut-être parce que Shark voudrait également émettre de nouveaux certificats sur l’ensemble des appareils : un chantier de fond qui semble prendre du temps.

En attendant, vous n’avez qu’une option possible pour protéger votre robot (si l’on met de côté celle de s’en débarrasser) : couper le Wi-Fi de l’aspirateur pour qu’il ne se connecte plus à Internet. Mais bon, plus d’application, plus de programmation, ni même d’accès aux cartes de votre logement, retour au simple aspirateur.