
Preuve de concept d'exploitation pour CVE-2020-12124 ciblant le routeur Wavlink AC1200, démontrant une injection de commandes non authentifiée et un débordement de tampon de pile dans les interfaces CGI.
originellement sur https://www.klogixsecurity.com/scorpion-labs-blog/anatomy-of-an-iot-exploit-from-hands-on-to-rce
par David E. Baker, publié le 1er juin 2023
Cette étude concerne le firmware du routeur Gigabit Wavlink Wireless-AC1200 tel qu'il était en juin 2020. Les vulnérabilités discutées ici peuvent ou non avoir été corrigées par le vendeur, mais il s'agit d'un cas de recherche de vulnérabilités qui montrera que le voyage est la récompense plutôt que sa conclusion. L'auteur a mené cette recherche avant la divulgation publique des vulnérabilités, mais après qu'elles aient été découvertes indépendamment par d'autres chercheurs et signalées au vendeur.
Le vendeur rend le firmware de ses produits disponible dans la section support de son site web ; c'est un moyen courant d'obtenir le firmware IoT et une alternative utile à son extraction depuis la mémoire de l'appareil. Le firmware n'est pas chiffré, il peut donc être facilement extrait avec binwalk. L'analyse dynamique a été effectuée avec l'accès à un exemplaire physique de l'appareil, et l'analyse statique via Ghidra.
L'interface web du routeur Gigabit Wavlink Wireless-AC1200 présente plusieurs points d'accès vulnérables qui permettent la copie sans restriction des données fournies par l'utilisateur sur la pile applicative, voire directement dans la ligne de commande, pour parvenir à une exécution de commande arbitraire.
Les scans initiaux de l'appareil suggèrent que la seule ressource exposée était la console d'administration web, accessible aux utilisateurs authentifiés sur l'interface LAN via HTTP sur le port TCP 80. L'appareil peut offrir davantage de services, mais ceux-ci ne sont pas activés par défaut. Par conséquent, cette enquête se concentre uniquement sur l'interface web.
Un scan nmap de l'appareil exemple, montrant uniquement l'interface web à l'écoute.
Les tests habituels — comme les injections de commande typiques sur les panneaux de diagnostic de l'appareil qui permettent une injection de commande dans les paramètres d'une commande ping ou traceroute — n'ont pas donné de résultats immédiatement intéressants, ce qui était décevant.
Options de gestion disponibles après authentification sur le panneau d'administration web. "Stockage USB" apparaît comme la deuxième option.
La première interface (finalement exploitable) examinée ici se trouvait sur le panneau "Stockage USB", visible comme la deuxième option dans la capture d'écran ci-dessus. L'appareil dispose d'un port USB adjacent à ses prises Ethernet 802.2, suggérant qu'il pourrait offrir une fonctionnalité de stockage en réseau (NAS).
Une photographie de l'arrière de l'exemplaire réel, montrant la disponibilité USB.
Un principe simple en recherche de vulnérabilités est que plus un morceau de code interagit avec de composants et plus il comporte de pièces mobiles, plus il est probable que du code exploitable se cache à proximité. La présence de capacités NAS est prometteuse car elle indique la présence de code qui interagit simultanément avec la couche logicielle de l'appareil, la couche matérielle et la périphérie branchée (le stockage USB lui-même).
L'interface de gestion de la console de stockage USB est présentée ci-dessous. La simple présence du champ "Groupe de travail" est prometteuse, car cela suggère que ce routeur WiFi pourrait même tenter d'interagir via le protocole Server Message Block (SMB) — une lourde tâche pour un routeur IoT. Je ne compte plus le nombre de fois où j'ai vu une entrée fournie par l'utilisateur envoyée directement à la ligne de commande comme argument de la fonction Unix smbpasswd.
Options de stockage USB disponibles pour les utilisateurs authentifiés.
Les tentatives initiales de modification de ces paramètres ont échoué car l'appareil ne détectait pas de disque USB, comme on le voit ci-dessous.
Les modifications de configuration des options de stockage USB ne seront pas enregistrées à moins qu'un disque correctement formaté ne soit branché manuellement sur le port USB de l'appareil.
Cependant, une fois un disque correctement formaté branché, l'appareil a permis de définir un nom d'utilisateur et un mot de passe FTP. Comme suspecté, il a placé cette entrée utilisateur sur la ligne de commande :
Une injection de commande dans le champ 'mot de passe' offre le premier accès shell directement au système d'exploitation de l'appareil.
Bien qu'intéressante, cette vulnérabilité est difficile à considérer comme très excitante : elle nécessite non seulement un accès authentifié à l'interface d'administration de l'appareil, mais aussi un accès physique à l'appareil pour manipuler son disque USB. L'exploit ci-dessus permet à un chercheur d'interagir avec les composants individuels du système d'exploitation (et de les exfiltrer à des fins de rétro-ingénierie).
L'appareil était un système Linux basé sur busybox avec une interface web alimentée par Lighttpd. La fonctionnalité CGI (Common Gateway Interface) était assurée par des binaires individuels dans /etc_ro/lighttpd/www/cgi-bin/, les requêtes web vers les URI CGI lançant ces binaires directement. Un rapide coup d'œil à nas.cgi dans Ghidra montre l'injection de commande à la ligne 38 ci-dessous, qui envoie un mot de passe fourni par l'utilisateur directement à la fonction do_system (elle-même simplement une enveloppe autour de l'appel système standard de la libc).
L'entrée utilisateur est placée sur la ligne de commande comme argument du script chpasswd.sh à la ligne 38, résultant en une injection de commande et un accès shell directement au système d'exploitation de l'appareil.
En parcourant le répertoire /cgi-bin/, la tâche de trouver un exploit plus intéressant se réduit à énumérer les interfaces CGI disponibles pour l'utilisateur, comme montré ci-dessous :
Une liste exhaustive des binaires CGI mis à disposition sur l'appareil, prise en direct du shell établi par l'exploit décrit dans cette section.