Blog ·
Ein Treffer, der sich weigert, sicher zu sein
Vier Fakten aus vier Quellen, getrennt gehalten. Warum ein KEV-Eintrag nie eine Schwere anhebt und warum nur ein begrenzter Versionsbereich wirklich zählt.
Von Provibr
Ein Bannerscanner liest SSH-2.0-OpenSSH_8.9p1 von einem Port und schreibt ein Produkt und eine Version auf. Ein Schwachstellenfeed sagt, dass ein Bereich von Versionen dieses Produkts ein bekanntes Problem hat. Diese beiden zusammenzulegen ist eine Zeile Code und einer der einfachsten Wege, einen Sicherheitsbildschirm zu bauen, dem binnen eines Monats niemand mehr traut.
Der Grund ist, dass die beiden Sätze nicht dieselbe Art von Aussage sind. Der eine ist eine Messung an einem Dienst, der Sie anlügen kann. Der andere ist die Behauptung eines Dritten über einen Versionsbereich, den er womöglich geschrieben hat, bevor es die Korrektur gab. Ein Bildschirm, der beides als eine Zahl darstellt, hat genau das weggeworfen, womit eine Kundin entscheiden könnte, was zu tun ist.
Vier Fakten aus vier Quellen
In dem Satz diese Maschine hat CVE-1234 stecken vier getrennte Behauptungen.
- Erreichbar ist gemessen. Zu einem bestimmten Zeitpunkt kam eine TCP-Verbindung zustande.
- Die Version ist abgeleitet. Wir haben ein Merkmal aus einer Begrüßung geschnitten, der Dienst kann so eingestellt sein, dass er beliebiges sagt, und eine Distribution kann eine Korrektur zurückportiert haben, ohne die Nummer zu ändern.
- Die Meldung gehört jemand anderem. NVD sagt, dass ein Versionsbereich eines Produkts betroffen ist.
- Aktiv ausgenutzt ist wieder eine dritte Partei. CISA sagt, dass dieses CVE in freier Wildbahn verwendet wird.
Es bleiben vier Spalten. Sie zu einer Punktzahl zu verrechnen ist genau die bedeutungslose Zusammensetzung, die die Spezifikation dieser Funktion verbietet, und einen Eintrag im Katalog aktiv ausgenutzter Schwachstellen als Anhebung der Schwere zu behandeln ist derselbe Fehler im Kleinen.
Ein KEV-Eintrag hebt deshalb nie eine Schwere an. Die Schwere kommt aus dem CVSS-Basiswert und aus sonst nichts, die Sicherheit bleibt niedrig, weil der Beweis ein Banner ist, und Ausnutzung ist eine eigene Spalte mit drei Zuständen: ja, nein, und nicht anwendbar für Befunde, die gar nicht auf einer Meldung beruhen. An den Prüfdaten gemessen: eine Exim-Meldung mit CVSS 9,8 ist kritisch und trägt eine KEV-Markierung; eine OpenSSH-Meldung mit 8,1 ist hoch und trägt keine. Die 9,8 ist kritisch wegen ihres Wertes und nicht wegen der Markierung.
Der Katalog kann bauartbedingt auch keinen Treffer aus eigener Kraft liefern. Er trägt eine CVE-Kennung, einen Hersteller, einen Produktnamen und ein Datum, und überhaupt keine Versionsbereiche. Apache HTTP Server gegen ein Banner zu legen wäre Raten. Er setzt immer nur eine Markierung auf eine Meldung, die NVD bereits an einen Versionsbereich gebunden hat.
Die Feeds sind Plattformtabellen
Beide Feeds liegen in Tabellen ohne Organisationsspalte. Ein CVE gehört niemandem: es ist kein personenbezogenes Datum, es ist nicht die Datenlage einer Kundin, und es ist dieselbe Zeile für jedes Konto auf der Plattform. Es steckt daher nicht in der Bereinigung, die beim Schließen einer Organisation läuft, und nicht in einer Datenauskunft. Die Verbindung zwischen einem Befund und einer Meldung gehört sehr wohl der Kundin, und die steckt in beidem.
Der Abholer hat eine Erlaubnisliste auf dem Host und nicht auf der Adresse, und die Adressen selbst stehen im Code. Ein Arbeiter, der eine Adresse aus der Umgebung oder aus der Datenbank liest, ist ein Werkzeug für gefälschte Anfragen mit einem Zeitplan darum herum: wer diesen Wert setzen kann, lässt unser Tor eine Anfrage aus unserem Netz mit unseren ausgehenden Adressen stellen. Der Host jeder endgültigen Adresse wird ebenfalls geprüft, damit auch eine Umleitung auf einen anderen Host abgelehnt statt verfolgt wird.
Die Wahrheitstabelle
Bei einem passenden Produktnamen und einer CPE-Regel aus der Meldung gibt es genau drei mögliche Antworten, und die meisten interessanten Zeilen liefern die mittlere.
| Beobachtete Version | Die CPE-Regel | Ergebnis |
|---|---|---|
| beliebig | Produktname weicht ab | nichts |
| nicht lesbar | beliebig | möglicher Treffer, ungeprüft |
| lesbar | genaue Version, gleich, Update passt | Meldungstreffer |
| lesbar | genaue Version, gleich, Update weicht ab | möglicher Treffer, ungeprüft |
| lesbar | genaue Version, ungleich | nichts |
| lesbar | Bereich mit Obergrenze, innerhalb | Meldungstreffer |
| lesbar | Bereich mit Obergrenze, außerhalb | nichts |
| lesbar | nur Untergrenze, darüber | möglicher Treffer, ungeprüft |
| lesbar | überhaupt keine Grenzen | möglicher Treffer, ungeprüft |
Nur CPE-Einträge mit dem Teil a für Anwendung zählen. Ein o für Betriebssystem oder ein h für Hardware würde Ubuntu 22.04 an ein SSH-Banner hängen, und das ist genau die Art Treffer, die überzeugend aussieht und nichts bedeutet: wir haben den Dienst gesehen und nicht das System darunter.
Die Zeile, über die sich streiten lässt, ist nur eine Untergrenze. Eine Regel, die alles ab 8.0 nennt, ohne Obergrenze, schließt Versionen ein, die nach der Meldung erschienen sind und das Problem längst behoben haben. NVD schreibt Bereiche so, wenn die Korrektur noch nicht veröffentlicht war, und bessert sie nachträglich nicht immer nach. So eine Regel auf eine Maschine zu kleben würde einen gepatchten Server als verwundbar melden, und nach zwei solchen Meldungen lernt eine Kundin, den ganzen Bildschirm zu ignorieren. Ungeprüft ist die ehrliche Beschriftung, und ungeprüft ist keine kleinere Ausgabe von bestätigt. Es ist eine andere Behauptung.
Trägt eine Meldung dutzende CPE-Regeln, eine je betroffener Freigabe, gewinnt das stärkste Ergebnis. Passt eine davon genau, ist das die Antwort, auch wenn zehn vage daneben stehen.
Eine Neubewertung schreibt eine neue Fassung und rührt keinen Beweis an
Feeds ändern sich. NVD korrigiert einen Wert, ein Bereich wird enger, ein CVE, das vorige Woche passte, passt nicht mehr. Der Durchlauf, der offene Befunde gegen die aktuellen Feeds neu bewertet, hat eine harte Regel: er schreibt und ändert nie ein Vorkommnis.
Ein Vorkommnis ist die Antwort auf war es um 03:14 da. Daran ändert eine Feedaktualisierung nichts. Was sich ändert, ist die Schlussfolgerung darüber, und die bekommt eine neue Zeile in der Bewertungstabelle mit einer eigenen Fassungskennung, die beide Feedstände benennt. Gemessen: nachdem eine Meldung von CVSS 9,8 auf 7,5 verschoben wurde, kamen die vorhandenen Vorkommniszeilen Byte für Byte identisch zurück.
Ein verschwundener Treffer schließt den Befund als closed_unverified und nie als resolved_verified. Letzteres ist eine Aussage über eine Messung, und gemessen wurde nicht. Geändert hat sich unsere eigene Ableitung. Der Name ist der ganze Grund, warum dieser Zustand existiert.
Es wird auch nichts geschrieben, wenn sich nichts geändert hat. Der Stand wird zuerst mit dem vorigen Urteil verglichen, denn ein Durchlauf, der bei jedem Lauf eine Zeile ablegt, hinterlässt binnen eines Monats hundertzwanzig gleiche Bewertungen unter jedem Befund, und dann ist die Zeitleiste unlesbar.
Kein Durchlauf ohne einen erfolgreichen Feed
Die letzte Sperre kostete den wenigsten Code und verhindert das schlimmste Ergebnis.
Ist noch nie ein Feed erfolgreich gewesen, dann ist die aktuelle Meldungsfassung leer, und der Durchlauf kehrt sofort zurück, ohne irgendetwas anzusehen. Ohne diese Prüfung liefe er, stellte fest, dass die Kandidatenabfrage nichts liefert, und schlösse jeden meldungsbasierten Befund bei jeder Kundschaft als nicht mehr passend. Eine ganze Flotte würde grün, gestützt auf einen Feed, der kaputt ist.
Ein misslungener Abruf lässt zudem den vorigen Zwischenspeicher stehen, mitsamt seinem eigenen Erfolgszeitpunkt, sodass die beiden Fragen wann haben wir es zuletzt versucht und wann hat es zuletzt geklappt zwei getrennte Spalten sind statt einer hoffnungsvollen.
Was das kostet und was es einbringt
Der Preis ist, dass der Bildschirm viele Zeilen möglicher Treffer, ungeprüft zeigt, und die sind weniger befriedigend als eine Zahl. Wer verwaltet, muss sich eine davon ansehen und entscheiden, ob die eingesetzte Version wirklich betroffen ist.
Was es einbringt, ist, dass die als bestätigt markierten Zeilen es wert sind, dass man handelt, und dass jede Zeile in die vier Fakten zerlegt werden kann, aus denen sie gebaut wurde: was gemessen wurde, was abgeleitet wurde, was jemand anderes behauptet hat und was schlicht unbekannt ist. Ein Befund, der nicht erklären kann, woher jeder seiner Teile stammt, ist ein Befund, den jemand eines Tages zu überspringen lernt.
Aus der Sicherheitsarbeit von Provibr. Warum ein Expositionsscan, der ein Banner liest, überhaupt keine Nutzlast sendet, steht in ein Scanner, der null Bytes sendet, und warum ein Vorfall nie durch Stille geschlossen wird, steht in ein Vorfall, der nie auf Stille schließt.