Am 1. November 2023 wurde das Common Vulnerability Scoring System Version 4.0 (CVSS v4.0) veröffentlicht. Die Vorgängerversion CVSS v3.0 wurde im März 2016 vorgestellt und galt seither als Standard zur Bewertung des Schweregrads von Schwachstellen. Im Artikel CVSSV3 als Risikometrik haben wir die Version 3 analysiert. Die CVSS v4.0 Spezifikation und das Tool zur Berechnung des CVSS v4.0 Scores wurden auf der Webseite des Forum of Incident Response and Security Teams (FIRST) veröffentlicht. Dieser Artikel zeigt die Änderungen zur Version 3.1, diskutiert die Veränderungen zur Einstufung der Basismetrik und die Herausforderung zur Erstellung eines genauen Scores für eine Schwachstelle.

Änderungen zu CVSS v3.1

Um den Basis-Score einer Schwachstelle präziser einstufen zu können, wurde die Metrik Attack Requirements (AT) eingeführt und die Metrik User Interaction (UI) in die Werte Passive (P) und Active (A) aufgeteilt. Die Metrik Scope (S) wurde durch die Auftrennung der Impact-Metrik in Vulnerable System (VC, VI, VA) und Subsequent System (SC, SI, SA) ersetzt. Die Auswirkungen auf den Basis-Score wird im nachfolgenden Kapitel beschrieben.

Die Metrikgruppe Temporal wurde in Threat umbenannt und vereinfacht. Sie enthält nur noch die Exploit Maturity (E), welche die Wahrscheinlichkeit beschreibt, dass die Schwachstelle ausgenutzt wird. Dazu können die Werte Attacked (A), Proof-of-Concept (P) oder Unreported (U) verwendet werden. Diese Information wird von FIRST als Threat Intelligence bezeichnet und die Metrik sollte laufend aktualisiert werden.

Durch den Wegfall der Metrik Remediation Level (RL) geht die Information verloren, ob ein Patch oder Workaround verfügbar ist. Dies ist eine wesentliche Information für das Vulnerability Management, die nicht adäquat ersetzt wird.

Das Ziel der neuen Metrikgruppe Supplemental ist, dass Unternehmen zusätzliche Informationen zu einer Schwachstelle definieren können, die hilfreich zur Risikoanalyse sind. Die Metrikgruppe ist optional und hat keinen Einfluss auf den CVSS-Score. Mit den Metriken können Unternehmen folgende Fragen zur Schwachstelle beantworten:

• Safety: Hat diese Schwachstelle einen Einfluss auf die Sicherheit der Organisation?
• Automatable: Kann die Schwachstelle automatisiert ausgenutzt werden?
• Recovery: Können die Ressourcen nach einen Angriff wiederhergestellt werden?
• Value Density: Welche Ressourcen wird ein Angreifer kontrollieren nach einer Ausnutzung der Schwachstelle?
• Vulnerability Response Effort: Welcher Aufwand ist für die erste Reaktion notwendig?
• Provider Urgency: Wie lautet der Schweregrad der Schwachstelle durch den Hersteller?

Mit der Metrikgruppe Environmental können Unternehmen die Basismetrik einer Schwachstelle an die spezifischen Eigenschaften der eigenen Umgebung anpassen. Bereits implementierte Massnahmen, die einen Einfluss auf die Ausnutzung einer Schwachstelle haben, können so berücksichtigt werden. Wird der Dienst beispielsweise in einem isolierten Netzwerk betrieben wird, kann der Attack Vector von Network auf Adjacent reduziert werden. In dieser Metrikgruppe wurde mit der Schaffung des Wertes Safety für Integrity (MSI) und Availability (MSA) ein stärkerer Fokus auf Operational Technology (OT), Industrial Control Systems (ICS) und die Sicherheit (Safety) im Allgemeinen gelegt.

Basismetrik

Bei der Einstufung der Basismetrik wird davon ausgegangen, dass der Angreifer detaillierte Kenntnisse über die Schwachstelle des Zielsystems hat. Dazu gehören die Basiskonfiguration und Standardabwehrmechanismen wie eine Host-Firewall oder die Beschränkung von Abfragen (Rate Limits). Falls spezifische Abwehrmassnahmen, wie unter anderem eine Zugriffsliste für bestimmte Netzwerkbereiche, implementiert wurden, sollen diese in der Metrikgruppe Environmental berücksichtigt werden und keinen Einfluss auf die Basismetrik haben.

Verfeinerte Einstufung der Exploitability-Metrik

Die bisherige Definition der Attack Complexity (AC) wurde durch die Schaffung der Attack Requirements (AT) angepasst. AC misst nun die Hürden, die ein Angreifer zur Ausnutzung der Schwachstelle überwinden muss. Dazu gehören beispielsweise die Techniken Address Space Layout Randomization (ASLR) und Data Execution Prevention (DEP). Beide Techniken erschweren die Entwicklung von Exploits. Ein weiteres Beispiel für AC ist ein Geheimnis (Secret), das ein Angreifer kennen muss, wie ein geheimer Schlüssel zum Brechen eines Kryptokanals.

Die Attack Requirements (AT) beschreiben die notwendigen Vorbedingungen, die einen Angriff auf ein verwundbares System ermöglichen. Der Unterschied zu AC ist, dass diese Bedingungen nicht explizit existieren, um einen solchen Angriff zu verhindern, sondern eine natürliche Folge des Betriebs des Systems sind. Beispiele hierfür sind die Notwendigkeit einer Machine-in-the-Middle-Attacke (MitM) oder die Abhängigkeit der erfolgreiche Ausnutzung eines Exploits vom Gewinn einer Race Condition.

Der Penetration Tester Konstantin beschreibt jedoch in seinem Artikel zum CVSS v4.0 Public Preview, dass die Trennung zwischen AC und AT nicht immer so klar ist. Sein Beispiel zeigt eine verwundbare Applikation, die in einem Container betrieben wird. Grundsätzlich können Container als Gegenmassnahme gegen einen Angriff betrachtet werden, da der den Container das Hostsystem vom Dienst trennt. Container sind auch ein nützliches Feature für die Skalierbarkeit von Applikationen und somit ist die Verwendung eines Containers eine natürlich Konsequenz. Hier ergibt sich ein Interpretationsspielraum, der im konkreten Fall nur durch den Entwickler der Applikation beantwortet werden kann.

Bei der Metrik User Interaction (UI) erleichtert die Einführung der Werte Passive (P) und Active (A) die Unterscheidung. Wenn eine Webapplikation eine Stored-XSS-Schwachstelle aufweist, reicht es aus, wenn der Benutzer die Applikation normal verwendet, damit der JavaScript-Code in seinem Browser ausgeführt wird. Handelt es sich jedoch um eine Reflected-XSS-Schwachstelle, muss der Benutzer aktiv auf einen präparierten Link klicken, damit der Schadcode ausgeführt wird.s

Die Unterscheidung zwischen Active und Passive einer XSS-Schwachstelle beträgt 0.2 Punkte, der CVSS-Vektor-String für eine Stored-XSS-Schwachstelle (Score 5.1) ist CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:A/VC:L/VI:L/VA:N/SC:N/SI:N/SA:N und für die Reflected-XSS-Schwachstelle (Score 5.3) CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:P/VC:L/VI:L/VA:N/SC:N/SI:N/SA:N.

Erweiterte Definition des Wirkungsbereichs

Die Metrik Scope wurde durch die Unterteilung des Wirkungsbereichs in Vulnerable System (VC, VI, VA) und Subsequent System (SC, SI, SA) ersetzt. Neu wird auch die Auswirkung der Schwachstelle auf umliegende Systeme auch in Confidentiality, Integrity und Availability unterteilt, was zu einer Verlängerung des Basisvektorstrings führt. Ein verwundbares System wird in der Spezifikation folgendermassen definiert:

Formally, a system of interest for scoring a vulnerability is defined as the set of computing logic that executes in an environment with a coherent function and set of security policies. The vulnerability exists in one or more components of such a system. A technology product or a solution that serves a purpose or function from a consumer’s perspective is considered a system (e.g., a server, workstation, containerized service, etc.).

Wenn ein System seine Funktionalität ausschliesslich einem anderen System zur Verfügung stellt, oder es nur für die Nutzung durch ein anderes System entwickelt wurde, dann werden beide Systeme zusammen in den Scope aufgenommen. Wenn die Auswirkung einer Schwachstelle über das definierte System hinausgeht, dann kann dies neu in den Subsequent System Metriken berücksichtigt werden.

Diese unscharfe Definition des Systems führt zu Interpretationsspielraum. Aus den Beispielen von FIRST lässt sich unter anderem ableiten, dass bei einer Schwachstelle in einer virtuellen Maschine (Guest) wie CVE-2023-21989 der Hypervisor (Host) als Subsequent System gilt, da der Hypervisor auch andere virtuelle Maschinen bereitstellt. In den Beispielen zu OpenSSL Heartbleed oder log4shell wird das gesamte System/Gerät (Webserver und Betriebssystem) in den Scope des Vulnerable System aufgenommen. Hier wäre es aber auch möglich, die Grenze bei der Webserver-Komponente zu ziehen und das darunter liegende Betriebssystem als Subsequent System zu betrachten. In der Einstufung der Schwachstelle Spring4shell wird darauf hingewiesen, dass je nach Einsatz von Spring auch andere Systeme betroffen sein können, dies aber in den Environmental-Metriken berücksichtigt werden sollte.

Im Auge des Betrachters

Die Komplexität der Einstufung einer Schwachstelle wird durch CVSS v4.0 erhöht und der Aufwand für die Definition einer genauen Einstufung steigt. Zudem liegt die Einstufung einer Schwachstelle mehr denn je im Auge des Betrachters. Aus der Sicht eines Sicherheitsforschers und Entdeckers einer Schwachstelle sollte die höchstmögliche Auswirkung angenommen werden, beispielsweise eine Remote-Code-Execution-Schwachstelle (RCE) wird mit den höchsten Rechten ausgeführt und betrifft das gesamte System, was zu einem hohen CVSS-Score führt. Wenn nun diese verwundbare Komponente in einem Penetration Test entdeckt und die Schwachstelle ausgenutzt wird, liegt es im Ermessen des Penetration Testers, ob er die Auswirkung neu einstuft oder nicht. Wird der Code auf dem System beispielsweise von einem nicht-privilegierten Service-Account ausgeführt, ist die Auswirkung geringer und sollte entsprechend dem Scope korrigiert werden. Alternativ wird die Metrik Environmental zusätzlich für den Penetration Test verwendet, um Diskussionen zu vermeiden, warum die Einstufung in einer Schwachstellendatenbank X und im Bericht Y ist.

Der Kunde wiederum betreibt das System in einem abgeschotteten Container, so dass die Auswirkung weiter begrenzt wird. Basierend auf der CVSS-Spezifikation kann und soll der Kunde dies in der Metrik Environmental selbst berücksichtigen. Je nach Ansatz liegen nun zwei korrigierte Metriken vor, beziehungsweise die Metrik Environmental kann vom Kunden weiter ausgeprägt werden.

Fazit

Der CVSS-Score liefert mit dem Schweregrad einer Schwachstelle einen Beitrag zur Risikobewertung einer Schwachstelle. Wenn der CVSS-Score aus einer Schwachstellendatenbank übernommen wird, gibt es Unbekannte, wie unter anderem was als Scope des verwundbaren Systems verwendet wurde. Um einen exakten Score zu erhalten, sollte der Score durch das Unternehmen entsprechend der Umgebung neu bewertet werden. Die in Version 4 eingeführte Trennung der Auswirkungen wird daher zu Interpretationsspielraum und unterschiedlichen Ergebnissen führen. Ohne eine Neubewertung wird daher mit ungenauen Informationen weitergearbeitet, was das Gegenteil des Ziels eines solchen Scores ist.

Um von den Neuerung des Basis-Scores von CVSS v4.0 profitieren zu können, muss ein entsprechender Aufwand betrieben werden und eine Neubewertung durch Fachexperten erfolgen, welche die Zielumgebung kennen und mit der Komplexität der Einstufung vertraut sind. Andernfalls wird mit ungenauen Informationen gearbeitet, was keine Verbesserung gegenüber dem Status quo von CVSS v3.1 darstellt.

Über den Autor

Michael Schneider arbeitet seit dem Jahr 2000 in der IT. Im Jahr 2010 hat er sich auf die Informationssicherheit spezialisiert. Zu seinen Aufgaben gehören das Penetration Testing, Hardening und das Aufspüren von Schwachstellen in Betriebssystemen. Er ist bekannt für eine Vielzahl in PowerShell geschriebener Tools zum Finden, Ausnutzen und Beheben von Schwachstellen. (ORCID 0000-0003-0772-9761)

Links

• https://infosec.exchange/@kpwn
• https://kpwn.de/2023/08/cvss-v4.0-public-preview/#deployment-consequence-or-security-measure
• https://vuldb.com/?id.12819
• https://vuldb.com/?id.187925
• https://vuldb.com/?id.196076
• https://vuldb.com/?id.226737
• https://www.first.org/
• https://www.first.org/cvss/calculator/4.0
• https://www.first.org/cvss/v4-0/
• https://www.first.org/cvss/v4.0/examples
• https://www.first.org/cvss/v4.0/specification-document