Ein Nuclei-Template für eine CVE schreiben: vom Advisory zum Template, das auslöst (ohne Fehlalarme)

Eine kritische CVE wird an einem Freitagabend veröffentlicht. Das Advisory beschreibt den Fehler, die betroffene Version, den verwundbaren Pfad. Die Frage lautet nicht mehr „bin ich betroffen?", sondern „wie viele meiner Assets sind es, genau jetzt?". Nuclei ist das Standardwerkzeug, um das im großen Maßstab zu beantworten: eine schnelle Engine, lesbare YAML-Templates, versionierbar wie Code. Der Haken: wenn die CVE erscheint, existiert das offizielle Template noch nicht, es kommt in einigen Tagen, manchmal Wochen. Diese Verzögerung ist Ihr Expositionsfenster.

Das Template selbst zu schreiben schließt diese Lücke. Aber ein schlecht geschriebenes Template ist schlimmer als keins: es verpasst die verwundbare Version (falsch-negativ (Sie halten sich für sicher) oder es schlägt bei einer bereits behobenen Version an (Fehlalarm) Sie ertränken das Team im Rauschen). Dieser Artikel zeigt, wie man eines schreibt, das präzise auslöst, und vor allem, wie man es beweist.

Warum nicht einfach auf das offizielle Template warten

Drei Gründe, es selbst zu können:

• Der Versatz. Zwischen der Veröffentlichung einer CVE und einem öffentlichen Template liegt eine variable Verzögerung. Bei einem aktiv ausgenutzten Fehler (ein Eintrag im CISA-KEV-Katalog) ist diese Verzögerung genau das Fenster, in dem auch die Angreifer scannen.
• Ihre eigenen Anwendungen. Kein Community-Projekt deckt Ihr internes ERP, Ihr Maßportal oder jene Nischen-Appliance ab. Die Erkennung auf diesem Perimeter schreibt niemand für Sie.
• Die Priorisierung. Sie können kein Template für die 40 000 CVEs des Jahres schreiben. Es schnell für die Handvoll zu können, die zählt (die ausgenutzten, exponierten, auf Ihren kritischen Assets) ist eine Detection-Engineering-Fähigkeit, kein Luxus.

Der Aufbau eines Nuclei-Templates

Ein Template ist eine YAML-Datei in zwei Teilen: die Metadaten (info) und die Logik (die Anfrage plus die matchers). Hier das Gerüst:

id: cve-2024-0000-config-disclosure
 
info:
  name: "ACME Portal < 4.2 - Nicht authentifizierte Konfigurationsoffenlegung"
  author: ihr-team
  severity: high
  description: |
    ACME Portal vor 4.2 stellt /api/v1/config ohne Authentifizierung bereit
    und gibt Datenbank-Zugangsdaten und API-Schlüssel preis.
  classification:
    cve-id: CVE-2024-0000
    cvss-score: 8.6
  tags: cve,cve2024,acme,exposure
 
http:
  - method: GET
    path:
      - "{{BaseURL}}/api/v1/config"
    matchers-condition: and
    matchers:
      - type: status
        status:
          - 200
      - type: word
        part: body
        words:
          - '"db_password"'
          - '"api_key"'
        condition: and

(Das Beispiel ist illustrativ: Das Prinzip zählt mehr als die gewählte CVE.) Jeder Block hat eine Rolle. Die id ist eindeutig und sprechend. Der info-Block trägt die Schwere und die classification (die cve-id, den CVSS-Score), das ist keine Dekoration: Es erlaubt anschließend das Triagieren, Korrelieren und Priorisieren. Der http-Abschnitt beschreibt, was gesendet wird und was die Verwundbarkeit beweist.

Von der Tatsache ausgehen, nicht vom Proof-of-Concept

Das ist der wichtigste und am häufigsten übersprungene Punkt. Auf GitHub kursiert fast immer ein Exploit-PoC vor dem Template. Die Versuchung ist, ihn zu kopieren. Tun Sie es nicht, aus zwei Gründen.

Erstens die rechtliche Sorgfalt: ein ohne ausdrückliche Lizenz veröffentlichter PoC ist standardmäßig „alle Rechte vorbehalten". Ihn in ein Template zu kopieren, das Sie teilen oder verkaufen, ist ein Problem. Die Tatsache hingegen, die das Advisory beschreibt („Version X stellt Pfad Y bereit, der Zeichenkette Z zurückgibt") gehört niemandem. Eine Erkennungssignatur ist Ihr Werk, so wie eine Antiviren-Signatur nicht die Rechte der Malware erbt, die sie erkennt.

Zweitens die Qualität: ein PoC will ausnutzen, ein Template will gefahrlos feststellen. Sie wollen keine Webshell ablegen, um eine RCE zu beweisen; Sie wollen das leichteste, zuverlässigste Zeichen, dass der Fehler vorhanden ist. Das Advisory gibt Ihnen genau dieses Zeichen: den Pfad, den Versionsmarker, die Antwortsignatur. Das ist Ihr Rohmaterial.

Die Matcher bauen, von grob zu präzise

Ein Matcher, der zu leicht „verwundbar" zurückgibt, ist die Falle Nummer eins. Betrachten wir drei Stufen:

Stufe 1: der Statuscode allein. status: 200 auf /api/v1/config. Unzureichend: eine gepatchte Version kann 200 mit einer leeren Seite oder einer Fehlermeldung zurückgeben. Ein Status beweist nicht die Verwundbarkeit, er beweist, dass der Pfad existiert.

Stufe 2: der Status plus ein Schlüsselwort. Man ergänzt das Vorhandensein von "db_password" im Body. Deutlich besser: Sie lösen nur aus, wenn die Antwort die geleakten Daten tatsächlich enthält. Das matchers-condition: and verlangt, dass beide Bedingungen wahr sind.

Stufe 3: die Versionsunterscheidung. Der subtile Fall. Gibt Version 4.2 (behoben) den Schlüssel noch zurück, aber leer, erzeugt Stufe 2 einen Fehlalarm. Dann braucht es einen regex-Matcher, der einen nicht-leeren Wert erfasst, oder das Lesen des Versionsmarkers in einem Header. Hier entscheidet sich der Unterschied zwischen einem Template, das Lärm macht, und einem, dem Ihr Team vertraut.

Für einen blinden Fehler (keine direkt beobachtbare Antwort, eine Out-of-Band-Injektion, ein SSRF) bietet Nuclei interactsh: das Template löst einen Netzwerk-Rückruf an einen Kontrollserver aus und bestätigt die Verwundbarkeit über diesen Rückruf, ohne das Ziel je auszunutzen.

Validieren genügt nicht: man muss beweisen

Nuclei bringt eine eingebaute Prüfung mit:

nuclei -validate -t cve-2024-0000-config-disclosure.yaml

Achtung vor dem Missverständnis: -validate prüft die Syntax, nicht die Wirksamkeit. Ein völlig gültiges Template kann nichts erkennen oder alles. Die Syntaxvalidierung ist notwendig, nie ausreichend.

Der echte Beweis ist empirisch und läuft auf zwei Tests hinaus:

1. Löst das Template bei einem verwundbaren Ziel aus? Stellen Sie die Anwendung in ihrer verwundbaren Version bereit (ein Docker-Container der richtigen Version tut es gut) und lassen Sie das Template darauf laufen. Löst es nicht aus, ist es nutzlos.
2. Bleibt es bei einem gepatchten Ziel stumm? Stellen Sie die behobene Version bereit und lassen Sie es erneut laufen. Löst es noch aus, haben Sie einen Fehlalarm, das schlechteste Ergebnis, weil es das Vertrauen in alle Ihre Warnungen untergräbt.

Ein Template, das beide Tests bestanden hat, ist unendlich viel mehr wert als ein bloß „gültiges". Das ist der Unterschied zwischen „kompiliert" und „funktioniert, bewiesen".

Die Fallen, die teuer werden

• Der zu generische Matcher. Das Auslösen auf einem Versions-Banner („Server: ACME/4.1") ist fragil: Banner werden maskiert, entfernt oder bleiben nach einem zurückportierten Fix bestehen. Bevorzugen Sie stets das beobachtbare verwundbare Verhalten gegenüber der Selbstauskunft der Software.
• Die vergessene gepatchte Version. Der „gepatcht"-Test ist nicht optional. Die Hälfte aller Fehlalarme kommt daher.
• Das Duplikat. Bevor Sie Ihr Template behalten, prüfen Sie, ob nicht bereits ein Pendant stromaufwärts existiert. Das Werkzeug cent aggregiert und dedupliziert Template-Sammlungen, nützlich, um nicht doppelt zu pflegen, was die Community schon abdeckt.
• Nachlässige Klassifikationen. Füllen Sie cve-id, cvss-score, severity aus. Das macht Ihre Ergebnisse nutzbar, nach Schwere sortierbar, mit Ihren anderen Quellen korrelierbar.

Priorisieren: nicht alle CVEs sind gleich

Ein Template zu schreiben hat einen Preis. Ihn in die richtigen Fehler zu investieren ändert alles. Zwei kostenlose, öffentliche Quellen lenken den Aufwand:

• CISA KEV (Known Exploited Vulnerabilities): der Katalog der aktiv ausgenutzten Fehler. Eine CVE auf dieser Liste ist ein Notfall, keine Hypothese.
• EPSS (Exploit Prediction Scoring System): eine 30-Tage-Ausnutzungswahrscheinlichkeit. Nützlich, um zwischen zwei Fehlern zu entscheiden, bevor einer ausgenutzt wird.

„Diese CVE steht in KEV" mit „sie trifft ein exponiertes Asset von mir" zu kreuzen ergibt eine kurze, umsetzbare Liste: das sind die Templates, die zuerst zu schreiben sind.

Zusammenfassung

Ein gutes Nuclei-Template für eine CVE zu schreiben ist eine Methode, keine Improvisation: von der Tatsache im Advisory ausgehen (nicht vom PoC), den präzisestmöglichen Matcher bauen (nicht nur einen Status) und empirisch beweisen, dass es bei der verwundbaren Version auslöst und bei der gepatchten stumm bleibt. Der Rest (Syntaxvalidierung, Klassifikationen, Deduplizierung) ist Hygiene.

Genau diese Disziplin wenden wir in großem Maßstab im Nuclei-Feed von ThreatClaw an: jedes Template wird auf der echten Engine validiert, nach KEV und EPSS priorisiert und als schnelle Reaktion auf die Fehler ausgeliefert, die zählen. Wenn eine kritische CVE an einem Freitagabend erscheint, ist das Expositionsfenster bereits abgedeckt, Sie müssen es nicht selbst unter Druck schreiben.