CVE Quick Search: Implementierung einer eigenen Schwachstellendatenbank

Nicht nur für die Durchführung von Penetrationstests ist es interessant zu wissen, welche Schwachstellen in einem Softwareprodukt bestehen. Auch aus der Perspektive eines IT Teams kann es nützlich sein, schnell Informationen zu einer eingesetzten Produktversion zu erhalten. Bisher gab es für diese Form von Anfragen verschiedene Datenbanken wie z.B. https://nvd.nist.gov/vuln/search, https://cvedetails.com oder https://snyk.io/vuln

Über die letzten Jahre konnten wir jedoch folgende Probleme mit diesen Datenbanken feststellen:

  • Viele Datenbanken indizieren Schwachstellen nur für bestimmte Produktgruppen (z.B. Snyk: Web Technologien)
  • Viele Datenbanken führen eine Stichwortsuche durch. Eine Suche nach spezifischen Produktversionen ist somit ungenau
  • Viele Datenbanken sind nicht aktuell oder weisen Fehler auf

1Abbildung: Fehlerhafte Schwachstelleninfos für Windows 10

3Abbildung: Stichwortsuche zeigt anderes Produkt als das eigentlich gesuchte

Aus diesem Grund haben wir uns entschieden, eine eigene Lösung zu implementieren. Diese Lösung hat die folgenden Vorteile:

  • Produkte und Versionsnummern werden anhand eindeutiger Identifikatoren gesucht. Somit können die Suchergebnisse genauer beschränkt werden.
  • Unser System importiert täglich die Schwachstellendatenbank des National Institute of Standards and Technology (NIST). Schwachstellen sind somit tagesaktuell und haben einen verifizierten CVE Eintrag.
  • Das System basiert auf dem Elastic Stack https://www.elastic.co/de/elastic-stack/ um Daten performant in Echtzeit zu durchsuchen und zu visualisieren.

Technischer Einblick: NIST NVD & Elastic Stack

Wenn Schwachstellen in Produkten veröffentlicht werden, so registrieren Sicherheitsforscher gewöhnlich einen CVE Eintrag pro gefundener Schwachstelle. Diese CVE Einträge erhalten eine einzigartige ID, genaue Informationen, welche Produkte betroffen sind sowie eine Beschreibung der Schwachstelle.

CVEs lassen sich auf https://cve.mitre.org registrieren und werden von der National Vulnerability Database (NVD) in Echtzeit indiziert. (https://cve.mitre.org/about/cve_and_nvd_relationship.html) Hierbeit stellt das NIST öffentliche und frei nutzbare Dateisammlungen zur Verfügung, die alle registierten Schwachstellen enthalten. Wir nutzen dieses frei vefügbare Angebot als Basis für unsere eigene Datenbank.

Der vollständige technische Ablauf für den Import dieser Daten und die anschließende Bereitstellung als Datenbank werden im Folgenden geschildert:

4Abbildung: Überblick der technischen Komponenten unserer Schwachstellendatenbank

1. Täglicher Import von Schwachstellendateien der NIST NVD

Die Dateisammlungen sind in Jahreszahlen unterteilt und werden von NIST täglich aktualisiert. Wir laden jede Nacht die neuesten Dateien auf unseren Dateiserver herunter.

2. Vor-Verarbeitung der Schwachstellendateien

Anschließend werden die Dateien nach dem Download vorverarbeitet, um Sie besser lesbar für den Elastic Stack Parser zu machen. Ein Vorgang der hierbei erfolgt ist eine Expandierung von allen JSON Dateien: Die Dateien enthalten die CVE Einträge als JSON Objekte, jedoch sind diese oft geschachtelt, was es dem Parser schwer macht einzelne Objekte zu erkennen. Wir lesen das JSON ein und schreiben alle Objektseparatoren sowie Parameter in separate Zeilen. Somit kann mittels eines Regex ( ‘^{‘ ) genau erfasst werden, wann ein neues Objekt beginnt.

5
6

Des weiteren bereinigen wir die Dateien von allen nicht benötigten Metadaten (z.B. Autor oder Versionsnummern der Datei), wodurch nur noch die CVE Einträge als gereihte JSON Objekte übrig bleiben.

3. Einlesen der vor-verarbeiteten Schwachstellendateien mittels Logstash

Nachdem die Daten in das bereinigte Format überführt wurden, kann unser Logstash Parser mittels des Multiline Codecs (https://www.elastic.co/guide/en/logstash/current/plugins-codecs-multiline.html) die einzelnen Zeilen einlesen und jedes Mal wenn ein vollständiges JSON Objekt erkannt wurde, schickt Logstash dieses CVE Objekt an unsere Elasticsearch Instanz weiter.

 

Der CVE Grepper – Datenformat und Suche von Schwachstellen

Nachdem nun alle CVE Einträge in unsere Elasticsearch Datenbank gespeist wurden, müssen wir verstehen, welches Format diese Einträge besitzen und wie wir nach spezifischen Produkten oder Produktschwachstellen suchen können. Unser finales Ergebnis ist in folgendem Screenshot sichtbar: Mittels eindeutigem Identifikator können wir alle Schwachstellen für die gesuchte Produktversion zurückgeben.

2021 09 17 09 56 10 ClipboardAbbildung: Vorschau unseres Schwachstellen-Suche Frontends

1. Datenformat von Produktversionen

Wenn wir das generelle Datenformat von Produktversionen betrachten, so ist dieses in einer eigenen NIST Spezifikation definiert. Absatz 5.3.3 der Spezifikation gibt einen kurzen Überblick (https://nvlpubs.nist.gov/nistpubs/Legacy/IR/nistir7695.pdf):

8

cpe:2.3:part:vendor:product_name:version:update:edition:sw_edition:target_sw:target_hw:language:other

  • part: ist entweder ‘a’ (application), ‘o’ (operating system) oder ‘h’ (hardware)
  • vendor: gibt den Hersteller des Produktes eindeutig an
  • product_name: gibt den Namen des Produktes eindeutig an
  • version: gibt die Versionsnummer des Produktes an
  • edition: veraltet
  • sw_edition: Versionsangabe für Marktbeschränkungen
  • target_sw: Softwareumgebung in der das Produkt verwendet wird
  • target_hw: Hardwareumgebung in der das Produkt verwendet wird
  • language: Unterstützte Sprache
  • other: anderweitige Beschreibungen

Der Doppelpunkt wird als Separator verwendet. Asterisk (*) als Wildcard-Symbol.

In unserem Screenshot: “cpe:2.3:o:juniper:junos:17.4r3:*:*:*:*:*:*:*” können wir das Betriebssystem JunOS von Hersteller Juniper in der Version 17.4r3 als verwundbar für eine Schwachstelle bestimmen.

Beim Betrachten der JSON Datei ist ersichtlich, dass es zwei Formate gibt, in denen Versionsnummern für eine Schwachstelle angegeben werden.

  • Format 1: Mittels der Attribute “versionStartIncluding/versionStartExcluding” und “versionEndIncluding/versionEndExcluding” wird eine Spanne an verwundbaren Versionen definiert.
  • Format 2: Eine einzelne verwundbare Softwareversion wird im Attribut “cpe23Uri” angegeben.

2. Durchsuchen der Datenbank

Um die Datenbank nach bestimmten Produkten zu durchsuchen muss zum einen eine einfache Produktsuche möglich sein, die anschließend den korrekten Produkspezifikator wählt, um in beiden beschriebenen Versionsformaten nach Treffern zu suchen. Wir haben uns hierbei für eine JavaScript Auto-Complete Variante entschieden, die Produkte und ihre CPE Werte dynamisch anzeigt:

9Abbildung: Autocomplete-Funktion des Such-Frontends

Nachdem eine Auswahl getroffen wurde, können Schwachstellen für den cpe Produktidentifikator angefragt werden.

 

Ausblick: Kibana – Schwachstellen und Trends visualisieren

Ein großer Vorteil den die Speicherung von Schwachstellendaten in einer Elasticsearch Datenbank hat, ist die unmittelbare Anbindung an Kibana. Kibana stellt dabei eigenständig Anfragen an Elasticsearch und erzeugt hieraus Visualisierungen. Im Folgenden haben wir ein paar Darstellungsbeispiele unserer Schwachstellendaten ausgesucht:

10Abbildung: Anzahl der registrierter Schwachstellen pro Jahr

11Abbildung: Anteile der jeweiligen Risikobewertungsgruppen pro Jahr

Wir sehen großes Potential darin, diese Daten in Echtzeit auf unsere Homepage einzubinden und somit tagesaktuelle Statistiken zu Trends und Schwachstellen zur Verfügung zu stellen.

 

Ausblick – Threat Intelligence und Automatisierung

Ein weiterer Punkt auf unserer CVE Datenbank Roadmap ist die Programmierung eines Systems, dass Kunden automatisiert benachrichtigen kann, sobald neue Schwachstellen für einen CPE Identifikator gefunden wurden. Dadurch dass Elasticsearch eine sehr umfangreiche REST API zur Verfügung stellt, können wir auch diese Aufgabe mit dem bereits implementierten ELK Stack umsetzen.

Aktuell arbeiten wir an der Umsetzung der Kibana Live Statistiken auf der Homepage. Sobald dieser Meilenstein abgeschlossen ist, beginnen wir mit dem Thema “Threat Intelligence”. Wie Sie sehen können, beschäftigen wir uns bei der Pentest Factory GmbH nicht nur mit der Thematik Penetrationstests, sondern haben großes Interesse daran, interessante Forschungsbereiche der IT Sicherheit zu erschließen und unser Verständnis zu erweitern.