Viele können sich bereits einen Penetration Test einer Web-Anwendung vorstellen, aber was passiert eigentlich bei einem IoT Pentest? Da wir hier physikalischen Zugriff zur Hardware haben, können wir natürlich deutlich intensiver in das Gerät vordringen. Ein direkter Zugriff auf die Chips ist hilfreich, um weitere Schwachstellen in dem Gerät aufzudecken, aber nicht immer nötig.

Anhand eines Travel Routers (Trendnet TEW-714TRU) möchten wir hier unser Vorgehen erläutern, wie wir bei einem geschlossenen Gerät zu einer Shell kommen, um nach weiteren Schwachstellen zu suchen. Wir wollen uns hier ausschließlich auf die statischen Analysen der Firmware beschränken. Denn wie gewinnt man aus der Binärdatei eines Firmwareupdates die nötigen Informationen, um Schwachstellen aufzudecken, mit welchen man Zugriff zum System bekommt?

Reconnaissance

Was tut es, was sind die wichtigen Aspekte, wobei kann es hier zu Problemen kommen? Da es sich hier um einen Router handelt, ist die Wahrscheinlichkeit sehr groß, dass Eingaben direkt in Konfigurationsdateien landen oder diese Eingaben direkt auf der Konsole ausgeführt werden.

Um aber einen ersten Überblick über das Gerät zu bekommen, ist es hilfreich, es zu starten und, wenn es wie in unserem Fall Netzwerkzugriff hat, mit nmap zu scannen.

Wir sehen läuft hier ein Telnet und zwei Webserver, was für uns gute Angriffsvektoren bedeutet. Telnet ist noch auf einigen Geräten verfügbar und wird gerade erst langsam von einem SSH-Server wie Dropbear abgelöst.

Firmware analysieren

Bei einem Kundengerät hat man hoffentlich die Firmware zur Verfügung gestellt bekommen. Sollte dem nicht so sein, kann man entweder auf sein Glück hoffen, dass diese frei im Internet steht, oder man muss das Gerät aufschrauben, um die Chips auszulesen.

Beim TEW-714TRU ist die neuste Firmware von der Trendnet-Seite herunterladbar. Hierbei handelt es sich um ein “u-boot legacy uImage”, welches man am einfachsten mit binwalk analysiert und weiter entpackt werden kann. Die einfachste Variante, an das dahinterliegende System zu kommen, ist mit binwalk das Image zu scannen und zerlegen.

Nach dem Entpacken des Image mit binwalk -e -M 1.0.4.img befindet sich in einem der letzten Ordner ein root-Verzeichnis, welches zum Teil das Root-Verzeichnis auf dem Gerät widerspiegelt. Da es sich hier nämlich um ein Firmware-Update handelt, werden manche Softlinks nicht aufgelöst, und die meisten Konfigurationsdateien in /etc/ sind auch nicht vorhanden.

Durchsuchen der Dateistruktur

Wir wissen nun, wie die Dateistruktur auf dem Gerät ungefähr aussieht und welche Binärdateien wie aufgerufen werden.

Hier lohnt es sich, nach typischen Begriffen wie “password, passwd”, etc. zu suchen. Auch die Konfigurationsdateien der einzelnen Dienste sind interessant. So sehen wir beispielsweise in der Datei etc_ro/boa_server/boa.conf, dass der Benutzer, der den Webserver ausführt, root ist. So wird unsere Chance, das Gerät komplett zu übernehmen, sollten wir hier eine Code Injection finden, nochmal wesentlich erhöht.

Webinterface

Ein zweiter Aspekt ist das zur Verfügung stehende Webinterface. Es ist durchaus hilfreich, den Code durchzulesen und die Funktionsweise zu verstehen. So kann man einerseits feststellen, dass ASP-Dateien ausgeführt werden und erkennt relativ schnell, dass sämtliche Formulare über eine “action” nach “/goform” geschickt werden.

Bei genauerer Betrachtung sieht man, dass nicht nur “/goform”, sondern auch “/goformX” existiert, worüber anscheinend direkt Befehle an die Shell übergeben werden.

Strike!

Wir haben also einen ersten möglichen Angriffspunkt des Gerätes identifiziert. Um uns das Leben zu erleichtern, testen wir diesen direkt an einem laufenden Router mit dem Befehl ls -l.

Das Webinterface nutzt einen normalen Aufruf an /goformX/formFServX, um Betriebssystem-Kommandos auszuführen und gibt deren Ausgabe zurück. Da der Webserver als root läuft, können wir nun alles ausführen.

Von Command Injection zu einer Shell

Nachdem wir nun eine Command Injection haben, können wir auch direkt die passwd herunterladen, john darauf ansetzen und hoffen, dass das Tool die gesetzten Passwörter identifiziert. Alternativ ist es auch immer eine gute Möglichkeit, die Hashes in Google einzugeben, um zu prüfen, ob diese bereits von einer anderen Person geknackt worden sind. Es kommt häufig vor, dass Passwörter durch Firmware-Sharing auf anderen Geräten landet.

Während die Onlinesuche nichts zu Tage fördert und John dafür, je nach Komplexität des Passwortes, eine Weile braucht, machen wir erstmal an einer anderen Stelle weiter.

Wir haben zwar eine Command Injection, wollen diese aber zu einer kompletten Shell ausweiten.

Es gibt nun mehrere Möglichkeiten, eine Shell auf dem Gerät zu bekommen:

• Wir legen uns einen eigenen Benutzer über die Passwd an
• Wir starten einfach einen eigenen Telnet Service.

Da wir Glück haben und eine busybox mit telnetd auf dem Gerät vorhanden ist, können wir diese einfach starten. Wenn dem nicht der Fall wäre, könnte man immer noch eine vorkompilierte Busybox auf das Gerät bringen und so die Befehle erweitern.

curl http://10.135.98.1/goformX/formFSrvX\?OP\=RCMD\&VN\=0\&SZCMD\=/bin/busybox%20telnetd%20-l%20/bin/sh%20-p%201337 -v

Wir starten also einen Telnet Service über /bin/busybox mit Login Command /bin/sh auf Port 1337. Nach dem Ausführen des Curl-Befehls können wir uns mit netcat oder telnet auf das Gerät verbinden und haben eine Shell.

Weiteres Vorgehen

Nun haben wir eine funktionierende Root-Shell auf dem Gerät. Mit Hilfe dieser kann nun die komplette Dateistruktur eines laufenden Gerätes analysiert werden, welches sich meistens von statischen Firmware-Updates signifikant unterscheidet, da bei einem Update nicht immer alles neu aufgespielt wird und teilweise Links nur im laufenden Zustand gebaut werden.

Zudem können wir nun die laufenden Binaries laden und sie in IDA oder anderen Disassemblern unter die Lupe nehmen, um so weitere Schwachstellen zu identifizieren.

Mit dem Webinterface kann nun “normal” wie mit einer Webanwendung verfahren werden, wobei man natürlich nun auch den Quellcode zur Verfügung hat und so seltsames Verhalten und Schwachstellen schneller identifiziert.

Fazit

Meist ist ein Aufschrauben des Gerätes nicht notwendig, um an die notwendigen Informationen zu gelangen. Natürlich ist ein Penetration Test hiermit nicht getan und es müssen noch die gängigen Überprüfungen der einzelnen Dienste durchgeführt werden, doch haben wir uns mit der ersten kritischen Schwachstelle den Audit wesentlich erleichtert.

Bei der demonstrierten Schwachstelle handelt es sich um einen fundamentalen Fehler im Design der gesamten Applikation. Da diese Funktion im Webinterface aufgerufen wird, ist sie gravierend und kann nicht schnell ersetzt werden. Dies hätte durch einen agilen Penetrationtest umgangen werden können.

Natürlich unterstützen wir Sie auch gerne im Rahmen einer Beratung zur sicheren Software-Entwicklung!