Zurück zu den Artikeln Ausgabe #2  / 

Explain This CVE

Ein CVE-Eintrag ist für Spezialisten geschrieben. Ich habe einen einseitigen Prüfer gebaut, der jedes CVE in klarer Sprache erklärt, und versucht, ihn schwer missbrauchbar zu machen.

CRITICAL vs
Das ProblemWer als Führungskraft entscheiden muss, ob heute alles stehen und liegen bleibt, bekommt einen Score, einen Vektor-String und 100 Links.
NVD CISA KEV EPSS
Die QuellenDrei öffentliche Datenbanken, parallel abgefragt und zu einer kleinen, festen Antwort verdichtet.
als feindlich behandelt.
Die RegelAlles aus den Datenbanken und alles, was die KI sagt, wird als feindlicher Text behandelt.

Was es tut

Du gibst eine CVE-ID ein, etwa CVE-2021-44228 (Log4Shell), und bekommst eine Seite mit sieben Kapiteln, immer in derselben Reihenfolge:

  1. Die CVE-ID, ihr Titel und das Veröffentlichungsdatum.
  2. Schweregrad: der CVSS-Score mit Farbabzeichen und die Stufe als Wort.
  3. Ob es ausgenutzt wird: die Known-Exploited-Vulnerabilities-Liste (KEV) der CISA und die EPSS-Wahrscheinlichkeit.
  4. Eine Zusammenfassung in klarer Sprache.
  5. Welche Produkte und Versionen betroffen sind.
  6. Behebung und Abmilderung: was die CISA verlangt, die ersten nicht betroffenen Versionen, Patches und Hinweise.
  7. Quellenverweise.

Es gibt zwei Ansichten derselben Daten. Die Manager-Ansicht beantwortet „Müssen wir heute handeln?“. Die Analyst-Ansicht behält die Details. Jede Übersicht endet mit „Always verify with the official vendor advisory“ (immer mit dem offiziellen Herstellerhinweis abgleichen).

Wie es funktioniert

Es ist eine statische Seite und eine Serverless-Funktion, ohne Konten, ohne Datenbank und ohne Abhängigkeiten. Bei jeder Anfrage führt die Funktion diese Schritte der Reihe nach aus:

  1. Methode prüfen, dann die Anfragerate des Clients begrenzen.
  2. Die ID validieren. Sie muss ^CVE-\d{4}-\d{4,10}$ entsprechen und der einzige Query-Parameter sein.
  3. Im Cache nachsehen. Läuft schon eine andere Anfrage für dieselbe ID, auf sie warten, statt erneut zu fragen.
  4. NVD, den CISA-KEV-Feed und EPSS parallel abfragen, jeweils mit eigenem Timeout.
  5. Die nicht vertrauenswürdigen Daten in eine kleine, feste Form normalisieren.
  6. Die Zusammenfassung schreiben: mit einem KI-Modell, wenn ein Schlüssel gesetzt ist, sonst mit festen Regeln.

NVD ist Pflicht. Fallen CISA, EPSS oder das KI-Modell aus, funktioniert die Seite trotzdem und sagt, was fehlt. „Die CISA-Liste konnte nicht geprüft werden“ erscheint als unbekannt, nie als „nicht ausgenutzt“, denn eine fehlgeschlagene Abfrage, die wie eine gute Nachricht aussieht, ist das Schlimmste, was ein Sicherheitswerkzeug tun kann. Aus demselben Grund gilt ein KEV-Feed mit weniger als 100 Einträgen als defekt.

Die Sicherheitsentscheidungen

Die Daten stammen aus öffentlichen Datenbanken, aber auf einen Teil kann jeder Einfluss nehmen, und ein KI-Modell liest sie. Deshalb wird alles als feindlich behandelt.

BedrohungWas ich getan habe
Durchsickern von API-SchlüsselnSchlüssel werden in einer einzigen Serverdatei aus Umgebungsvariablen gelesen. Der Browser-Code erwähnt sie nie, und ein Test durchsucht jede eingecheckte Datei nach schlüsselähnlichen Zeichenfolgen.
Schlechte Eingaben und SSRFEin strenges Muster nur mit ASCII für die ID. Die drei API-Hosts sind Konstanten, die ID geht über URL.searchParams hinein, und Weiterleitungen werden abgelehnt.
XSSDer Server bereinigt Text und begrenzt Längen. Der Browser schreibt nur mit textContent. Eine strenge Content Security Policy mit Trusted Types ist die letzte Verteidigungslinie.
Prompt InjectionDas Modell bekommt nur öffentliche Fakten, keine Werkzeuge und keine Geheimnisse. Seine Antwort muss ein JSON-Objekt mit drei Feldern sein und wird abgelehnt, wenn sie einen Link, ein Tag oder eine Versionsnummer enthält, die nicht in den Fakten steht.
Missbrauch und Kontingent20 Anfragen pro Minute und Client, 6 Abfragen ohne Cache pro Minute, ein gemeinsames Budget knapp unter dem eigenen Limit von NVD und eine Stunde Cache.
Feindliche Upstream-DatenJedes Feld wird auf seinen Typ geprüft, Schleifen und Größen sind begrenzt, und ein Eintrag zu einem anderen CVE als dem angefragten wird abgelehnt.

Es gibt mehr als 140 Tests auf gespeicherten echten API-Antworten, sie laufen also offline. Am nützlichsten ist eine XSS-Übung, die den echten Browser-Code gegen eine Antwort voller <img onerror>- und <script>-Payloads laufen lässt und bei jedem unerwarteten Element, Attribut oder Link fehlschlägt.

Was es noch nicht kann

  • Cache und Ratenbegrenzung leben im Speicher einer einzelnen Funktionsinstanz und arbeiten daher nach bestem Bemühen. Ein gemeinsamer Speicher würde das beheben.
  • Das Kontingent von NVD teilen sich alle Besucher. Ist es aufgebraucht, zeigt die Seite die Meldung „ausgelastet“.
  • Ein überredetes KI-Modell kann immer noch einen irreführenden Satz ohne Link und ohne Versionsnummer schreiben. Die Prüfungen erkennen keine Meinung, deshalb werden Schweregrad, KEV und EPSS getrennt von der Zusammenfassung angezeigt.
  • KEV führt nur bestätigte Ausnutzung auf, und EPSS ist eine Wahrscheinlichkeit, kein Urteil.
  • Ich habe einen Chromium-Browser getestet, in beiden Themes, in Desktop- und Smartphone-Breite. Safari und Firefox habe ich nicht getestet.

Ich habe es mit KI-Unterstützung gebaut. Funktionen und Sicherheitsanforderungen habe ich entworfen, den Code habe ich geprüft und getestet.

Ausprobieren

Der Prüfer läuft unter explain-this-cve.vercel.app, der Code und ein Lernleitfaden liegen auf GitHub. Probiere zuerst Log4Shell.