Unitree Go2 : L'analyse des failles critiques exposant les robots quadrupèdes au piratage local

Les robots autonomes entrent dans les foyers et les entreprises, mais leur sécurité réseau reste souvent un angle mort. Récemment, deux chercheurs en sécurité ont mis en lumière des vulnérabilités majeures dans le robot quadrupède Go2 de Unitree, permettant à n'importe quel appareil connecté au même réseau Wi-Fi de prendre le contrôle total de la machine.

En bref

• Exposition totale du réseau local : Le robot Go2 communique sans chiffrement ni authentification robuste sur le réseau Wi-Fi local, exposant ses commandes de mouvement et ses flux vidéo.
• Interception de la chaîne de commande : Les chercheurs ont démontré qu'il est possible de rediriger les paquets de données vers des contrôleurs malveillants pour piloter le robot à distance.
• Risque de fuite de données : Les flux vidéo en temps réel et les données de télémétrie sont accessibles sans protection, compromettant la vie privée des utilisateurs et la confidentialité des sites industriels.
• Absence de segmentation réseau : L'architecture logicielle du robot ne distingue pas clairement les flux critiques de maintenance des flux grand public, facilitant les attaques latérales.
• Nécessité d'une isolation stricte : La mitigation repose sur la création de VLANs dédiés, le filtrage strict des ports et la désactivation des services inutiles.

Architecture réseau et surface d'attaque du Go2

Pour comprendre la gravité de ces vulnérabilités, il faut analyser la manière dont le Go2 gère sa connectivité. Contrairement à un simple objet IoT qui se contente de renvoyer des données, le Go2 est une plateforme de calcul mobile complexe. Il embarque une unité de traitement central, des capteurs LiDAR, des caméras stéréo et des moteurs servos qui nécessitent une latence minimale pour les commandes de mouvement.

Le problème majeur réside dans le protocole de communication utilisé sur le réseau local (LAN). Les analyses effectuées par les chercheurs indiquent que le robot expose une interface de développement (API) locale, souvent via des ports TCP/UDP standard, pour permettre aux développeurs de programmer des tâches autonomes. Cette interface, conçue pour la flexibilité, n'est pas protégée par défaut par des mécanismes de sécurité réseau solides.

Sur un réseau Wi-Fi domestique ou d'entreprise classique, le trafic est routé en clair ou avec un chiffrement faible si l'application mobile de l'utilisateur est mal configurée. Un attaquant situé sur le même segment de réseau peut alors :

1. Écouter le trafic (Sniffing) pour identifier les adresses IP du robot et les ports ouverts.
2. Injecter des paquets pour simuler des commandes de mouvement (ex. : faire tourner le robot, le faire s'asseoir ou se déplacer).
3. Capturer les flux vidéo envoyés vers l'application mobile, contournant ainsi toute notion de confidentialité visuelle.

Le risque est amplifié par le fait que le Go2 est souvent utilisé dans des environnements semi-ouverts (bureaux, laboratoires, espaces commerciaux) où le réseau Wi-Fi peut être partagé ou partiellement accessible. Dans un contexte industriel, un robot qui peut être pris en contrôle par un visiteur ou un employé non autorisé représente un danger physique immédiat.

Techniques d'exploitation et démonsstration d'impact

Les chercheurs ont démontré l'exploitabilité de ces failles en utilisant des outils standards de pentest réseau. Voici le schéma technique de l'attaque typique identifiée :

1. Découverte et identification

L'attaquant commence par un scan de port sur le sous-réseau local pour identifier le Go2. Le robot répond généralement sur des ports spécifiques liés à son SDK (Software Development Kit) et à son interface web de gestion.

# Exemple de scan Nmap pour identifier les services ouverts sur le robot
nmap -sV -p- 192.168.1.50 -oN go2_scan.txt

Les résultats révèlent souvent des ports ouverts pour la communication série virtuelle (pour les moteurs) et des ports HTTP/HTTPS pour l'interface de configuration et le streaming vidéo.

2. Interception du flux vidéo

Une fois l'adresse IP et le port du flux vidéo identifiés, l'attaquant peut rediriger le flux vers son propre poste de travail. Si le flux n'est pas chiffré de bout en bout (ou si la clé de session est prévisible), la capture est triviale.

# Exemple de capture de flux RTSP ou HTTP en temps réel
# (La commande varie selon le protocole exact utilisé par le firmware, souvent basé sur GStreamer ou RTSP)
ffplay rtsp://192.168.1.50:8554/stream

Cette capture permet de voir exactement ce que le robot voit, ce qui est critique dans un contexte de surveillance ou de navigation autonome.

3. Injection de commandes de mouvement

Le point le plus critique est la capacité à envoyer des commandes de mouvement. Le Go2 utilise des paquets de données binaires ou des requêtes JSON pour contrôler ses articulations. Sans authentification forte sur ces endpoints, un attaquant peut envoyer des commandes arbitraires.

# Pseudocode illustratif d'une injection de commande via l'API locale
import requests

# L'adresse IP est celle du robot Go2
url = "http://192.168.1.50:8080/api/move"

# Payload pour faire avancer le robot (structure hypothétique basée sur le SDK)
payload = {
    "command": "walk",
    "speed": 0.5,  # m/s
    "direction": "forward"
}

# Envoi de la requête sans en-têtes d'authentification
response = requests.post(url, json=payload)
print(response.text)

Si l'API n'exige pas de jeton d'authentification dynamique ou de signature numérique, cette requête est acceptée. Le robot se met alors en mouvement, potentiellement vers des personnes ou des objets fragiles.

Analyse des failles logicielles et de configuration

Au-delà de l'exposition réseau, plusieurs aspects de la conception logicielle contribuent à la vulnérabilité :

• Absence de segmentation interne : Le système d'exploitation embarqué ne sépare pas strictement les processus de contrôle moteur des processus de communication réseau. Une faille dans le module de communication peut potentiellement affecter la stabilité du contrôle moteur.
• Mises à jour non sécurisées : Les mécanismes de mise à jour du firmware peuvent être interceptés ou altérés si le canal de transmission n'est pas vérifié cryptographiquement de manière rigoureuse.
• Comptes par défaut : Bien que moins courant sur les modèles récents, l'absence de forçage d'un mot de passe fort lors de la première configuration laisse la porte ouverte à des accès non autorisés si le robot est réinitialisé ou vendu d'occasion.

Ces failles ne sont pas spécifiques à Unitree, mais reflètent une tendance générale dans l'industrie de la robotique de service : la priorité donnée à l'expérience utilisateur et à la connectivité facile au détriment de la sécurité par défaut (security by default).

Stratégies de mitigation pour les environnements professionnels

Pour les consultants IT et les administrateurs systèmes qui déploient des robots autonomes, il est impératif de ne pas les connecter directement au réseau de production. Voici les mesures concrètes à mettre en œuvre :

1. Isolation réseau stricte (VLAN)

Créez un VLAN (Virtual Local Area Network) dédié aux robots IoT/Robotique. Ce VLAN ne doit pas avoir de route directe vers le réseau des utilisateurs ou les serveurs critiques.

Config Switch (Exemple générique) :
interface vlan 10
 name Robot_Isolation
 ip address 10.10.10.1 255.255.255.0
!
interface gigabitEthernet 0/1
 switchport mode access
 switchport access vlan 10

2. Filtrage de paquets (ACL)

Implémentez des listes de contrôle d'accès (ACL) pour restreindre la communication. Le robot ne devrait communiquer qu'avec :

• Son serveur de gestion spécifique.
• Les capteurs/acteurs locaux (si câblés).
• Aucun autre hôte du réseau.

ACL Exemple :
access-list 100 permit tcp host 10.10.10.50 eq 80 host 10.10.10.200
access-list 100 permit udp host 10.10.10.50 eq 5000 host 10.10.10.200
access-list 100 deny ip any any

3. Désactivation des services inutiles

Via l'interface de configuration du robot (si accessible), désactivez :

• Le partage de fichiers (SMB/FTP) si non requis.
• L'accès SSH/RDP direct.
• Les ports de développement non utilisés en production.

4. Surveillance et Logging

Connectez le VLAN robotique à un système de journalisation centralisé (SIEM). Alertez sur toute tentative de connexion sortante non autorisée ou sur un volume de trafic anormal (indicatif d'une exfiltration de données vidéo).

Bonnes pratiques pour consultants IT

1. Audit de pré-déploiement : Avant de connecter un robot à un réseau d'entreprise, effectuez un scan complet de sa surface d'attaque. Utilisez des outils comme nmap et wireshark pour documenter tous les flux sortants.
2. Politique de mot de passe : Forcez la création d'un mot de passe complexe et unique pour l'interface web et l'application mobile du robot. Évitez les identifiants par défaut.
3. Chiffrement du trafic : Si le robot le permet, configurez le TLS/SSL pour toutes les communications API et vidéo. Vérifiez que les certificats sont valides et non auto-signés sans autorisation explicite.
4. Mises à jour automatiques : Assurez-vous que les mises à jour du firmware sont poussées depuis un serveur interne sécurisé (proxy) plutôt que depuis Internet, afin de contrôler l'intégrité du code.
5. Formation des utilisateurs : Informez les opérateurs des risques liés au partage du robot sur des réseaux Wi-Fi publics ou non sécurisés. Le robot doit toujours rester sur le réseau isolé.

Points cles

• Le Unitree Go2 et d'autres robots autonomes présentent des vulnérabilités critiques liées à l'absence de sécurité par défaut sur le réseau local.
• Un attaquant sur le même Wi-Fi peut piloter le robot et capturer ses caméras sans authentification robuste.
• La segmentation réseau (VLAN) est la mesure de mitigation la plus efficace et indispensable.
• Les consultants IT doivent traiter les robots comme des nœuds de calcul critiques, pas comme de simples objets IoT.
• L'audit de la surface d'attaque et la surveillance active du trafic sont obligatoires avant tout déploiement en entreprise.

En conclusion, l'essor de la robotique autonome exige une refonte de nos approches de sécurité réseau. La confiance aveugle dans les fournisseurs de matériel doit être remplacée par une posture de "zero trust" appliquée aux dispositifs de terrain. Les entreprises qui ignorent ces risques s'exposent non seulement à des fuites de données, mais aussi à des incidents de sécurité physique graves.

Source : Generation-NT