Étude de cas : un arrosage connecté piloté par n’importe qui
Nous avons testé un système d’arrosage connecté : une configuration MQTT défaillante permettait de voir, piloter et localiser les appareils d’autres clients.
Zyberum Security Team · Publié le · 4 min de lecture
L’arrosage connecté a l’air inoffensif : des vannes, un contrôleur, une application. Nous avons testé un tel système et nous nous sommes retrouvés avec le contrôle d’appareils qui n’étaient pas les nôtres, et une carte de leur emplacement.
Ce que nous avons testé
- le contrôleur et son firmware
- l’application mobile
- le service cloud
- la connexion MQTT qui transporte les commandes et les messages d’état
Ce que nous avons trouvé
MQTT était défaillant
Le système utilisait MQTT pour relier les appareils, l’application et le cloud. La configuration ne séparait pas les clients les uns des autres. Depuis notre propre compte, nous pouvions voir les appareils d’autres clients, y compris leurs messages d’état.
Nous pouvions les piloter
Voir n’était pas tout. Nous pouvions aussi envoyer des commandes : ouvrir des vannes, lancer l’arrosage, modifier des réglages, sur des systèmes qui appartenaient à d’autres personnes.
Nous pouvions les localiser
Les messages et les réponses de l’API contenaient assez d’informations pour géolocaliser les appareils. Un attaquant saurait quel appareil se trouve où.
Pourquoi c’est important
Mis bout à bout : une liste d’appareils, leur emplacement, leur activité, et la possibilité de les contrôler à distance. Ce sont des dégâts des eaux et des coûts à grande échelle, et ce sont des données de localisation sur des logements privés et des entreprises.
Et comme pour la plupart des résultats IoT de ce type, rien ici n’a nécessité de casser un chiffrement ou d’exploiter des bugs mémoire. Le système a répondu à des questions qu’il aurait dû refuser.
Ce que les fabricants doivent en retenir
- Donnez à chaque appareil sa propre identité. Ses propres identifiants, pas un identifiant partagé issu du firmware.
- Restreignez les topics sur le broker. Un client ne doit pouvoir lire et écrire que sur ses propres topics. Les abonnements avec wildcard doivent être impossibles pour les clients normaux.
- Ne mettez pas la localisation dans des messages qui n’en ont pas besoin. Une donnée qui n’est pas envoyée ne peut pas fuiter.
- Vérifiez aussi les autorisations dans le cloud. Le même contrôle de propriété a sa place dans chaque appel d’API.
- Surveillez le broker. Un client qui s’abonne à tout est un incident, et il doit déclencher une alerte.
Ce sont exactement les points que les exigences de cybersécurité de la RED (EN 18031) et le Cyber Resilience Act rendent désormais obligatoires pour les produits connectés.
Nous testons les appareils, leurs applications et leur cloud comme un seul système. Découvrez nos tests de sécurité IoT ou nos pentests hardware, ou consultez le prix d’un test.
FAQ
Questions fréquentes
Qu’est-ce que MQTT et pourquoi est-ce un risque ?
MQTT est un protocole de messagerie léger utilisé par de nombreux produits IoT : les appareils et les applications publient et s’abonnent à des topics sur un broker central. Si le broker ne limite pas les topics qu’un client peut utiliser, n’importe quel client connecté peut lire et envoyer des messages pour tous les appareils.
Un système d’arrosage de jardin est-il vraiment un problème de sécurité ?
Oui. Celui qui le contrôle peut provoquer des dégâts des eaux et des coûts, et les données de localisation indiquent à un attaquant où les appareils sont installés et, d’après leur activité, quand les occupants sont absents. Les mêmes familles de produits sont aussi utilisées dans l’agriculture et sur des sites professionnels.