VM: My File Server:1 – Vulnhub
Quelle: www.vulnhub.com
Ziel: Kontrolle übernehmen und proof.txt auslesen.
Tools: NMAP, DIRB, linux-exploit-suggester-2
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 |
| 80 | HTTP |
| 111 | RPC Bind (Portmapper) |
| 445 | SMB |
| 2049 | NFS |
| 2121 | FTP |
| 20048 | mountd |
Wir werden nicht auf alle diese Ports eingehen, damit die Lösung nicht unnötig lang wird.
Schritt 2: Enumeration
Port 21 – FTP Server
Wie wir schon beim NMAP-Scan sehen können, ist ein Anonymes Zugriff auf den FTP-Server möglich. Nach einer Verbindungsaufbau können wir mehrere Dateien und Ordner sehen. Leider haben wir nicht auf alle Dateien lese Berechtigungen. Ich kopiere die Dateien auf mein System zur späteren Analyse.
Port 22 – SSH Server
Zu diesem Zeitpunkt können wir hier keine nützliche Information gewinnen.
Port 80 – HTTP Server
Wenn wir die IP-Adresse im WEB-Browser aufrufen, bekommen wir einen Link auf eine externe Seite und ein Text „My File Server„. Damit kann man leider nicht viel anfangen. Ein Scan mit dem DIRB und dem Standard Wörterbuch lieferte keine nutzbaren Ergebnisse. Dann habe ich ein Wörterbuch aus Seclists Sammlung genommen und könnte eine weitere sehr interessante Datei finden.
Der Inhalt von der readme.txt ist:
My Password is
rootroot1
Jetzt haben wir ein Passwort aber noch keinen Benutzer dazu.
Port 111 – RPC Bind
Zu diesem Zeitpunkt können wir hier keine nützliche Information gewinnen.
Port 445 – SMB
Mit dem Befehl sudo smbclient -L 192.168.178.99 sehen wir uns die über SMB freigegebene Ordner.
Hier können wir zwei Kommentare sehe, die auch Benutzernamen sein können.
Port 2049 – NFS
Mit dem Befehl showmount -e 192.168.178.99 sehen wir die über NFS freigegebene Ordner.
Leider sehen wir auch dabei, dass es nur aus dem 192.168.56.0/24 Netz erreichbar ist. Also müssen wir die IP-Bereiche des Hosts und der VM ändern, um auf die Freigabe zugreifen zu können.
Port 2121 – FTP
Zu diesem Zeitpunkt können wir hier keine nützliche Information gewinnen.
Port 20048 – mountd
Zu diesem Zeitpunkt können wir hier keine nützliche Information gewinnen.
Schritt 3: Analyse und Zusammenfassung
Bei der Analyse der über den FTP-Server heruntergeladenen Dateien könnten folgende Informationen gewinnen:
Datei wtmp – in der Datei wtmp werden alle Logins gespeichert. Die Datei kann man mit dem Befehl last -f wtmp auswerten.
Wie auf dem Ausschnitt zu sehen ist, haben sich in der Vergangenheit 3 Benutzer eingeloggt:
armour root smbuser
Der Benutzer smbuser deckt sich mit dem über den SMB-Share gesehen Kommentar.
Außerdem haben wir in der Datei readme.txt ein mögliches Password gefunden. Falls wir mit diesen Informationen nicht weiterkommen, bleibt als Möglichkeit noch das IP-Bereich unserer Systeme zu ändern um aus dem 192.168.56.0/24 Bereich zu kommunizieren.
Schritt 4: Exploration
Versuchen wir zuerst eine SSH Verbindung mit den gefundenen Benutzer herzustellen.
Dabei sehen wir, dass kein Passwort abgefragt wird und nur die Meldung „smbuser@192.168.178.99: Permission denied (publickey,gssapi-keyex,gssapi-with-mic)“ angezeigt wird. Diese zeigt uns mögliche Authentifizierungsmethoden wie public key oder gssapi.
Ein Zugriff über die SMB-Freigabe funktionierte nicht. Dafür könnten wir aber per FTP mit dem Benutzer smbuser und dem Passwort rootroot1 in ein leeres /home/ftpuser Verzeichnis einloggen.
So wie es aussieht, haben wir Zugriff auf das Home Verzeichnis von dem Benutzer smbuser. Wir können versuchen ein ssh-key Paar mit ssh-keygen zu generieren und in dem Ordner hinterzulegen.
Jetzt müssen wir den public key in die /home/smbuser/.ssh/authorized_keys Datei ablegen. Dafür erstellen wir ein .ssh Verzeichnis und legen da die in authorized_keys umbenannte id_rsa.pub Datei. Jetzt können wir uns mit dem Befehl „ssh -i id_rsa smbuser@192.168.178.99“ eine SSH -Verbindung mit dem Server herstellen.
Schritt 5: Privilege Escalation
Jetzt, wo wie eine SSH Verbindung mit dem Server haben, können wir nach weiteren Möglichkeiten suchen die Maschine zu übernehmen. Dazu lade ich meine Exploration Skripte per FTP hoch und versuche diese auszuführen. Leider hat es mit dem LinEnum.sh nicht funktioniert, dafür könnte ich mit perl linux-exploit-suggester-2.pl nach möglichen Exploits suchen.
Es werden 4 mögliche Exploits ausgegeben. Direkt mit entsprechenden Links dazu. Dirty_cow haben wir früher schon mal benutzt, fangen wir damit an. Dazu laden wir den Exploit von www.exploit-db.com, kopieren es auf den Server und versuchen zu kompilieren.
gcc 40616.c -o cowroot -pthread
Nachdem es kompiliert wurde, führen wir den fertigen Exploit aus.
chmod +x cowroot
./cowroot
Nachdem der Exploit fertig ist (evtl. mehrmals starten), können wir die /root/proof.txt Datei auslesen und haben volle Kontrolle über den Server.
Ich freue mich über Ihre Kommentare.