Der Umgang mit Schwachstellen in IT-Systemen und Anwendungen ist wichtiger denn je. Täglich ist in den Medien zu lesen, dass neue Schwachstellen entdeckt, veröffentlicht und ausgenutzt werden. Wir haben nun unsere Schwachstellen Datenbank für die Öffentlichkeit freigeschaltet und bieten allen Nutzern die Möglichkeit nach entsprechenden Einträgen in ihrer Software zu suchen.
Lies weiter
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:
Abbildung: Fehlerhafte Schwachstelleninfos für Windows 10
Abbildung: 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:
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:
Abbildung: Überblick der technischen Komponenten unserer Schwachstellendatenbank
Die Dateisammlungen sind in Jahreszahlen unterteilt und werden von NIST täglich aktualisiert. Wir laden jede Nacht die neuesten Dateien auf unseren Dateiserver herunter.
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.
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.
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.
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.
Abbildung: Vorschau unseres Schwachstellen-Suche Frontends
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):
cpe:2.3:part:vendor:product_name:version:update:edition:sw_edition:target_sw:target_hw:language:other
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.
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:
Abbildung: Autocomplete-Funktion des Such-Frontends
Nachdem eine Auswahl getroffen wurde, können Schwachstellen für den cpe Produktidentifikator angefragt werden.
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:
Abbildung: Anzahl der registrierter Schwachstellen pro Jahr
Abbildung: 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.
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.
