Man möchte meinen im Jahr 2023 ist das Bewusstsein für unsichere, vom Internet aus erreichbaren IoT-Geräten inzwischen vorhanden – falsch gedacht. So unterhaltsam dieser Hack einerseits war, so besorgniserregend ist die Tatsache, wie einfach es ist, über den Web-Zugriff einer Kamera RCE (Remote Command Execution) zu erlangen.
Shodan ist immer ziemlich praktisch, wenn es darum geht Geräte und Services für eine bestimmte Organisation zu finden, die aus dem Internet aus erreichbar sind. Das geht am einfachsten über den „org“ Tag (Freelancer-Subscription notwendig):
Eines der Geräte schien auffällig zu sein mit den offenen Ports 80 und 8001 und veralteter Softwarekomponenten (siehe Vulnerabilities):
Ein Aufruf von Port 80 kommt man auf eine Webapplikation die zwei Kamerabilder anzeigt. Zweck der Applikation ist es, die Parkplatzsituation auf dem Unternehmensgelände zu organisieren.
Viel interessanter ist jedoch der Aufruf von Port 8001:
Dabei erscheint eine Login-Seite zum Managen des jeweiligen Kamera-Systems. Bevor die Suche nach potentiellen Schwachstellen (z.B. im JavaScript Sourcecode) losgeht, zahlt es sich oft aus Standard-Credentials wie z.B. admin:admin, test:test, oder root:root auszuprobieren. In diesem Fall funktionierte keine der genannten Kombinationen, aber es muss auch nicht immer gleich ein Admin-Zugang sein… 😉 Oftmals reichen auch niedrig-privilegierte User-Accounts, mit denen man später seine Rechte ausweitet. Einer dieser Standard-Credentials ist guest:guest:
Diese Kombination funktioniert und man wird direkt auf die System-Ansicht weitergeleitet:
Wie vorher schon erwähnt, ist der nächste Schritte Admin-Berechtigungen zu erlangen. Beim Klick auf das User-Menü, erscheint allerdings eine Fehlermeldung:
Da mein lokaler Web-Proxy (Burp Suite) beim Klicken auf das User-Menü keinen Web-Traffic erkennt, ist davon auszugehen, dass das User-Management im JavaScript-Code gesteuert ist (also Client-seitig).
In der index.js ist zu sehen, dass ein Cookie namens „authLevel“ abgefragt wird. Sobald der Wert des Cookies 255 entspricht, gibt die Funktion „CheckAuth“ true zurück.
Sobald der Cookie-Wert entsprechend gesetzt wird, ist das User-Menü aufrufbar:
Das Passwort des Admin-Users ist nur per JavaScript Feld-Typ „password“ verschleiert und kann durch Ersetzen von des „text“-Typs sichtbar gemacht werden:
Da wir mit dem gesetzten „authLevel“-Cookie aber sowieso schon Admin-Rechte besitzen, ist das Admin-Passwort nicht mehr unbedingt notwendig.
Später hat sich übrigens herausgestellt, dass das User-Menü per direktem Aufruf und ohne Authentifizierungs-Cookie – also http://[IP]:8001/web/user.html – ebenso aufgerufen werden kann. Sofern dieser Endpoint vorab erraten werden konnte.
Mit den höchsten Berechtigungen können wir nun sämtliche Einstellungen verändern, wie z.B. das Video-Material an eine bestimmte E-Mail weiterzuleiten:
Das Sahnehäubchen eines jeden Hacks ist jedoch meist das dahinterliegende System (auf dem die Kamera-Webapplikation läuft) unter Kontrolle zu bringen – sprich Remote Command Execution (RCE) zu erlangen.
Beim Browsen durch die Menüs sind einige Request besonders interessant, wie z.B. http://[IP]:8001/cgi-bin/getwifiattr.cgi mit dem das lokale WIFI-Passwort ausgelesen werden kann:
Auch interessant ist das Auslesen des Passworts für die direkte P2P-Verbindung mit der Kamera:
Der interessanteste Aspekt einiger dieser Request ist, dass oftmals CGI-Scripts verwendet werden. Diese basieren oft auf Bash-Scripts, was die Wahrscheinlichkeit für Bash-Code Injection ziemlich erhöht. Um herauszufinden, ob die Webapplikation für derartige Angriffe anfällig ist, ersetzt man bestimmte Parameter mit Bash-Befehlen:
Original
http://[IP]:8001/cgi-bin/p2p.cgi?cmd=p2p.cgi&-action=get
Bash-Injection mit Linux-Befehl „ls“
http://[IP]:8001/cgi-bin/p2p.cgi?cmd=p2p.cgi&-action=ls
Um sicher zu sein, dass die eingegebenen Befehle auch wirklich ausgeführt werden, benötigt man eine Möglichkeit, auf seinen eigenen Systemen checken zu können, ob Verbindungen vom Zielsystem hergestellt werden. Man spricht dabei vom sogenannten Out-of-Band Application Security Testing (OAST).
Eine der Optionen ist das Senden von Web-Requests z.B. via curl oder wget. Diese Programme sind auf vielen Linux-basierten Systemen (vor-) installiert.
Der Befehl oben setzt voraus, dass auf unserer (Angreifer-) Seite ein Webserver auf Port 80 läuft. Mit ein bisschen Glück können wir den einlangenden Web-Request überprüfen:
Der nächste Schritt besteht darin eine Möglichkeit zu finden, den Befehls-Output zu überprüfen. Wenn zum Beispiel „cat /etc/passwd“ eingegeben wird, wollen wir den Inhalt der passwd-Datei checken.
Es gibt viele Möglichkeiten dies zu bewerkstelligen, eine davon ist das Mitsenden der Infos direkt über den wget-Request:
Auf unserer Seite sieht das dann wie folgt aus:
An diesem Punkt könnte man eigentlich aufhören, da das System als vollständig kompromittiert gilt. Um auf dem Ziel-System aber „stabil arbeiten“ arbeiten zu können, benötigt es eine interaktive Reverse Shell.
Da leider weder Netcat auf dem Zielsystem installiert ist, noch andere Reverse Shell Techniken funktionieren, versuchen wir mit dem Befehl „uname -a“ Informationen zum Betriebssystem herauszufinden:
Der Output lässt vermuten, dass sich dabei um ein ARM-System handelt, das oft bei Raspberry Pis verwendet wird. Dieses Wissen ist insofern wichtig, da wir versuchen 1) den C Source-Code einer einfachen Reverse Shell auf unserem System zu kompilieren, 2) auf das Ziel-System zu kopieren und 3) anschließend auszuführen.
1) Um auf dem Zielsystem den Reverse Shell C-Code ausführen zu können, müssen wir ihn mit einem geeigneten Cross-Compiler auf unserem System kompilieren:
Nachdem beim Kompilieren keine Fehler aufgetreten sind, können wir die gerade erstellte Executable-Datei überprüfen, ob sie auch wirklich für das Zielsystem kompiliert wurde (ARM):
2) Als nächstes müssen wir unsere frisch kompilierte Reverse Shell auf unser Ziel-System transferieren. Das machen wir am besten wieder mit wget:
Um die Datei ausführen zu können, müssen wir noch die entsprechenden Execution-Berechtigungen setzen:
Danach überprüfen wir mit „ls -la“, ob die entsprechenden Rechte auch gesetzt worden sind:
Die entsprechende Response auf unserem Web-Server zeigt, dass unsere Reverse Shell nun ausführbar ist:
3) Bevor wir nun die Datei ausführen, muss noch ein Listener auf unserem Angreifer-Server gestartet werden, um unsere Reverse Shell empfangen zu können. Danach können wir z.B. mit „ls“ den ersten Befehl auf dem Ziel-System ausführen:
Mit „uname“ und „whoami“ können wir uns noch einmal die OS-Version anzeigen lassen und checken in welchem Kontext (bzw. mit welchen Berechtigungen) wir auf dem System Befehle ausführen können:
In diesem Fall fällt der Privilege Escalation Teil weg, da wir mit dem „root“-User sowieso schon die höchsten Rechte haben.
Schlusswort
Glücklicherweise war die IP -Kamera nicht mit der internen Unternehmens-Infrastruktur verbunden. Was aus meiner Sicht gleichzeitig schade ist, denn hier beginnt üblicherweise der wahre Spaß… 😉
Der Kamera-Hersteller reagierte noch nicht auf die gemeldeten Schwachstellen. Dies ist ein weiterer Grund, IoT-Geräte mit Bedacht zu wählen und sicherzustellen, dass sie ordnungsgemäß gepflegt werden und über ein ausgereiftes Sicherheitsniveau verfügen (z. B. keine Standard-Passwörter).
In diesem Sinne: Passt auf, welche Geräte ihr wie ins Internet hängt!
