Eine Implementierung eines Proof-of-Concepts für CVE-2020-12124
ursprünglich auf https://www.klogixsecurity.com/scorpion-labs-blog/anatomy-of-an-iot-exploit-from-hands-on-to-rce
von David E. Baker, veröffentlicht am 1. Juni 2023
Dieser Aufsatz befasst sich mit der Firmware des Wavlink Wireless-AC1200 Gigabit Routers ab Juni 2020. Die hier diskutierten Schwachstellen wurden möglicherweise vom Hersteller gepatcht oder auch nicht, aber dies ist ein Fall von Schwachstellenforschung, bei dem die Reise selbst die Belohnung darstellt, nicht das Ergebnis. Der Autor führte diese Forschung vor der öffentlichen Offenlegung der Schwachstellen durch, jedoch nachdem sie von anderen Forschern unabhängig entdeckt und dem Hersteller gemeldet worden waren.
Der Hersteller stellt die Firmware für seine Produkte im Support-Bereich seiner Website zur Verfügung; dies ist eine gängige Methode, um IoT-Firmware zu erhalten und eine hilfreiche Alternative zum Extrahieren aus dem Gerätespeicher. Die Firmware ist unverschlüsselt, sodass sie leicht mit binwalk extrahiert werden kann. Die dynamische Analyse wurde mit Zugriff auf ein physisches Exemplar des Geräts durchgeführt, die statische Analyse mit Ghidra.
Die Weboberfläche des Wavlink Wireless-AC1200 Gigabit Routers verfügt über mehrere anfällige Endpunkte, die das uneingeschränkte Kopieren von benutzerbereitgestellten Daten auf den Anwendungsstack oder sogar direkt in die Befehlszeile ermöglichen, um beliebige Befehle auszuführen.
Erste Scans des Geräts deuten darauf hin, dass die einzige exponierte Ressource die administrative Webkonsole war, die authentifizierten Benutzern auf der LAN-Schnittstelle über HTTP auf TCP-Port 80 zugänglich ist. Das Gerät kann weitere Dienste anbieten, diese sind jedoch standardmäßig nicht aktiviert. Daher konzentriert sich diese Untersuchung ausschließlich auf die Weboberfläche.
Ein nmap-Scan des Exemplargeräts zeigt nur die lauschende Weboberfläche.
Die üblichen Tests – wie die typischen Befehlsinjektionen auf Diagnosetafeln von Geräten, die eine Befehlseinschleusung in den Parametern eines Ping- oder traceroute-Befehls erlauben – brachten keine sofort interessanten Ergebnisse, was enttäuschend war.
Verwaltungsoptionen nach Authentifizierung im administrativen Webpanel. „USB-Speicher“ ist als zweite Option zu sehen.
Die erste (letztendlich ausnutzbare) Schnittstelle, die hier untersucht wurde, befand sich im Panel „USB-Speicher“, das im obigen Screenshot als zweite Option zu sehen ist. Das Gerät verfügt über einen USB-Anschluss neben seinen 802.2-Ethernet-Steckern, was darauf hindeutet, dass es NAS-Funktionalität (Network-Attached Storage) bieten könnte.
Ein Foto der Rückseite des tatsächlichen Exemplars, das die USB-Verfügbarkeit zeigt.
Ein einfaches Prinzip in der Schwachstellenforschung ist: Je mehr Komponenten ein Codeabschnitt umfasst und je mehr bewegliche Teile er hat, desto wahrscheinlicher ist es, dass ausnutzbarer Code in der Nähe lauert. Das Vorhandensein von NAS-Fähigkeiten ist vielversprechend, da es auf Code hinweist, der gleichzeitig mit der Softwareebene, der Hardwareebene und der angeschlossenen Peripherie (dem USB-Speicher selbst) interagiert.
Die Verwaltungsoberfläche für die USB-Speicherkonsole ist unten dargestellt. Allein das Vorhandensein des Feldes „Arbeitsgruppe“ ist vielversprechend, da dies darauf hindeutet, dass dieser WLAN-Router möglicherweise sogar über SMB (Server Message Block) zu interagieren versucht – eine große Herausforderung für einen IoT-Router. Ich kann nicht zählen, wie oft ich gesehen habe, dass benutzereingegebene Daten direkt als Argument an die Unix-Funktion smbpasswd an die Befehlszeile übergeben wurden.
USB-Speicheroptionen, die authentifizierten Benutzern zur Verfügung stehen.
Erste Versuche, diese Einstellungen zu manipulieren, schlugen fehl, da das Gerät kein USB-Laufwerk erkannte, wie unten zu sehen.
Konfigurationsänderungen an USB-Speicheroptionen werden nicht gespeichert, es sei denn, ein entsprechend formatiertes Laufwerk wird manuell in den USB-Anschluss des Geräts eingesteckt.
Sobald jedoch ein korrekt formatiertes Laufwerk eingesteckt war, erlaubte das Gerät die Festlegung eines FTP-Benutzernamens und -Passworts. Wie vermutet, übergab es diese benutzereingegebenen Daten an die Befehlszeile:
Eine Befehlsinjektion im Feld „Passwort“ ermöglicht den ersten Shell-Zugriff direkt auf das Betriebssystem des Geräts.
Obwohl interessant, ist es schwierig, sich über diese Schwachstelle übermäßig zu freuen: Sie erfordert nicht nur authentifizierten Zugriff auf die administrative Schnittstelle des Geräts, sondern auch physischen Zugriff auf das Gerät, um dessen USB-Laufwerk zu manipulieren. Der obige Exploit ermöglicht es einem Forscher, mit den einzelnen Betriebssystemkomponenten zu interagieren (und sie für Reverse-Engineering-Zwecke zu extrahieren).
Das Gerät war ein BusyBox-zentriertes Linux-System mit einer Weboberfläche, die von Lighttpd betrieben wurde. Die CGI-Funktionalität (Common Gateway Interface) wurde durch einzelne Binärdateien in /etc_ro/lighttpd/www/cgi-bin/ bereitgestellt, wobei Webanfragen an CGI-URIs diese Binärdateien direkt starteten. Ein kurzer Blick auf nas.cgi in Ghidra zeigt die Befehlsinjektion in Zeile 38 unten, die ein benutzereingegebenes Passwort direkt an die Funktion do_system übergibt (die selbst nur ein Wrapper um den Standard-Libc-Systemaufruf ist).
Benutzereingabe wird in Zeile 38 als Argument an das Skript chpasswd.sh in die Befehlszeile eingefügt, was zu einer Befehlsinjektion und Shell-Zugriff direkt auf das Betriebssystem des Geräts führt.
Ein Durchsuchen des /cgi-bin/-Verzeichnisses reduziert die Aufgabe, einen interessanteren Exploit zu finden, auf die Auflistung der CGI-Schnittstellen, die dem Benutzer zur Verfügung stehen, wie unten gezeigt:
Eine erschöpfende Liste der auf dem Gerät verfügbaren CGI-Binärdateien, direkt aus der Shell entnommen, die durch den in diesem Abschnitt beschriebenen Exploit eingerichtet wurde. Benutzereingabe wird in Zeile 38 als Argument an das Skript chpasswd.sh in die Befehlszeile eingefügt, was zu einer Befehlsinjektion und Shell-Zugriff direkt auf das Betriebssystem des Geräts führt.
Mehrere Dinge fallen bei der ersten Untersuchung auf. Das erste wichtige Detail ist, dass die CGI-Binärdateien oft die Funktion check_valid_user aufrufen. Diese Methode prüft, ob die IP-Adresse, die die Anforderung stellt, in einer bestimmten temporären Datei im Dateisystem gespeichert ist. Minimale Tests zeigen, dass der Authentifizierungsstatus eines Clients erst bei Aufruf dieser Methode überprüft wird, sodass die gesamte Codeoberfläche in jeder CGI-Binärdatei vor dem Aufruf dieser Funktion ohne Authentifizierung zugänglich ist.
Die Dekompilierung von adm.cgi zeigt die Methode check_valid_user. Der gesamte Code vor diesem Aufruf wird ausgeführt, bevor der Authentifizierungsstatus des Anforderers überprüft wird.
Eine weitere interessante Beobachtung ist die große Anzahl von Methoden, die benutzereingegebene Daten direkt auf den Stack kopieren. Beispielsweise zeigt die Dekompilierung von wireless.cgi den Parameter NewName, der aus dem Körper einer Webanfrage in den Zeilen 14 und 15 übernommen wird, gefolgt von einem ungeschützten strcpy dieser Benutzereingabe auf den Stack in Zeile 34, wie unten gezeigt:
Zeilen 14 und 34 zeigen ein ungeschütztes strcpy des Parameters NewName aus dem Anforderungskörper direkt auf den Programmstack. Die Dekompilierung von adm.cgi zeigt die Methode check_valid_user. Der gesamte Code vor diesem Aufruf wird ausgeführt, bevor der Authentifizierungsstatus des Clients überprüft wird.
Dieses Kopieren von Benutzereingaben auf den Stack allein deutet auf einen Speicherkorruptions-Exploit hin, der mit dem folgenden Befehl überprüft werden kann:
curl -XPOST --data "page=SetName&NewName=\`python3 -c 'print(\\"A\\"*(512))'\`" http://target-ip/cgi-bin/wireless.cgi
Obwohl vielversprechend, ist ein Return-Oriented-Angriff hier nicht optimal. Mit dem bereits erlangten Shell-Zugriff auf das Betriebssystem zeigt der folgende Befehl eine '1' an, was bedeutet, dass ASLR (Address Space Layout Randomization) schwach durchgesetzt wird, sodass eine ROP-Kette nur eine Chance von 1 zu 256 hat, auf dem gewünschten Gadget zu landen:
# cat /proc/sys/kernel/randomize_va_space
1
Darüber hinaus zeigt der Befehl unten, dass die Little-Endian-Binärdateien mit gesetztem Stack-Guard-Byte kompiliert wurden, sodass nur das letzte Gadget in einer Kette an einer vorbestimmten Stelle innerhalb der Binärdatei landen kann. Wenn ein Watchdog-Prozess vorhanden ist, der den Webserver nach einem Absturz neu startet, ist es nicht ausgeschlossen, wiederholt einen Return-Oriented-Exploit zu werfen und schließlich Erfolg zu haben, aber es ist auch möglich, dass an anderer Stelle im Code bessere Bugs lauern.
xxd /etc_ro/lighttpd/www/cgi-bin/wireless.cgi | head -n 10
Wenn man weiter durch die CGI-Funktionen schaut, stößt man schließlich auf live_api.cgi. Diese Binärdatei ruft check_valid_user nicht auf, daher laufen alle Webanfragen an den URI /cgi-bin/live_api.cgi diese CGI-Anwendung ohne Authentifizierung. Zeile 9 in Abbildung 11 zeigt, dass die Umgebungsvariable QUERY_STRING, die (gemäß der Apache-CGI-Spezifikation) der Teil des Anfrage-URI unmittelbar nach einem Fragezeichen und daher benutzerbereitgestellt ist, in pcVar1 gespeichert und in Zeile 19 von Abbildung 11 an die Methode satellite_status gesendet wird.
Eine Dekompilierung von live_api.cgi zeigt, dass Benutzereingaben aus dem URI in Zeile 9 übernommen und in Zeile 19 an satellite_status gesendet werden. Die Dekompilierung von adm.cgi zeigt die Methode check_valid_user. Der gesamte Code vor diesem Aufruf wird ausgeführt, bevor der Authentifizierungsstatus des Clients überprüft wird.
Die Dekompilierung der Methode satellite_status, gezeigt in Abbildung 12, zeigt, dass die Abfragezeichenfolge selbst (jetzt param_1) nach den Parametern page, id und ip durchsucht wird. Der Parameter ip wird über die Funktion sprintf in Zeile 38 von Abbildung 12 in eine lokale Variable kopiert und in Zeile 39 an die Funktion do_system übergeben. Das Fehlen eines Aufrufs von check_user_auth zeigt, dass eine beliebige Client-Eingabe eines nicht authentifizierten Benutzers im URI direkt in die Befehlszeile im URI-Parameter ip eingefügt wird, bestätigt durch Folgendes:
Eine Dekompilierung der Funktion satellite_status, die zeigt, wie die Abfragezeichenfolge (jetzt param_1) in den Zeilen 22 und 23 nach dem Parameter ip durchsucht wird, dann zu einem Aufruf von do_system in den Zeilen 38 und 39 führt.
Der Beweis liegt im Pudding, der zeigt, wie der Exploit verwendet wird, um eine Remote-Übernahme des Geräts zu bewirken.
Das Finden von Exploits in einem neu auf den Markt gekommenen IoT-Gerät mag wie eine niedrig hängende Frucht erscheinen, wie zu Beginn dieses Beitrags erwähnt, aber der Wert dieser Untersuchung lag eher in der Reise als im Ziel.
Ein Verständnis der Umgehung der Authentifizierung und der Lokalisierung der Befehlsinjektion wäre ohne statische Analyse der Firmware unwahrscheinlich oder sogar unmöglich gewesen. Wäre sie nicht online verfügbar gewesen, hätte es dynamischen Zugriff auf das Betriebssystem des Geräts erfordert, um sie zu erhalten, wofür die Chancen auf dynamischen Zugriff auf das Gerät gering gewesen wären. Diese Zugriffsebene selbst beruhte sowohl auf physischem Zugriff auf das Gerät als auch entweder auf spezialisierter Hardware oder einer fundierten Vermutung über die wahrscheinlichen Stellen im Code, an denen Fehler gemacht worden sein könnten.
Wir hoffen, Ihnen hat diese Reise gefallen und Sie kommen wieder. Happy Hacking!
Autor:
David Baker, Senior Security Consultant, Testing, K logix