Sicherheitslücken bewerten 101: CVSS für CVEs erklärt

Ähnlich wie Softwarefehler nach ihrem Schweregrad eingestuft werden, werden auch Sicherheitslücken bewertet, um ihre Auswirkungen und Risiken einzuschätzen. Das unterstützt das Schwachstellenmanagement.

Das Forum of Incident Response and Security Teams (FIRST) ist eine internationale Organisation aus vertrauenswürdigen IT-Sicherheitsforschenden und -wissenschaftlern. Sie hat den Auftrag, Best Practices und Tools für Incident-Response-Teams zu entwickeln und Sicherheitsrichtlinien sowie Methoden zu standardisieren.

Eine Initiative von FIRST ist eine Special Interest Group (SIG), die für die Entwicklung und Pflege der Spezifikation des Common Vulnerability Scoring System (CVSS) zuständig ist. Damit soll Teams geholfen werden, den Schweregrad einer Sicherheitslücke zu verstehen und zu priorisieren.

Sicherheitslücken bewerten

CVSS gilt als Standard für die Bewertung von Sicherheitslücken in Branchen, Unternehmen und Behörden, die präzise und einheitliche Bewertungen ihrer Auswirkungen benötigen.

Das quantitative Modell von CVSS ermöglicht eine wiederholbare und präzise Bewertung. Gleichzeitig macht es die zugrunde liegenden Merkmale der Sicherheitslücke sichtbar, anhand derer die Bewertung ermittelt wurde.

CVSS wird häufig verwendet, um die Behebung von Sicherheitslücken zu priorisieren und den Schweregrad von Schwachstellen in den eigenen Systemen zu bestimmen.

Herausforderungen bei CVSS

Fehlender Anwendungskontext

Bei der Bewertung von Sicherheitslücken wird nicht immer der richtige Kontext berücksichtigt, in dem eine anfällige Komponente in einem Unternehmen eingesetzt wird. Das Common Vulnerabilities and Exposures-System (CVE) kann bei der Ermittlung der Bewertung eines Unternehmens verschiedene Variablen einbeziehen. Es gibt jedoch weitere Faktoren, die den Umgang mit einer Sicherheitslücke beeinflussen können – unabhängig von der ihr in einer CVE zugewiesenen Bewertung.

Eine vom CVSS als schwerwiegend eingestufte Sicherheitslücke in einer Komponente, die zu Testzwecken verwendet wird, etwa in einem Test-Harness, erhält von Sicherheitsteams, der IT-Abteilung oder der Forschungs- und Entwicklungsabteilung möglicherweise wenig bis gar keine Aufmerksamkeit. Ein Grund dafür könnte sein, dass diese Komponente intern als Tool eingesetzt wird und weder über eine öffentlich zugängliche Schnittstelle erreichbar noch für andere zugänglich ist.

Darüber hinaus berücksichtigen Bewertungen von Sicherheitslücken keine möglichen materiellen Folgen, etwa wenn eine Sicherheitslücke medizinische Geräte, Autos oder Versorgungsnetze betrifft. Jedes Unternehmen muss die konkreten Auswirkungen selbst bewerten und berücksichtigen, je nachdem, wie relevant und verbreitet die betroffenen Komponenten in seinen Produkten sind.

Fehlerhafte Bewertungen

Eine Bewertung einer Sicherheitslücke basiert auf mehr als einem Dutzend wichtiger Merkmale. Ohne angemessene Anleitung, Erfahrung und unterstützende Informationen können leicht Fehler passieren. Eine aktuelle akademische Studie[1] ergab, dass die Teilnehmenden nur 57 % der Fragen zur Bewertung von CVE-Sicherheitslücken korrekt beantworteten. Die Studie erläutert außerdem, welche Informationshinweise für eine höhere Genauigkeit entscheidend sind und welche tatsächlich zu Verwirrung und weniger präzisen Bewertungen führen können.

Falschmeldungen in einer CVE oder ungenaue Bewertungen für eine der Metrikgruppen sind keine Seltenheit. Dadurch besteht das Risiko, das Vertrauen in eine CVE zu verlieren oder Unternehmen grundlos in Panik zu versetzen.

Der CVSS-Wertebereich von 0 bis 10 entspricht Schweregraden von niedrig bis hoch oder kritisch. Eine ungenaue Bewertung der Variablen kann zu einem Wert führen, der der falschen CVSS-Stufe entspricht. Eine weitere Studie[2] der Carnegie Mellon University kam zu ähnlichen Ergebnissen hinsichtlich der Bewertungsgenauigkeit. In dem Bericht heißt es: „Mehr als die Hälfte der Befragten liegt nicht durchgehend innerhalb einer Genauigkeitsspanne von vier CVSS-Punkten.“ Eine Abweichung von nur vier Punkten kann bereits eine Einstufung von hoch oder kritisch auf niedrigere Stufen verschieben.

[1] Allodi, Luca & Banescu, Sebastian & Femmer, Henning & Beckers, Kristian. (2018). Identifying Relevant Information Cues for Vulnerability Assessment Using CVSS. 119-126. 10.1145/3176258.3176340.

[2] Spring, J.M, Hatleback, E. Householder, A. Manion, A. Shick, D. "TOWARDS IMPROVING CVSS" Carnegie Mellon University, Dezember 2018

Der Ansatz von Snyk

Bei Snyk verwenden wir CVSS v3.1, um Merkmale von Sicherheitslücken zu bewerten und zu kommunizieren und ihre Auswirkungen einzuschätzen.

Das spezialisierte Security Research-Team von Snyk ist an der Entdeckung neuer Sicherheitslücken in verschiedenen Ökosystemen beteiligt. Außerdem bewertet es CVE-Scores und überprüft, ob diese den Schweregrad korrekt wiedergeben. So werden die zuvor genannten Bewertungsfehler anderer Stellen, die CVEs veröffentlichen, ausgeglichen.

Die Schwachstellendatenbank von Snyk bietet zu jeder Sicherheitslücke zusätzliche Metadaten über die CVE-Details hinaus. Das Security Research-Team ergänzt die Einträge unter anderem um eine Beschreibung der anfälligen Komponente sowie um Details zum Typ der Sicherheitslücke, Beispiele und Links zu Commits, Fixes oder anderen relevanten Informationen.

Das folgende Bild zeigt eine Cross-Site-Scripting-Sicherheitslücke (XSS) im Frontend-Framework React, die verschiedene Versionen der Reihe 16.x des Moduls React DOM betrifft.

Das Bild zeigt außerdem die Basis-Metrik für den CVSS-v3.1-Score mit einer detaillierten Aufschlüsselung der Metriken.

So funktioniert CVSS

In der Geschichte von CVSS gibt es drei Versionen: von der ersten Veröffentlichung im Jahr 2004 über die breite Einführung von CVSS v2.0 bis zur aktuellen Spezifikation CVSS v3.1. Im Folgenden geht es um CVSS v3.1.

Die Spezifikation bietet ein Framework, das die Bewertung von Sicherheitslücken standardisiert und nach einzelnen Problembereichen aufschlüsselt.

Die Metriken für einen CVSS-Score sind in drei Gruppen unterteilt:

1. Basis – Metriken zur Bewertung der Auswirkungen und Ausnutzbarkeit, die weder vom Zeitpunkt der Sicherheitslücke noch von der Umgebung der Nutzerin oder des Nutzers abhängen. Dazu zählt etwa, wie leicht sich die Sicherheitslücke ausnutzen lässt. Wird einer anfälligen Komponente durch eine Sicherheitslücke der vollständige Zugriff entzogen, erhält sie beispielsweise einen hohen Wert für die Auswirkungen auf die Verfügbarkeit.

2. Zeitabhängig – Metriken, die Umstände berücksichtigen, welche den Score einer Sicherheitslücke beeinflussen. Gibt es beispielsweise einen bekannten Exploit, steigt der Score. Ist hingegen ein Patch oder Fix verfügbar, sinkt er.

3. Umgebung – Metriken, mit denen sich die Bewertung an die Auswirkungen auf die spezifische Umgebung einer Person oder eines Unternehmens anpassen lässt. Legt ein Unternehmen beispielsweise großen Wert auf die Verfügbarkeit einer anfälligen Komponente, kann es eine hohe Verfügbarkeitsanforderung festlegen und so den gesamten CVSS-Score erhöhen.

Die Basis-Metrikgruppe bildet die Grundlage eines CVSS-Vektors. Wenn zeitabhängige oder umgebungsbezogene Metriken vorliegen, fließen sie in den gesamten CVSS-Score ein.

CVSS-3.0-Metrikgruppen von FIRST / CC-BY-SA-3.0

Basis-Scores

Die CVSS-Basis-Metriken setzen sich aus den Untergruppen Ausnutzbarkeit und Auswirkungen zusammen. Sie bewerten die Anwendbarkeit auf eine Softwarekomponente, die sich auf weitere Komponenten auswirken kann – etwa Software, Hardware oder Netzwerkgeräte.

Die Ausnutzbarkeit beschreibt den Aufwand und die Mittel, die zum Ausnutzen einer Sicherheitslücke erforderlich sind. Sie umfasst folgende Metriken:

• Angriffsvektor (AV) – beschreibt vier Angriffswege, über die ein Exploit ausgeführt werden kann: physisch, lokal, benachbart und über ein Netzwerk. Je zugänglicher der Angriffsweg ist, desto höher fällt der Score aus.

Eine Cross-Site-Scripting-Sicherheitslücke (XSS) in jQuery, die auf einer öffentlich zugänglichen Website ausgenutzt werden könnte, würde beispielsweise als Netzwerkangriffsvektor bewertet.

• Angriffskomplexität (AC) – erhält einen niedrigen oder hohen Wert, je nachdem, ob für einen erfolgreichen Angriff besondere Umstände oder Konfigurationen als Voraussetzung erforderlich sind. Ein Path Traversal, der relativ einfach auszuführen ist und beispielsweise 2018 und 2017 im Next.js-Paket entdeckt wurde, weist eine niedrige Angriffskomplexität auf. Ein Beispiel für eine hohe Angriffskomplexität ist ein Timing-Angriff in Apache Tomcat.

• Erforderliche Berechtigungen (PR) – kann einen der folgenden Werte annehmen: keine, niedrig oder hoch. Diese Werte hängen davon ab, welche Berechtigungen ein Angreifer erlangen muss, um die Sicherheitslücke auszunutzen. So konnten beispielsweise durch eine beliebige Code-Injection in Wordpress MU authentifizierte Nutzer schädliche Dateien aus der Ferne hochladen und ausführen. Die Berechtigung wird als niedrig eingestuft, da jeder authentifizierte Nutzer den Angriff unabhängig von seiner Rolle und seinen Berechtigungen in einer Wordpress-Anwendung ausführen konnte.

• Nutzerinteraktion (UI) – erhält einen hohen Wert, wenn keine Aktion der Nutzer erforderlich ist, damit ein Angriff erfolgreich ausgeführt werden kann, und einen niedrigeren Wert, wenn irgendeine Form der Nutzerinteraktion erforderlich ist. Bei schädlichen Modulen, die nach der Installation die Umgebung gefährden, ist zunächst eine Interaktion erforderlich: Das schädliche Paket muss installiert werden. Im npm-Ökosystem haben wir Dutzende schädlicher Pakete beobachtet. Eines davon unternahm den Versuch, Umgebungsvariablen zu stehlen – durch einen Typosquatting-Angriff mit einem Paket namens crossenv. Dies sind Beispiele für niedrige Werte, da eine Nutzerinteraktion erforderlich ist.

Die Untergruppe der Auswirkungsmetriken beschreibt die Auswirkungen auf Vertraulichkeit, Integrität und Verfügbarkeit einer anfälligen Komponente, wenn die Sicherheitslücke erfolgreich ausgenutzt wird. Sie umfasst:

• Vertraulichkeit (C) – misst, in welchem Maß die Vertraulichkeit der betroffenen Komponente beeinträchtigt wird, beispielsweise durch die Offenlegung von Informationen gegenüber Unbefugten. Ein schwerwiegender Verlust der Vertraulichkeit tritt beispielsweise auf, wenn eine Sicherheitslücke durch beliebige Skriptinjektion in Angular-Anwendungen ausgenutzt wird (genauer gesagt in AngularJS). Nicht ausreichend bereinigte Nutzereingaben, die als DOM-Ereignis eingehen, können zur Codeausführung führen.

• Integrität (I) – misst, in welchem Maß die Integrität der betroffenen Komponente beeinträchtigt wird, etwa durch die Möglichkeit, Daten nach erfolgreicher Ausnutzung der Sicherheitslücke zu ändern. Ein schwerwiegender Integritätsverlust trat beispielsweise im Open-Source-Framework Apache Struts 2 auf, als fehlerhafte Serialisierung die Ausführung beliebiger Befehle ermöglichte. Diese Sicherheitslücke sorgte 2017 für Schlagzeilen, weil sie zum Equifax-Datendiebstahl beitrug. Weitere Informationen dazu finden Sie in unserem Blog.

• Verfügbarkeit (A) – misst den Verlust der Verfügbarkeit von Ressourcen und Funktionen der betroffenen Komponente. Dazu zählt die Frage, ob ein Angriff auf die anfällige Komponente zu einem Denial-of-Service für Nutzer führen könnte. Eine schwerwiegende Beeinträchtigung der Verfügbarkeit tritt beispielsweise bei einer Version von lodash auf, die für einen Denial-of-Service-Angriff durch reguläre Ausdrücke anfällig ist. Wird lodash als Frontend-Bibliothek eingesetzt, betrifft die Ausnutzung dieser Sicherheitslücke die Browser der Endnutzer. Noch schwerwiegender ist das Problem beim Einsatz von lodash in einer Node.js-Serveranwendung: Dort reagiert die Ereignisschleife nicht mehr, und alle eingehenden Anfragen an einen API-Dienst sind betroffen.

Wichtig ist: Wenn sich der Geltungsbereich geändert hat, geben die Auswirkungsmetriken die Folgen des höchsten Schweregrads wieder – unabhängig davon, ob die anfällige Komponente selbst oder die betroffene Komponente gemeint ist.

Schließlich ist der Geltungsbereich eine neue Metrik, die mit CVSS v3.0 eingeführt wurde. Er gibt an, ob eine Sicherheitslücke über sich selbst hinaus weitere Ressourcen betrifft. Für die Metrik zum Geltungsbereich sind die Werte unverändert oder geändert möglich. Werden durch die erfolgreiche Ausnutzung einer anfälligen Komponente Ressourcen beeinträchtigt, die einem anderen Berechtigungsbereich unterliegen, gilt der Geltungsbereich als geändert.

Beispielsweise würden Cross-Site-Scripting-Schwachstellen (XSS) in phpMyAdmin eine Änderung des Geltungsbereichs darstellen, da die anfällige Komponente phpMyAdmin ist, das als serverseitige PHP-Anwendung ausgeführt wird. Die Auswirkungen betreffen jedoch den Browser des Benutzers.

Sicherheitslücken wie die Ausführung entfernter Befehle, bei denen die anfällige Komponente mit sehr hohen Berechtigungen ausgestattet ist, eignen sich gut als Beispiel dafür, wie sich der Geltungsbereich über die Berechtigungen dieser einzelnen Komponente hinaus ändern und möglicherweise auch andere Komponenten betreffen kann.

Zeitliche Bewertungen

Die zeitliche Bewertung soll den zeitlichen Kontext zum Schweregrad einer CVE liefern. Gibt es beispielsweise bekannte öffentliche Exploits für eine Sicherheitslücke, erhöht dies deren Kritikalität und den Schweregrad der CVE, da Ressourcen für solche Angriffe dadurch erheblich leichter zugänglich sind.

Der Gesamt-CVSS-Score wird unter Einbeziehung der zeitlichen Bewertung anhand des höchsten Risikos eines Werts berechnet und nur dann berücksichtigt, wenn ein zeitliches Risiko besteht. Daher halten alle der Schwachstelle zugewiesenen Werte für die zeitliche Bewertung den Gesamt-CVSS-Score mindestens auf seinem bisherigen Niveau oder senken ihn sogar, können ihn aber nicht erhöhen.

Die Metriken für die zeitliche Bewertung sind:

• Reifegrad des Exploit-Codes (E)—misst, wie wahrscheinlich es ist, dass die Schwachstelle ausgenutzt wird. Maßgeblich ist dabei der Reifegrad des verfügbaren öffentlichen Exploit-Codes. Mögliche Werte sind „U“ für keinen verfügbaren Exploit-Code, „P“ für einen bekannten Proof-of-Concept-Code, „F“ für verfügbaren funktionsfähigen Exploit-Code oder „H“ für eine hohe Ausnutzungswahrscheinlichkeit, die entweder durch automatisierte Angriffstools wie das weithin bekannte Metasploit-Framework ermöglicht wird oder dann besteht, wenn für einen erfolgreichen Angriff kein spezieller Exploit-Code erforderlich ist.

• Behebungsgrad (RL)—misst, wie wahrscheinlich es ist, eine Risikominderung anzuwenden oder die Behebung dieser Schwachstelle abzuschließen. Wurde eine Schwachstelle beispielsweise ordnungsgemäß offengelegt und vom Anbieter bearbeitet, sollte für die anfällige Komponente bis zur Veröffentlichung der CVE ein Upgrade verfügbar sein. Mögliche Werte sind „O“ für einen offiziellen Fix, den der Anbieter als Patch oder Upgrade bereitstellt, „T“ für einen temporären Fix wie ein Hotfix-Release oder einen Workaround zur Risikominderung, „W“ für einen bekannten, aber inoffiziellen und vom Anbieter nicht unterstützten Workaround und schließlich „U“, wenn keine öffentlich bekannte Maßnahme zur Risikominderung oder Behebung verfügbar ist.

• Vertrauenswürdigkeit des Berichts (RC)—misst, wie zuverlässig der Bericht zur Schwachstelle ist. Offen gelegte Sicherheitsberichte enthalten mitunter keine ausführlichen Hintergrundinformationen oder unterstützenden Materialien wie einen Proof of Concept oder Schritte zur Reproduktion. Dadurch wird es schwieriger, die Glaubwürdigkeit des Berichts und seine Auswirkungen einzuschätzen. Mögliche Werte sind „C“ für eine hohe Sicherheit, dass sich der Bericht reproduzieren lässt, „R“ für ausreichende Angaben zur Bestätigung des Berichts und „U“ für unbekannte Details zur Ursache der Schwachstelle.

Allen drei zeitlichen Metriken kann der Wert „X“ zugewiesen werden. Er bedeutet, dass keine Werte zugewiesen werden sollen und die Metriken den Basis-Score nicht beeinflussen sollen.