Common Vulnerabilities and Exposures Die CVE-Auflistung bekannter Sicherheitslücken

Im Rahmen von IT-Security-Warnungen werden oft CVE-Einträge genannt, die bestimmte Lücken und Risiken in Software-Produkten adressieren. Aber was genau steckt hinter den Common Vulnerabilities and Exposures?

Anbieter zum Thema

FTAPI Software GmbH

Pathlock Deutschland | akquinet enterprise solutions GmbH

Sicherlich haben Sie schon mal in einer Sicherheitswarnung einen Hinweis in der Art „CVE-2018-0001“ gesehen. Zumindest bei jeder größeren, öffentlich bekannten Schwachstelle sollte ein CVE-Verweis (im Folgenden kurz: CVE) mit angegeben sein.

Das Kürzel steht für Common Vulnerabilities and Exposures und ist ein Industriestandard zur Benennung öffentlich bekannter Sicherheitslücken. Das System wurde bereits 1999 eingeführt, um Schwachstellen eindeutig benennen und somit auch Doppelungen vermeiden zu können. CVEs haben dabei nicht nur für Entwickler, Hacker und Institutionen der Cybersicherheit enorme Bedeutung – auch Verbraucher kommen indirekt damit in Kontakt.

Beispielsweise hat der Verbraucherschutz NRW in 2017 einen Händler abgemahnt, der ein Smartphone mit bekannten, nicht behobenen Sicherheitslücken im Angebot hatte, welches vom Hersteller nicht mehr mit Patches versorgt wurde. Ausschlaggebend für die Argumentation waren auch hier CVEs.

Über CVEs gibt es also auch einen gewissen Druck auf die Hersteller der betroffenen Produkte, zumal die aufgegriffenen Anfälligkeiten eben öffentlich sind. Nicht behobene Schwachstellen, die als CVE veröffentlicht wurden, sind entsprechend Glücksfälle für Cyber-Kriminelle. Das Kürzel CVE beschreibt also wie erwähnt sowohl Industriestandard als auch Namenskonvention, impliziert aber ebenso die vollständige Liste aller einzelnen CVEs.

Die Schwachstellen-Auflistung ist in großen Teilen ein Community-Projekt, dahinter steckt jedoch die MITRE Organization. Diese US-amerikanische Non-Profit-Organisation kümmert sich im Wesentlichen um Forschungsfinanzierungen und wird staatlich finanziert. MITRE stellt Informationen und Webseiten zur Verfügung, pflegt die CVE-Liste und agiert als Root CNA (CVE Numbering Authority). Mehr dazu später.

Eng mit dem Projekt verbunden ist auch die U.S. National Vulnerabilities Database (NVD), die 2005 vom National Institute for Standards and Technology (NIST) gegründet wurde. Die NVD speist sich aus der CVE-Liste und stellt erweiterte Informationen sowie Suchmöglichkeiten zur Verfügung.

Wie sieht ein CVE-Eintrag aus?

In der freien Wildbahn sieht man meist nur die CVE ID, bestehend aus der Jahreszahl gefolgt von einer fortlaufenden Identifikationsnummer. CVEs haben aber natürlich noch weitere Einträge, hier mal ein vollständiges Beispiel aus der MITRE-Dokumentation:

Alle Informationen sind grundsätzlich auf Englisch gehalten. Neben der CVE-Nummer gibt es hier detailliertere Informationen zum betroffenen Produkt und genauere Ausführungen zum Problem. Auch Referenzen sind in jedem CVE-Eintrag zu finden. Wie genau CVEs in der Praxis aussehen, können Sie direkt in der NVD nachschauen.

CVE ist also ein eindeutiger Bezeichner für eine einzelne Schwachstelle/Enthüllung, eine Namenskonvention, eine simple Liste (keine Datenbank), Basis für die Evaluation von Services, Tools und Datenbanken, frei für Jedermann nutzbar und ein Industriestandard, der natürlich auch entsprechende Prozesse voraussetzt.

Wie entstehen CVEs?

Damit eine entdeckte Lücke zur CVE wird, muss eine CVE ID beantragt werden. Grundsätzlich gibt es zwei Wege: Einerseits lassen sich Anträge öffentlich direkt bei der MITRE stellen, andererseits gibt es speziell für öffentliche (!) Probleme bei Open-Source-Software das Distributed-Weakness-Filing-Formular (DWF).

Verantwortlich für die Vergabe sind die bereits erwähnten CNAs, die CVE Numbering Authorities. Die MITRE selbst agiert derzeit als primäre CNA, daneben gibt es Stand 2018 genau 87 Entitäten, die entsprechende Nummern vergeben: 72 IT-Anbieter und -Projekte, sieben IT-Security-Forscher, drei CERTs, zwei Bug-Bounty-Programs sowie DWF und das japanische CERT als Root CNAs.

Aus Deutschland ist beispielsweise SAP mit an Board. Probleme, für die eine bestimmte CNA verantwortlich ist, müssen eben jener Authority gemeldet werden, ansonsten können die obigen Formulare genutzt werden. Die CNA schreibt nach einer Meldung die Beschreibung, fügt Referenzen hinzu und vervollständigt allgemein den CVE-Eintrag.

Dabei bekommen ausschließlich „öffentliche“ Schwachstellen eine CVE ID. Das heißt unter anderem, dass es eine öffentlich zugängliche Website mit Informationen zur Lücke gibt, die die CVE List verlinken kann. Wenn Sie sich mit den Interna von CVE beschäftigen wollen, finden Sie das gesamte CNA-Regelwerk online bei der MITRE.

Was wird zu einer CVE?

Die eben verlinkte Dokumentation der CNA-Regularien gibt auch einen wunderbaren Einblick in die inhaltlichen Entscheidungsprozesse. Dabei helfen zwei Entscheidungsbäume zu erfassen, ob eine CVE ID vergeben wird und um wie viele einzelne CVEs es sich bei einem Report überhaupt handelt. Interessant ist vor allem der erste Baum, der folgende fünf Phasen durchläuft:

• Phase 1: Fällt die Schwachstelle überhaupt in den Zuständigkeitsbereich der CNA? Im Zweifel wird eine Root CNA konsultiert, ansonsten geht es weiter zu …

• Phase 2: Ist die Schwachstelle tatsächlich für die Öffentlichkeit gedacht oder bereits veröffentlicht? Falls ja, geht es weiter.

• Phase 3: Wird die Software vom Kunden installiert und kontrolliert? Spezifische Webseiten, Software-as-a-Service-Lösungen und sonstige Varianten, die unter voller Kontrolle des Anbieters stehen, fallen aus dem CVE-Spektrum heraus. Falls die Software vom Kunden kontrolliert wird oder die Frage nicht klar zu beantworten ist, folgt …

• Phase 4: Ist die Software allgemein verfügbar und lizenziert? Wieder können Produkte herausfallen: Für einzelne Commits, die zwischen Releases existieren, geschlossene Beta-Versionen, Software, die nur in einem bestimmten Unternehmen läuft und explizit für Malware wird keine ID vergeben. Ist die Software jedoch ein verfügbares und lizenziertes Produkt, bleibt noch die letzte Phase, die eines der ursprünglichen Probleme adressiert.

• Phase 5: Gibt es für die Schwachstelle bereits eine CVE ID? Falls nicht, wird diese schlussendlich vergeben.

Wie geht es weiter?

Nun hat also jemand eine Schwachstelle entdeckt und einen Report eingereicht – und schon sind alle Infos online? Natürlich nicht. Wie genau mit gemeldeten Problemen umgegangen wird, liegt auch an der jeweiligen Numbering Authority.

Das US-CERT beispielsweise informiert den betroffenen Software-Anbieter und gibt diesem standardmäßig 45 Tage Zeit für das Bug-Fixing. Erst danach wird die CVE veröffentlicht. Bei besonders dringlichen Fällen, etwa bei bereits laufenden Exploits, kann dieser Zeitraum verkürzt werden. Werden umfangreiche Änderungen beispielsweise an Standards notwendig, kann der Zeitraum auch ausgedehnt werden.

Vorab werden die Informationen bereits mit dem Anbieter und weiteren Betroffenen geteilt. Dies können zum Beispiel Security-Spezialisten sein, Institutionen, die akut von der jeweiligen Schwachstelle betroffen sein könnten und generell jedem, der nach Ansicht des US-CERTs zur Lösung des Problems beitragen könnte. Ganz allgemein behält sich zumindest dieser CNA vor, eingereichte Anträge gar nicht zu veröffentlichen.

Zum Schluss noch ein Blick auf ein paar Zahlen, um ein Gefühl für die Größenordnungen zu bekommen. Die Erfahrung lehrt, dass „Acrobat“ sicherlich ein guter Suchbegriff sein sollte – und in der Tat bringt NVD stattliche 1.145 Treffer zu Tage. Davon 106 am 20. Juli 2018. Die als CSV-Datei bereitgestellte CVE-Liste umfasst über 130.000 Einträge. Darunter sind allerdings auch viele von CNAs reservierte, nicht genutzte IDs.

Die Webseite CVE Details gibt tiefere Einblicke und spricht von insgesamt 105.816 CVEs. Ein Blick auf die Seite lohnt sich, zumal hier auch das Bewertungssystem Common Vulnerability Scoring System (CVSS) Anwendung findet. CVSS-Werte reichen von 0 (keine Bedrohung) bis 10 (kritisch), der Durchschnittswert der CVE List liegt bei 6,6.

Heutzutage werden täglich neue CVE IDs vergeben und es lohnt sich, das Thema zu verfolgen. Bei der Entwicklung lassen sich beispielsweise Sicherheitsrisiken durch Abhängigkeiten von Drittsoftware minimieren. Github etwa hat kürzlich ein Warnsystem eingeführt, welches CVEs berücksichtigt. Auch viele Security-Services, etwa die CERT-BUND-Meldungen, nennen explizit auch die zu einer Warnung bzw. zu einem Produkt gehörenden CVE IDs.

(ID:45468948)