heventafese/penetration-testing-walkthrough-hacksudo-thorBlack-box penetration test against HackSudo Thor : CVE-2014-6271 Shellshock RCE through Apache mod_cgi, chained with sudo misconfiguration and bash eval injection for full privilege escalation. Includes custom CSRF-aware brute force tooling and Metasploit RPC automation.
Ziel: HackSudo Thor von VulnHub
Aufgabe: Root-Zugriff erlangen und/root/proof.txtlesen
Umgebung: Isolierte VirtualBox-Lab-Umgebung, segmentiert durch eine pfSense-Firewall
Dieses Repository dokumentiert einen partiellen Black-Box-Penetrationstest, der auf HackSudo Thor durchgeführt wurde – eine absichtlich verwundbare virtuelle Maschine, die von Vishal Waghmare auf VulnHub veröffentlicht wurde. Ziel war es, einen realitätsnahen Angriff zu simulieren, bei dem ein externer Angreifer versucht, ein isoliertes internes System zu kompromittieren. Das primäre Ziel bestand darin, Root-Zugriff zu erlangen und den Inhalt von /root/proof.txt auszulesen.
Die Bewertung folgt dem vollständigen Penetrationstest-Lebenszyklus: passive Aufklärung, Netzwerkermittlung, Enumeration, Schwachstellenbewertung, Exploitation, Privilegieneskalation, Post-Exploitation und Spurenverwischung.
Die primär verwendeten Werkzeuge waren Nmap für das Netzwerk-Scanning, Nessus für die Schwachstellenbewertung und das Metasploit-Framework als zentrale Plattform für Exploitation und Post-Exploitation. John the Ripper, Hashcat und Online-Rainbow-Tables kamen in der Phase des Passwortknackens zum Einsatz, obwohl alle Versuche aufgrund der Stärke des verwendeten Hash-Algorithmus letztlich erfolglos blieben.
Das virtuelle Labor wurde vollständig in VirtualBox aufgebaut und darauf ausgelegt, ein realistisches Unternehmensnetzwerk mit drei verschiedenen Sicherheitszonen abzubilden, die alle von einer pfSense 2.7.2-Firewall verwaltet werden. Die drei NAT-Netzwerke waren wie folgt konfiguriert: eine WAN-Zone, die das öffentliche Internet simuliert, in der sich die Kali-Angreifer-Maschine befindet; eine DMZ-Zone, die das Zielsystem hostet; und eine interne LAN-Zone mit außerhalb des Prüfumfangs liegenden Maschinen.``` Internet Zone — NatNetwork (10.0.2.0/24) │ │ Kali Linux 2025.4 [attacker] — 10.0.2.9 │ pfSense WAN interface — 10.0.2.8 │ ├── pfSense Firewall (boundary device) │ ├── DMZ Zone — DMZnat (10.0.4.0/24) │ ├── HackSudo Thor [TARGET] — 10.0.4.3 │ └── DVWA — 10.0.4.4 (out of scope) │ └── LAN Zone — LANnat (10.0.3.0/24) ├── Metasploitable 2 — 10.0.3.5 (out of scope) └── Windows XP Cyberlab — 10.0.3.4 (out of scope)
*Durch pfSense verwaltete logische Netzwerktopologie-Sicherheitszonen*
Die WAN-Schnittstelle erhielt per DHCP die Adresse `10.0.2.8/24`, die LAN-Schnittstelle wurde auf `10.0.3.1/24` und die OPT1 (DMZ)-Schnittstelle auf `10.0.4.1/24` gesetzt. Um eine bewusste Fehlkonfiguration in das Labor einzuführen, wurde Port 80 absichtlich auf der pfSense-WAN-Schnittstelle offen gelassen, wodurch eine typische reale Admin-Panel-Exposition simuliert wurde, die als primärer Einstiegspunkt in das interne Netzwerk diente.
---
## Zusammenfassung der Angriffskette```
[Kali Linux — 10.0.2.9]
│
│ CSRF-aware Python brute force → admin / pfsense
▼
[pfSense webConfigurator — 10.0.2.8:80]
│
│ Firewall rules disabled → DMZ and LAN now reachable
▼
[HackSudo Thor — 10.0.4.3]
│
│ Shellshock RCE (CVE-2014-6271)
│ Apache mod_cgi → /cgi-bin/shell.sh
▼
[Meterpreter shell — www-data]
│
│ sudo -u thor /home/thor/hammer.sh
│ Command injection via eval → bash -i payload
▼
[Interactive shell — thor]
│
│ GTFOBins: sudo service ../../bin/bash
▼
[Root shell]
│
├── /root/proof.txt captured ✅
├── /etc/shadow + /etc/passwd exfiltrated
└── SSH RSA backdoor planted
Bevor jeglicher Kontakt mit der Zielumgebung aufgenommen wurde, wurden Informationen ausschließlich aus öffentlichen Quellen gesammelt. Die beiden Hauptquellen waren die offizielle VulnHub-Eintragsseite für HackSudo Thor und das öffentliche GitHub-Profil des Autors.
Die VulnHub-Seite bestätigte, dass es sich bei dem Ziel um ein Linux-basiertes System handelte, bewertet als einfach bis mittelschwer, mit dem Ziel, die proof.txt-Flagge zu finden. Die Überprüfung des GitHub-Profils des Autors lieferte zusätzliche Einblicke. Vishal Waghmare entwirft durchgängig Linux-Boot-to-Root-Maschinen mit Privilegieneskalation als Kernherausforderung in der gesamten HackSudo-Reihe. Dies prägte das Bedrohungsmodell für die aktiven Phasen: HTTP- und SSH-Dienste waren die wahrscheinlichste Angriffsfläche, und es wurde vorhergesagt, dass der Eskalationspfad eine falsch konfigurierte sudo-Berechtigung, den Missbrauch von SUID-Binärdateien oder die Ausnutzung eines benutzerdefinierten Dienstes beinhalten würde.
Diese Art der Autorenmusteranalyse ist auch bei einem echten Engagement wichtig. Zu verstehen, wie ein System wahrscheinlich entwickelt wurde und welche Kategorien von Schwachstellen sein Administrator wahrscheinlich wiederholt, gibt eine Richtung vor, bevor auch nur ein einziges Paket gesendet wird.
Diese Phase beinhaltete den direkten aktiven Kontakt mit der Umgebung. Ziel war es, alle aktiven Hosts zu identifizieren, die Netzwerkgrenze zu verstehen und ein Bild der gesamten Angriffsfläche zu erstellen, bevor der Fokus auf das primäre Ziel verengt wurde.
Zunächst wurde ein leichter Nmap-Ping-Sweep (-sn) gegen das WAN-Subnetz (10.0.2.0/24) durchgeführt, um aktive Hosts mit minimaler Geräuschkulisse zu entdecken. Drei Hosts wurden identifiziert: 10.0.2.1 und 10.0.2.2 waren Standard-Adressen der VirtualBox-Infrastruktur, sodass 10.0.2.8 der einzige Nicht-Infrastruktur-Host blieb. Diese Maschine wurde zum unmittelbaren Fokus.
Ein vollständiger SYN-Stealth-Scan gegen 10.0.2.8 lieferte überhaupt keine Ergebnisse. Dies war erwartetes Verhalten und kein Fehler. Unternehmensfirewalls sind darauf ausgelegt, auf Port-Scans nicht zu reagieren, indem sie Pakete stillschweigend verwerfen, anstatt zu antworten. Das Fehlen von Ergebnissen war selbst die Bestätigung, dass es sich um ein Netzwerkgrenzgerät handelte, das den Datenverkehr aktiv filterte.
Um zu bestätigen, welche Dienste tatsächlich liefen, ohne sich auf Paket-Scans zu verlassen, wurde eine direkte HTTP-Anfrage mit curl gestellt. Dieser Ansatz wurde gewählt, da eine Standard-Webanfrage weitaus weniger wahrscheinlich gefiltert wird als ein Scan-Tool. Die Antwort kam als HTTP/1.1 200 OK mit Server: nginx und einem Seitentitel pfSense zurück, was bestätigte, dass der WebConfigurator über das WAN-Interface direkt auf Port 80 erreichbar war.
Nachdem die Anmeldeseite bestätigt war, bestand der nächste Schritt darin, zu versuchen, die Anmeldeinformationen wiederherzustellen. Hydra wurde zunächst als Brute-Force-Tool ausgewählt, aber dieser Versuch scheiterte aus zwei Gründen. Der erste war ein praktischer: rockyou.txt enthält über 14 Millionen Einträge, was es im Rahmen dieser Bewertung unpraktisch macht. Der zweite war technischer und bedeutender: pfSense 2.7.2 implementiert CSRF-Token-Schutz, der bei jedem Seitenladen ein eindeutiges kryptografisches Token generiert, das zusammen mit den Anmeldeinformationen übermittelt werden muss. Hydras HTTP-POST-Modul sendet einen statischen Anforderungstext und hat keinen Mechanismus, um dynamisch ein neues Token pro Versuch abzurufen, sodass jede Übermittlung abgelehnt wurde, bevor das Passwort überhaupt überprüft wurde.
Um dies zu umgehen, wurde ein benutzerdefiniertes Python-Skript geschrieben, das den vollständigen Browser-Anmeldeprozess nachbildet. Bei jedem Passwortversuch öffnet das Skript eine neue Sitzung, lädt die Anmeldeseite, extrahiert das aktuelle CSRF-Token aus dem HTML-Formular und sendet dann die Anmeldeinformationen zusammen mit diesem Token genau so, wie es ein Browser tun würde. Eine benutzerdefinierte Wortliste wurde mit CeWL erstellt, um die pfSense-Anmeldeseite zu durchsuchen und relevante Begriffe zu extrahieren, und dann mit fasttrack.txt ergänzt, um bekannte Standard-Anmeldeinformationen abzudecken.
Das Skript ermittelte die Anmeldeinformationen: admin / pfsense, die unveränderten Standardwerte.
Benutzerdefiniertes Python-Skript zum Wiederherstellen von pfSense-Anmeldeinformationen
Nachdem der Dashboard-Zugriff hergestellt war, wurde die pfSense-Schnittstellenkonfiguration überprüft, um die vollständige interne Topologie zu verstehen. Dies zeigte zwei Subnetze, die vom WAN aus unsichtbar gewesen waren: ein LAN unter 10.0.3.0/24 und ein DMZ unter 10.0.4.0/24. Die WAN-Firewall-Regeln wurden dann über die Weboberfläche deaktiviert, und es wurden zwei Pass-Regeln hinzugefügt, um Datenverkehr von der IP des Angreifers in beide Subnetze zu erlauben.
Nmap-Ping-Sweeps in beiden Subnetzen identifizierten sechs aktive Hosts. Vier davon wurden weiter untersucht, mit Ausnahme von 10.0.4.1 und 10.0.3.1, die zu den pfSense-Gateway-Schnittstellen gehörten. Ein kombinierter Dienst-Erkennungsscan mit Versionserkennung, Standard-NSE-Skripten und Betriebssystem-Fingerprinting wurde gegen alle vier gleichzeitig durchgeführt. Der Abgleich der Ergebnisse mit der passiven Aufklärung identifizierte jede Maschine in der Topologie:
Das Ziel wurde als 10.0.4.3 bestätigt. Alle weiteren Aktivitäten konzentrierten sich ausschließlich auf diese Maschine.
Nach der Identifizierung des Ziels wurde eine tiefere Analyse seiner Dienste durchgeführt, um die Angriffsfläche zu kartieren und praktikable Exploit-Pfade zu bestimmen. Das Metasploit-Framework wurde als primäre Plattform für diese Phase verwendet, insbesondere weil sein PostgreSQL-Backend alle Scan-Ergebnisse über Sitzungen hinweg persistent speichert – Hosts, Dienste und Schwachstellen werden alle in der Datenbank gespeichert und können in späteren Phasen ohne erneutes Scannen referenziert werden.
Vor Beginn wurde Metasploit mit msfdb init initialisiert, die Datenbankverbindung mit db_status überprüft, und alle nachfolgenden Arbeiten wurden innerhalb der msfconsole durchgeführt.
Der Befehl db_nmap wurde verwendet, um einen vollständigen Scan gegen 10.0.4.3 durchzuführen: SYN-Stealth-Scan, Dienst-Versionserkennung, Standard-NSE-Skripte, Betriebssystem-Fingerprinting und alle 65.535 TCP-Ports. Die Ergebnisse wurden automatisch in der Datenbank gespeichert und mit hosts und services abgerufen. Drei Dienste wurden als offen bestätigt: FTP auf Port 21 mit Pure-FTPd, SSH auf Port 22 mit OpenSSH 7.9p1 und HTTP auf Port 80 mit Apache 2.4.38.
Jeder Dienst wurde dann mit gezielten Metasploit-Auxiliary-Modulen weiter enumeriert. Der HTTP-Dienst erhielt die meiste Aufmerksamkeit. Die Module dir_scanner und http_crawler wurden verwendet, um alle zugänglichen Pfade und Endpunkte auf dem Webserver zu kartieren. Der bedeutendste Fund dabei war das Verzeichnis /cgi-bin/ und ein Skript namens shell.sh. Unabhängig davon ergab eine manuelle Überprüfung des HTML-Quellcodes von news.php einen versteckten Kommentar des Autors, der auf das Verzeichnis /cgi-bin/ verwies – ein bewusster Hinweis auf eine CGI-basierte Schwachstelle. Der FTP-Dienst wurde auf anonymen Zugriff überprüft (deaktiviert), und die Versionszeichenfolge wurde für CVE-Querverweise notiert. Der SSH-Banner wurde aus demselben Grund abgerufen.
Nachdem die Angriffsfläche vollständig kartiert war, wurde eine strukturierte Schwachstellenbewertung mit zwei Ansätzen durchgeführt: einem automatisierten Nessus-Scan und manueller Angreiferlogik, die auf jeden Dienst angewendet wurde.
Eine benutzerdefinierte Nessus-Richtlinie wurde erstellt, bei der CGI-Scanning und Webanwendungstests explizit aktiviert waren, mit den Zielports 21, 22 und 80. Diese Einstellungen sind standardmäßig nicht aktiviert und waren hier entscheidend; ohne sie wäre der CGI-Endpunkt nicht getestet worden. Der Scan lief etwa 11 Minuten und lieferte 41 Ergebnisse insgesamt. Die umsetzbaren Ergebnisse waren:
Die beiden Shellshock-Funde auf /cgi-bin/shell.sh hatten sofort Priorität. CVE-2014-6271 hat einen CVSS-Score von 9.8 und ermöglicht nicht authentifizierte Remote-Codeausführung – der Fund mit der höchsten Auswirkung im Scan. CVE-2014-6278 repräsentiert einen unvollständigen Patch derselben Schwachstelle, was bedeutet, dass selbst teilweise gepatchte Systeme ausnutzbar bleiben. Die SSH-Terrapin-Schwachstelle wurde als nicht ausnutzbar ohne eine Man-in-the-Middle-Position bewertet. Die übrigen Funde hatten in diesem Engagement keinen sinnvollen Ausnutzungswert.
Vor dem Übergang zur Ausnutzung wurde der Shellshock-Fund unabhängig mit dem Nmap-NSE-Skript http-shellshock verifiziert, das direkt auf /cgi-bin/shell.sh abzielte. Die unabhängige Verifizierung vor der Ausnutzung ist ein wichtiger Schritt in der Methodik, da sie bestätigt, dass die Schwachstelle real und kein Fehlalarm des Scanners ist, und vermeidet Zeitverschwendung beim Versuch eines Exploits, der nicht funktionieren wird. Das NSE-Skript bestätigte, dass der Endpunkt anfällig war, und CVE-2014-6271 wurde als primärer Angriffsvektor ausgewählt.
Nachdem Shellshock bestätigt war, begann die Ausnutzungsphase. Die Schwachstelle besteht darin, dass Apache mod_cgi HTTP-Anforderungsheader als Umgebungsvariablen an Bash übergibt, wenn ein CGI-Skript aufgerufen wird. In einer ungepatchten Version von Bash führt eine speziell gestaltete Funktionsdefinition in einer Umgebungsvariablen dazu, dass alle nach der Definition angehängten Befehle sofort ausgeführt werden. Durch Injizieren dieser Nutzlast in den User-Agent-Header einer Anforderung an /cgi-bin/shell.sh konnten ohne Authentifizierung beliebige Befehle auf dem Server ausgeführt werden.
Das Metasploit-Modul exploit/multi/http/apache_mod_cgi_bash_env_exec automatisiert dies vollständig. Das Modul wurde mit RHOSTS auf 10.0.4.3, TARGETURI auf /cgi-bin/shell.sh, der Nutzlast auf linux/x86/meterpreter/reverse_tcp und dem Listener, der auf die Kali-Maschine auf Port 4444 zurückzeigt, konfiguriert. Das Ausführen des Moduls sendete die bösartige Anforderung, der Server führte die Nutzlast aus, und Metasploit empfing die eingehende Verbindung, wodurch eine Meterpreter-Sitzung als www-data hergestellt wurde.
Shellshock-Exploit ausgeführt und Meterpreter-Reverse-Shell als www-data hergestellt
Ausgehend von www-data war das Ausmaß des Zugriffs auf das System zunächst unbekannt. Die unmittelbare Priorität bestand darin, die aktuelle Position zu verstehen – wer der aktive Benutzer war, welche anderen Konten existierten und welche Pfade zu höheren Privilegien verfügbar waren.
Die Meterpreter-Sitzung wurde auf eine rohe System-Shell herabgestuft, und ein Pseudo-Terminal wurde mit dem Python-pty-Modul erzeugt, um eine ordnungsgemäße interaktive Shell zu erstellen. Das Lesen von /etc/passwd und das Auflisten von /home/ bestätigten einen Benutzer namens thor auf dem System. Ein anfängliches ls -la /home/thor/ gab "Permission denied" zurück, daher wurde das Dateisystem mit find / -user thor 2>/dev/null nach Dateien durchsucht, die Thor gehörten, unabhängig von Verzeichnisberechtigungen. Dies lokalisierte eine anomale Binärdatei unter /usr/local/sbin/ls, eine Datei namens ls, die nicht die Standard-Systembinärdatei war. Ihr Inhalt zeigte, dass es sich um ein benutzerdefiniertes Skript handelte, das Thor gehörte, was für spätere Untersuchungen notiert wurde.
Der übliche Post-Exploitation-Schritt, die aktuellen sudo-Berechtigungen des Benutzers zu überprüfen, wurde mit sudo -l durchgeführt. Dies zeigte, dass www-data berechtigt war, /home/thor/hammer.sh als Benutzer thor ohne Passwort auszuführen – eine NOPASSWD-Regel ohne legitime betriebliche Rechtfertigung.
sudo -l bestätigt, dass www-data hammer.sh als thor ohne Passwort ausführen kann
Der direkte Zugriff zum Lesen von hammer.sh wurde durch Verzeichnisberechtigungen blockiert, daher wurde es zuerst mit sudo -u thor /home/thor/./hammer.sh ausgeführt, um sein Verhalten zu beobachten. Das Skript zeigte zwei interaktive Aufforderungen: einen "Secret Key" und eine "Secret Message". Die erste Aufforderung gab die Eingabe als Begrüßung zurück. Die zweite verarbeitete die Eingabe und beendete sich dann. Der Unterschied zwischen diesen beiden Verhaltensweisen war signifikant: Wenn beide Aufforderungen die Eingabe einfach nur zurückgeben würden, wäre keine interessant. Die Tatsache, dass die zweite Aufforderung die Eingabe verarbeitete, bevor sie antwortete, deutete darauf hin, dass sie den Wert an einen Shell-Befehl übergab – ein Muster, das mit einer eval-Anweisung konsistent ist, einer gut dokumentierten Angriffsfläche für Befehlsinjektion.
Bei einer zweiten Ausführung wurde eine leere Eingabe an die erste Aufforderung übergeben. Die Injektionsnutzlast bash -i wurde an die zweite geliefert. Dies erzeugte eine interaktive Shell als thor.
bash -i-Nutzlast in hammer.sh injiziert
sudo -l wurde erneut als thor ausgeführt. Dies zeigte uneingeschränkten NOPASSWD-Zugriff sowohl auf /usr/bin/cat als auch auf service als root. Die service-Regel war die bedeutendste. Die GTFOBins-sudo service-Technik erlaubt es, eine Pfad-Traversal-Zeichenfolge als Servicenamen-Argument zu übergeben. Die Angabe von ../../bin/bash führt dazu, dass die service-Binärdatei den Traversal auflöst und /bin/bash mit Root-Rechten aufruft.```bash
sudo service ../../bin/bash
Dies ergab eine vollständige Root-Shell.
*Root-Shell erhalten, GTFOBins sudo service path traversal bestätigt*
## Phase 7: Post-Exploitation
Nach Bestätigung der Root-Identität konzentrierte sich die Post-Exploitation-Phase auf drei Bereiche: Verständnis der Systemumgebung, Extrahieren sensibler Daten und Einrichten dauerhaften Zugriffs.
### Systeminformationen und Flag
Zuerst wurde eine grundlegende System-Enumeration durchgeführt, um die Zielidentität zu bestätigen und Kontext für die Abhilfeempfehlungen zu schaffen, einschließlich Kernel-Version, OS-Release und Netzwerkkonfiguration. Das System wurde als Debian GNU/Linux 10 (Buster) mit Kernel 4.19.0-17-686-pae auf `10.0.4.3` bestätigt.
Das Root-Home-Verzeichnis wurde aufgelistet, was `proof.txt` und `root.txt` zeigte. Die Datei `proof.txt` wurde gelesen, um die primäre Flagge zu erfassen, das erklärte Ziel dieser Übung.
*Inhalt von proof.txt – primäre Flagge erfasst*
### Extraktion von Anmeldeinformationen und Passwort-Knacken
Die Dateien `/etc/shadow` und `/etc/passwd` wurden nach `/tmp` kopiert und über Meterpreter auf die Angreifermaschine heruntergeladen. Diese beiden Dateien zusammen liefern die Systembenutzerkonten und Passwort-Hashes, die für das Offline-Knacken benötigt werden.
Es wurden mehrere Knackansätze versucht. John the Ripper identifizierte beide Hashes als SHA-512crypt mit einem Kostenfaktor von 5.000 Iterationen. Ein erster Versuch mit `rockyou.txt` wurde nach stundenlangem Lauf ohne Ergebnis abgebrochen. Der Rechenaufwand von SHA-512crypt macht erschöpfende Wörterbuchangriffe ohne GPU-Beschleunigung sehr langsam. Ein zweiter Versuch mit einer maßgeschneiderten Wortliste, die aus während der Aufklärung gesammelten Informationen erstellt wurde, war schnell abgeschlossen, brachte jedoch keine Treffer.
Als nächstes wurde CrackStation als Online-Rainbow-Table-Dienst ausprobiert, aber er gab ein unbekanntes Hash-Format für beide Einträge zurück. Dies war erwartet. SHA-512crypt fügt jedem Hash vor dem Hashing ein eindeutiges zufälliges Salt hinzu, was bedeutet, dass dasselbe Passwort für jedes Konto einen anderen Hash erzeugt. Rainbow-Tabellen funktionieren, indem sie Hashes für bekannte Passwörter vorberechnen, aber für jeden möglichen Salt-Wert wäre eine separate Tabelle erforderlich, was den Ansatz gegen gesalzene Hashes völlig unpraktikabel macht.
Hashcat wurde für die letzten Versuche verwendet, mit drei Wortlisten nacheinander: `fasttrack.txt` (in 4 Sekunden erschöpft), eine maßgeschneiderte Liste (ohne Treffer erschöpft) und die oberen 100.000 Einträge aus `rockyou.txt` (nach 3 Minuten fehlgeschlagen). Alle Passwort-Knackversuche waren erfolglos. Die Verwendung von gesalzenem SHA-512crypt mit einer hohen Iterationszahl ist der Grund, warum der Algorithmus so konzipiert ist, dass er rechenintensiv ist, um genau dieser Art von Offline-Angriffen zu widerstehen.
### SSH-Schlüsselsuche
Es wurde auch eine Dateisystemsuche nach RSA-Private-Key-Dateien und PEM-Zertifikaten mit `find` durchgeführt. Jeder gefundene private Schlüssel könnte Zugang zu anderen Systemen gewähren, die dem entsprechenden öffentlichen Schlüssel vertrauen, eine wertvolle Gelegenheit zur Lateralbewegung. Es wurden keine privaten Schlüssel gefunden, die zu anderen Systemen gehören.
### Hintertür-Bereitstellung
Dauerhafter Zugriff wurde implementiert, indem ein RSA-öffentlicher Schlüssel in die Datei `authorized_keys` des Root-Kontos eingefügt wurde. Die SSH-Schlüsselauthentifizierung wurde gewählt, da sie nicht auf Passwörtern basiert und schwer zu erkennen ist, es sei denn, die Datei `authorized_keys` wird speziell überprüft. Ein 4096-Bit-RSA-Schlüsselpaar wurde auf der Kali-Maschine generiert, und der öffentliche Schlüssel wurde an `/root/.ssh/authorized_keys` auf dem Ziel angehängt, mit korrekt eingestellten Verzeichnis- und Dateiberechtigungen. Eine Verbindung zurück zum Ziel mit dem privaten Schlüssel wurde hergestellt, um zu überprüfen, ob die Hintertür funktioniert.
*Dauerhafter Root-Zugriff bestätigt via Private-Key-Authentifizierung*
### Automatisierung
Ein benutzerdefiniertes Metasploit RPC Python-Skript (`thor_full_chain.py`) wurde ebenfalls entwickelt, um die gesamte Post-Exploitation-Kette zu automatisieren. Das Skript verbindet sich mit einer live Metasploit RPC-Sitzung und behandelt die vollständige Sequenz: Shell-Stabilisierung von `www-data`, Injection von hammer.sh zur Eskalation zu thor, GTFOBins-Eskalation zu Root, Flaggen-Erfassung, Extraktion von Anmeldeinformationen und Hintertür-Bereitstellung mit Zeitstempel-Logging, das in einer lokalen Datei gespeichert wird. Dies war ein zusätzliches Ergebnis, das die Fähigkeit zur Automatisierung der Angriffskette mit der Metasploit RPC API demonstriert. Siehe `scripts/thor_full_chain.py` für die vollständige Implementierung.
## Phase 8: Spurenverwischen
Die letzte Phase umfasste das Entfernen von Beweisen des Eindringens sowohl vom Zielsystem als auch von der Kali-Angreifermaschine. Auf dem Ziel war das Apache-Zugriffsprotokoll die kritischste Datei, die gelöscht werden musste, da es die rohe Shellshock-HTTP-Anfrage enthielt, die den initialen Exploit auslöste. Das Auth-Log wurde gelöscht, da es jeden sudo-Befehl speicherte, der während der Eskalationsphase verwendet wurde. Das Syslog, die binären Login-Aufzeichnungen (`wtmp`, `btmp`, `lastlog`) und die Bash-Historie sowohl für `root` als auch für `www-data` wurden alle überschrieben und als leer verifiziert.
Auf Kali wurde der Metasploit-Arbeitsbereich mit `workspace -d default` gelöscht, die heruntergeladenen Anmeldeinformationsdateien wurden entfernt, das SSH-Schlüsselpaar wurde gelöscht und die Bash-Historie wurde gelöscht. Jeder Schritt wurde verifiziert, bevor zum nächsten übergegangen wurde.
Eine bewusste Ausnahme wurde bei der SSH-Hintertür gemacht, und die zugehörigen Schlüsseldateien wurden auf dem Ziel belassen und zu diesem Zeitpunkt nicht entfernt, da sie für Demonstrationszwecke in der Bewertungspräsentation benötigt wurden.
## Ausgenutzte Schwachstellen
| Schwachstelle | CVE | CVSS | Komponente | Methode |
|--------------|-----|------|-----------|--------|
| Shellshock RCE | CVE-2014-6271 | 9.8 | Apache mod\_cgi + ungepatchte Bash | Metasploit mit schädlichem User-Agent-Header |
| Standard-Anmeldedaten | — | — | pfSense webConfigurator | `admin / pfsense` unverändert nach Installation |
| Sudo-Fehlkonfiguration (www-data) | — | — | `/etc/sudoers` | NOPASSWD `hammer.sh` ausführbar als thor |
| Befehlseinschleusung in hammer.sh | — | — | Benutzerdefiniertes Bash-Skript | `eval`-Injection via `bash -i`-Payload |
| Sudo-Fehlkonfiguration (thor) | — | — | `/etc/sudoers` | NOPASSWD uneingeschränktes `service` als root |
---
## Verwendete Werkzeuge
| Werkzeug | Zweck |
|---------|-------|
| Nmap | Host-Erkennung, Port-Scanning, OS-Fingerprinting, NSE Shellshock-Verifikation |
| Metasploit Framework | Datenbankgestützte Enumeration, Ausnutzung, Meterpreter, Post-Exploitation |
| Nessus Essentials | Strukturierte Schwachstellenbewertung mit CGI- und Webanwendungs-Scanning |
| Hydra | Initialer pfSense-Brute-Force-Versuch erfolglos aufgrund CSRF-Schutz |
| CeWL | Erstellung einer benutzerdefinierten Wortliste durch Crawlen der pfSense-Login-Seite |
| Python 3 + BeautifulSoup | CSRF-bewusstes pfSense-Brute-Force-Skript |
| pymetasploit3 | Metasploit RPC API-Client für vollständige Angriffsketten-Automatisierung |
| John the Ripper | Offline-SHA-512crypt-Hash-Knacken |
| Hashcat | GPU-beschleunigte SHA-512crypt-Knackversuche |
| CrackStation | Online-Rainbow-Table-Nachschlagewerk |
| GTFOBins | Referenz für die sudo service Privilege-Escalation-Technik |
| curl | HTTP-Dienstverifikation gegen pfSense WAN |
---
## Empfehlungen
**Bash sofort patchen.** Die Shellshock-Schwachstelle besteht, weil Bash auf diesem Debian-10-System nie aktualisiert wurde. Das Ausführen von `apt-get update && apt-get upgrade bash` entfernt die Schwachstelle. Über das Patchen hinaus sollte, wenn CGI-Skripte betrieblich nicht erforderlich sind, das Verzeichnis `/cgi-bin/` in der Apache-Konfiguration vollständig deaktiviert werden, wodurch die Angriffsfläche unabhängig von der Bash-Version beseitigt wird.
**Sudo-Regeln prüfen und härten.** Zwei NOPASSWD-Sudo-Regeln bildeten die gesamte Privilegieneskalationskette. Keine der Regeln hat eine legitime Rechtfertigung. Die Datei `/etc/sudoers` sollte überprüft und beide Einträge entfernt werden. Das Prinzip der geringsten Privilegien sollte jede zukünftige Sudo-Konfiguration leiten; Konten sollten nur den spezifischen Zugriff haben, den sie wirklich benötigen, nicht mehr.
**Eval aus Shell-Skripten entfernen.** Das Skript `hammer.sh` übergab Benutzereingaben direkt an eine `eval`-Anweisung ohne Validierung oder Bereinigung. Dies ermöglichte die Befehlseinschleusung. Die Verwendung von `eval` sollte in Shell-Skripten, die Benutzereingaben akzeptieren, vollständig vermieden werden, da es fast immer eine Angriffsfläche darstellt. Eingaben sollten vor jeder Verarbeitung gegen eine strenge Positivliste validiert werden.
**Standard-Anmeldedaten von pfSense ändern und Zugriff einschränken.** Der WebConfigurator war auf der WAN-Schnittstelle unter Verwendung der unveränderten Standard-Anmeldedaten `admin / pfsense` exponiert. Standard-Anmeldedaten sollten unmittelbar nach der Installation geändert werden. Der WebConfigurator sollte niemals vom WAN aus erreichbar sein; der Zugriff sollte nur auf das LAN oder eine dedizierte Verwaltungsschnittstelle beschränkt werden.
**Zentralisiertes Logging implementieren.** In Phase 8 wurden alle lokalen Protokolle innerhalb von Minuten gelöscht, sodass keine Spur des Eindringens auf dem Zielsystem zurückblieb. Dies zeigte, dass das Ziel kein zentralisiertes Log-Management hatte. In einer Produktionsumgebung sollten Protokolle in Echtzeit an ein entferntes SIEM weitergeleitet werden. Dies stellt sicher, dass selbst wenn ein Angreifer Protokolle lokal löscht, die Beweise bereits außerhalb des Systems gesichert wurden und nicht manipuliert werden können.
---
## Repository-Struktur```
hacksudo-thor-pentest/
│
├── README.md
├── report.pdf ← Full penetration testing report
│
├── scripts/
│ ├── pfsense_brute.py ← CSRF-aware pfSense brute force script
│ └── thor_full_chain.py ← Metasploit RPC attack chain automation
│
└── screenshots/
├── network.PNG
│
├── Discovery/
│ └── pfsenselogin.png
│
└── exploit/
├── sheellockexploit.PNG
├── sudol.PNG
├── hammer.bash-i.PNG
├── privilage escaltiontoroot.PNG
├── proof.PNG
└── backdoor.PNG
Dieser Penetrationstest wurde ausschließlich in einer eigenständigen, isolierten virtuellen Laborumgebung durchgeführt, die in Oracle VirtualBox aufgebaut wurde. HackSudo Thor ist eine absichtlich angreifbare CTF-Maschine, die auf VulnHub zum Zweck der Sicherheitsausbildung und -praxis veröffentlicht wurde.
| Feld | Detail |
|---|
| Ziel | HackSudo Thor |
| Autor | Vishal Waghmare (@hacksudo) |
| Veröffentlichung | 3. August 2021 |
| Schwierigkeit | Einfach bis Mittel |
| Betriebssystem | Linux (Debian) |
| Format | VirtualBox OVA |
| DHCP | Aktiviert |
| Vorhergesagte Angriffsfläche | HTTP, SSH, wahrscheinlich falsch konfigurierte sudo-Berechtigungen |
| IP-Adresse | Schlüsseldienste | Betriebssystem | Identifiziert als |
|---|
| 10.0.4.3 | SSH 7.9p1, Apache 2.4.38, FTP | Linux (Debian) | HackSudo Thor |
| 10.0.4.4 | Apache 2.4.29, DVWA v1.10 | Linux (Ubuntu) | DVWA |
| 10.0.3.4 | Microsoft IIS 5.1 | Windows XP/2003 | WinXP Cyberlab |
| 10.0.3.5 | vsftpd 2.3.4, SSH, Apache 2.2.8 | Linux (Ubuntu) | Metasploitable 2 |
| Schweregrad | Fund | CVE | CVSS v3 |
|---|
| KRITISCH | Shellshock RCE | CVE-2014-6271 | 9.8 |
| KRITISCH | Shellshock Unvollständiger Fix | CVE-2014-6278 | 8.8 |
| MITTEL | SSH Terrapin Schwachstelle | CVE-2023-48795 | 5.9 |
| MITTEL | Durchsuchbare Webverzeichnisse | — | 5.3 |
| MITTEL | Clickjacking / Kein X-Frame-Options | CWE-693 | 4.3 |
| NIEDRIG | ICMP-Timestamp-Offenlegung | CVE-1999-0524 | 2.1 |