Common Vulnerabilities and Exposures (CVE) CVE & Co. für Einsteiger

Autor / Redakteur: Ralph Dombach / Peter Schmitz

Sicherheitslücken stellen seit Jahren eine gewaltige Bedrohung für die Sicherheit von IT-Systemen dar. Damit Sicherheitsexperten, Entwickler und Anwender weltweit gemeinsam an der Beseitigung von Sicherheitslücken arbeiten können bedarf es eines einheitlichen Schemas zur Identifikation der Schwachstellen. Das Common Vulnerabilities and Exposures (CVE) bildet dazu seit 1999 einen unverzicht­baren Industriestandard.

Anbieter zum Thema

Wer bei der großen Zahl an jährlich entdeckten Schwachstellen und Sicherheitslücken in Programmen und Geräten den Überblick behalten will, muss sich mit CVE und CVSS auskennen.
Wer bei der großen Zahl an jährlich entdeckten Schwachstellen und Sicherheitslücken in Programmen und Geräten den Überblick behalten will, muss sich mit CVE und CVSS auskennen.
(© itcraftsman - stock.adobe.com)

Im täglichen Fachgespräch zwischen Security-Experten fällt immer mal wieder der Begriff CVE – verbunden mit der Frage ob man davor geschützt ist oder mit der positiven Feststellung das dies der Fall ist. Wer nun nichts mit dem Begriff „CVE“ anfangen kann, steht oft ratlos daneben und wundert sich nur. Dabei ist die Sache ganz einfach. Denn CVE ist die Abkürzung für Common Vulnerabilities and Exposures. Dies ist nichts anderes als die etablierte Bezeichnung für eine Schwachstelle und deren Gefährdungspotential im Security-Jargon. Anders als beispielsweise bei Malware, hat man hier auf die Benennung von Schwachstellen mit mehr oder weniger sprechenden Namen verzichtet und stattdessen ein Nummernschema (CVE-YYYY-NNNN) eingeführt, welches, aus dem CVE-Prefix, dem Jahr der Entdeckung der Schwachstelle (YYYY), und einer fortlaufenden Nummer (NNNN) besteht.

Mit Einführung der CVE-Bezeichnung im Jahr 1999 wurden 4 Stellen als ausreichend betrachtet um alle gefundenen Schwachstellen zu bezeichnen und die maximale Anzahl von 9999 schien mehr als ausreichend. Die Praxis zeigt aber, dass dies nicht ausreichte, denn 2017 überschritt die Zahl der gemeldeten Schwachstellen erstmals die Zehntausender-Grenze (14.714) und auch 2018 sind bis ende Juli bereits über 10.000 erfasst (10.744). Vorausschauend wurde daher im Januar 2014 eine Syntaxänderung mit beliebig vielen Stellen (mindestens vier) beschlossen. Die CVE-ID-Syntaxänderung trat am 1. Januar 2014 in Kraft und CVE-IDs mit der neuen Syntax wurden erstmals am 13. Januar 2015 veröffentlicht.

Bildergalerie
Bildergalerie mit 13 Bildern

Die amerikanische Organisation Non-Profit-Organisation Mitre ist Schirmherr des CVE-Systems. CVE ist dabei der Lösungsansatz, Schwachstellen in ein einheitliches Schema zu packen. Aktuell unterstützen weltweit 88 Organisationen die CVE-Liste, diese werden als CNA (CVE Numbering Authority) bezeichnet.

CNAs sind berechtigt, Schwachstellen, die Produkte in ihrem jeweiligen vereinbarten Umfang betreffen, CVE-IDs zuzuweisen, damit sie bei erstmaligen öffentlichen Bekanntgabe neuer Sicherheitslücken berücksichtigt werden können. Die aktuellen CNAs können dabei über die Mitre Webseite abgerufen werden. Die Anzahl der Produkte, die sich in der CVE-Liste wiederfindet, geht dabei weit über 3000 – wobei es einmalige Meldungen gibt, aber auch mehrfachen Schwachstellen je Produkt. Eine Liste aller CVEs lässt sich auch bequem herunterladen.

CVE-Übersicht im Detail

Einen übersichtlichen Blick auf die gemeldeten Schwachstellen gibt der Service „CVE Details“, der eine übersichtliche Darstellung der CVE-Liste von Mitre erlaubt. Im Wesentlichen handelt es sich hier um eine Datenbank, die diverse Abfragen ermöglicht. So werden hier auch die rund 1300 Hersteller benannt, die Input für die CVE-Liste liefern. Aufgeschlüsselt nach Herstellername, Anzahl der Produkte und Schwachstellen. Bei Microsoft, einem der großen Unternehmen finden sich hier gegenwärtig 471 Produkte und 5773 Schwachstellen. Als Vergleich dazu Mozilla (23 Produkte und 1801 Schwachstellen) und Google (63 Produkte und 3524 Schwachstellen).

Man sollte sich aber nun nicht verleiten lassen und die Anzahl der CVEs für eine Produktbeurteilung heranzuziehen. Denn zunächst ist eine CVE nur eine gefundene Schwachstelle. Dies sagt noch nichts über das Risiko aus, das dies Schwachstelle auch ausgenutzt werden kann und über die Auswirkungen eines Exploit auf ein Unternehmen bzw. dessen IT-Infrastruktur. Es ist also das Risiko, welches die Gefährdung bzw. das Risiko der CVEs definiert und nicht deren Anzahl. Aber auch hier gibt es einen Ansatz der dem Sicherheitsverantwortlichen das Leben etwas erleichtert - das CVSS (Common Vulnerability Scoring System).

Risikobestimmung mit CVSS

CVSS legt das Risiko einer Gefährdung fest. Auch hier gibt es Regelwerke, die genau definieren, wie sich der CVSS ergibt und wie man ihn ermittelt. Eine einfache Art, den Risiko-Faktor zu berechnen, bietet der „Common Vulnerability Scoring System Version 3.0 Calculator“ von FIRST. Die Organisation wurde gegründet, um die Zusammenarbeit von Incident-Response-Teams besser zu koordinieren. Die Nutzung des „CVSS Calculator“ ist denkbar einfach. Aus einer vorgegebenen Gruppe von Eigenschaften wählt der Bearbeiter die aus, welche seiner Schwachstelle am besten entsprechen. Beispielsweise welcher Aufwand erforderlich ist, um die Schwachstelle auszunutzen. Die Notwendigkeit von erweiterten Privilegien oder auch ob Anwender-Interaktionen erforderlich sind. Je einfacher eine Schwachstelle auszunutzen ist und umso geringer die zu überwindende Hürde und desto höher der Risiko-Faktor der Schwachstelle. Der Risiko-Faktor erreicht dabei Werte von 0,0 bis 10,0 wobei 10 den höchsten Wert darstellt.

CVE Details bietet auch hier wieder eine gute Ergänzung an. Eine Bubbles-Grafik zeigt übersichtlich die Score-Werte aller gemeldeten Schwachstellen. Im Jahr 2017 lag der durchschnittliche CVSS-Score der 14.714 benannten Schwachstellen bei 6,4 Punkten. Kritische Elemente, mit einem Score von 8 bis 10 lagen bei knapp 11 Prozent der Gesamtmenge. Für die ersten 6 Monate des Jahres 2018 zeigt sich aber der Trend, dass die Werte des Vorjahres überschritten werden. Denn 8569 gefundene Schwachstellen forcieren diesen Trend.

Quellenstudie mit NIST & Co.

In Fachgesprächen zwischen den Security-Experten wird auch irgendwann eine konkrete CVE genannt, wie CVE-2018-8136. Die CVE-ID allein sagt dabei noch nichts aus, erst durch die Detailinformationen bei CVE Details oder anderen Anbietern erhält man hier eine genaue Beschreibung. Generell empfiehlt es sich auch, nicht nur eine Beschreibung als Informationsbasis zu nutzen, sondern mindestens zwei – besser drei.

Viele Hersteller von Security-Tools wie z.B. Rapid7, Symantec und Organisationen wie CERT haben eigene, CVE-kompatible Datenbanken aufgebaut. Aber auch Hersteller wie beispielsweise Adobe, Cisco oder Intel führen eigene Listen um Ihre Kunden zu informieren oder spezielle Hinweise auf für die eigenen Produkte zu geben. Den Reigen ergänzen aber auch wieder bewährte Informationslieferanten wie beispielsweise CVE Details oder NIST.

Die Frage nach dem „Was ist besser?“ lässt sich nicht generell beantworten, denn die wesentlichen Informationen sind identisch. Aber die Darstellung und ggf. im Text enthaltenen Querverweise erhöhen den Mehrwert deutlich. Von daher wird jeder Security-Verantwortliche seine eigene Präferenz haben, unter den Anbietern. Für das National Institute of Standards and Technology (NIST) spricht, dass es eine offizielle Institution ist und die Informationen stets qualifiziert sind, wie eine Recherche für CVE-2018-8136 zeigt. Auch bei CVE Details findet man zahlreiche Informationen zur entsprechenden CVE. Unter Umständen werden diese sogar etwas früher veröffentlicht als bei anderen Stellen – im Kampf gegen Schwachstellen ein Pluspunkt.

Letztendlich kann aber sogar auch die Informationsbasis eines Herstellers für den Security-Verantwortlichen interessanter sein, wenn dort produktspezifische Hinweise enthalten sind, die in anderen Quellen nicht aufgeführt werden. Es ist also eine gewisse zeitliche Vorarbeit zu investieren, bis man die für das eigene Umfeld beste Variante gefunden hat.

Die Suche nach der Nadel im Heuhaufen

Was CVE bedeutet ist geklärt, ebenso einige nützliche Tools – aber die Gretchenfrage ist nach offen: „Wie findet man Schwachstellen im eigenen System“? Hier greifen die Tools, die man von einzelnen Security-Anbietern erwerben kann. Diese scannen einzelne Systeme oder per Remotezugriff ganze Netzwerke nach verwundbaren Systemen. Diese Tools sind wahre Alleskönner, die auch Systeme patchen können oder andere Software Deployment-Tools instruieren, die Schwachstellen zu beseitigen.

Es gibt aber auch Freeware-Produkte, die nach Schwachstellen suchen. Teilweise sind diese aber auf bestimmte Ziele fokussiert (Webseiten, Web-Anwendungen, Datenbanken, Produkte, Programmier-Sprachen etc.). Freie Tools wie OpenVAS sind Mangelware. Eine Aufstellung verschiedener freier und kommerzieller Vulnerability-Scanner findet sich bei OWASP, einer Non-Profit-Organisation, die sich der Entwicklung, vertrauenswürdige Anwendungen verschrieben hat.

Eine spezifische Variante ist der kostenlose MBSA (Microsoft Baseline Security Analyzer), der sich auf Schachstellen im MS-Umfeld fokussiert. Microsoft nutzt im MSBA bevorzugt ein eigenes Namens-Schema, so dass die CVE-ID oft erst nach Nutzung einiger Links ersichtlich wird. Aber MBSA ist einfach zu bedienen und ein hilfreiches Werkzeug für Windows-Systeme! Wem dies nicht genügt, der kann auch mit professionellen Tools erste Erfahrungen sammeln, denn die meisten Hersteller bieten (zeitlich und funktionell beschränkte) Testlizenzen Ihrer Produkte an.

Kali Linux Workshop
Bildergalerie mit 5 Bildern

Zusammenfassung

Schwachstellen und CVE sind ein komplexes Thema, aber mit einem soliden Grundwissen kann man schon einiges erreichen. Dabei wird es in Zukunft eine elementare Rolle spielen, Security-Schwachstellen zeitnah zu bearbeiten. Das umfasst ein Testen in der Zielumgebung ebenso, wie einen schnellen Rollout auf alle verwundbaren Systeme.

Anders als bei Produkt-Patches ist dies jedoch keine Aufgabe, die sich über Wochen hinziehen kann, sondere ein Job der in zwei oder drei Arbeitstagen (oder schneller) erledigt sein sollte. Das dies angesichts der zunehmenden Anzahl von Produkten und Schwachstellen eine Herausforderung für jedes Security-Management ist, liegt dabei klar auf der Hand.

(ID:45427529)