WiFi extendeur £3 expose une porte dérobée root

Présentation

Le dispositif Z05L WiFi extender, commercialisé à 3 £, utilise un SoC MT7620 et une mémoire flash Winbond 4 Mo. Une analyse du firmware a révélé que le système démarre un service Telnet à chaque boot avec le mot de passe 198277tt@. Parallèlement, l’API web accepte un paramètre mac qui est directement injecté dans un appel system(), ouvrant la porte à une exécution de commande en tant que root.

Architecture du firmware et vecteurs d'attaque

Le processus de mise à jour ne vérifie que le CRC32 de l’image, ce qui permet de signer des images falsifiées sans altérer le checksum. La partition de configuration stocke les identifiants Wi‑Fi en texte clair, et le pare‑feu laisse les services entrants actifs sur les réseaux pontés. Ainsi, un attaquant peut :

curl "http://192.168.0.1/api?mac=$(cat /etc/passwd)"

En injectant une chaîne contenant $(…), la fonction system() exécute la commande avec les privilèges du noyau. Le service Telnet, déjà accessible, offre une seconde voie d’accès sans authentification supplémentaire.

Chaîne d’exploitation et risques associés

Une fois le code malveillant exécuté, l’attaquant obtient un shell root sur le dispositif. Le contrôle du système permet de :

• Intercepter les identifiants Wi‑Fi stockés en clair.
• Utiliser le dispositif comme pivot vers d’autres machines du réseau local.
• Déployer des images firmware falsifiées, conservant la vérification CRC32 mais contenant du code persistant.

Le temps d’infiltration est limité par la courte fenêtre d’accès au réseau domestique, mais la persistance du backdoor rend la compromission difficile à détecter, surtout en l’absence de logs d’accès Telnet.

Mitigations et limites de la correction

Le fabricant n’a pas publié de correctif au moment de la rédaction. Les mesures d’atténuation immédiates comprennent :

1. Désactiver le service Telnet via le CLI ou le blocage du port 23 au pare‑feu.
2. Restreindre l’accès à l’API web à des adresses IP approuvées et implémenter une validation stricte des paramètres.
3. Remplacer la vérification CRC32 par une signature cryptographique (RSA/ECDSA) afin d’empêcher les images falsifiées.
4. Chiffrer la partition de configuration pour protéger les clés Wi‑Fi.

Sans ces actions, le dispositif reste exploitable à grande échelle, notamment dans des environnements où le matériel à bas coût est déployé massivement. La divulgation met en lumière la nécessité d’audits de sécurité dès la phase de conception des firmware IoT.