Étude de cas : robot aspirateur, root et caméras d’autrui
Nous avons testé un robot aspirateur à caméra : accès root sur l’appareil, et failles de l’API cloud ouvrant la caméra en direct d’autres utilisateurs.
Zyberum Security Team · Publié le · 5 min de lecture
Un robot aspirateur équipé d’une caméra, c’est une caméra mobile à l’intérieur d’un logement. Nous en avons testé un : l’appareil, son application et le cloud qui se trouve derrière. Le nom du fabricant n’a pas d’importance ici. Le schéma, lui, en a, car nous le retrouvons encore et encore.
Ce que nous avons testé
Le produit complet, tel qu’un attaquant le verrait :
- l’appareil lui-même
- l’application mobile
- l’API cloud avec laquelle l’application communique
- le canal MQTT entre l’appareil et le cloud
- la connexion vidéo WebRTC de la caméra en direct
Ce que nous avons trouvé
Root sur l’appareil
Nous avons obtenu un accès root complet à l’aspirateur. Avec les droits root, un attaquant contrôle tout ce que l’appareil sait faire : se déplacer, enregistrer, écouter le réseau auquel il est connecté et lire tout ce que le fabricant y a stocké.
Les appareils des autres via l’API
Les résultats les plus graves se trouvaient dans le cloud. L’API présentait les trois failles d’autorisation classiques :
| Faille | Ce que cela signifiait ici |
|---|---|
| IDOR / BOLA | Les requêtes portant sur un appareil recevaient une réponse pour des appareils appartenant à d’autres utilisateurs |
| BFLA | Des fonctions qui auraient dû être restreintes pouvaient être appelées depuis un compte utilisateur normal |
| Exposition excessive de données | Les réponses de l’API contenaient bien plus d’informations que l’application n’en affichait |
MQTT
Le canal de messagerie entre les appareils et le cloud avait ses propres faiblesses, qui élargissaient ce qu’un simple utilisateur connecté pouvait voir et faire.
L’impact : une caméra en direct chez un inconnu
Combinés, ces résultats nous ont donné accès au flux de la caméra WebRTC des aspirateurs d’autres personnes. Pas notre appareil de test : les appareils d’autres utilisateurs. Pas de malware, pas d’accès physique, pas de mots de passe à deviner. Un compte normal et les bonnes requêtes ont suffi.
Pourquoi c’est arrivé
Rien de tout cela n’a demandé d’exploitation avancée. La cause racine était la même pour chaque résultat : le backend faisait confiance à ce que le client envoyait. Il vérifiait qu’un utilisateur était connecté, mais pas que l’appareil visé par la requête appartenait à cet utilisateur.
C’est la faille grave la plus répandue dans les produits connectés, et elle est invisible pour les scanners automatisés, car chaque requête prise isolément paraît légitime.
Ce que les fabricants doivent en retenir
- Vérifiez la propriété à chaque requête. Côté serveur, pour chaque identifiant d’appareil, à chaque fois. Pas dans l’application.
- Traitez MQTT comme une API. Chaque client ne doit pouvoir publier et s’abonner que sur ses propres topics.
- Ne renvoyez que le nécessaire. Si l’application n’affiche pas un champ, l’API ne doit pas l’envoyer.
- Partez du principe que l’appareil sera ouvert. Tout ce qui y est stocké, clés comprises, sera lu.
- Testez le produit dans son ensemble. Appareil, application et cloud, ensemble. Les pires résultats naissent de leur combinaison.
Avec le Cyber Resilience Act, un produit comme celui-ci ne doit pas être mis sur le marché avec des vulnérabilités exploitables connues, et le fabricant doit les traiter et les signaler. Un test avant le lancement coûte moins cher qu’un rappel après.
Vous voulez savoir ce que votre appareil laisse échapper ? Découvrez nos tests de sécurité IoT, nos pentests web et API ou le prix d’un test.
FAQ
Questions fréquentes
Que sont IDOR, BOLA et BFLA ?
IDOR (insecure direct object reference) et BOLA (broken object level authorization) décrivent le même problème : le serveur renvoie ou modifie un objet, par exemple un appareil, parce que la requête indique son identifiant, sans vérifier qu’il appartient à l’appelant. BFLA (broken function level authorization) signifie qu’un utilisateur peut appeler des fonctions destinées à un autre rôle, par exemple un administrateur.
Pourquoi ces failles sont-elles si fréquentes dans les produits IoT ?
Les backends IoT gèrent des millions d’appareils avec un petit nombre d’appels d’API et de topics MQTT. Si le contrôle « cet appareil appartient-il à cet utilisateur ? » manque à un seul endroit, tous les appareils derrière cet appel sont exposés. Les scanners automatisés ne le détectent pas, car chaque requête est techniquement valide.