Das Common Vulnerability Scoring System (CVSS) konnte sich als Risikometrik im Bereich der technischen Cybersicherheit etablieren. Seit dem Erscheinen von CVSSv2 im Jahr 2007 wird der Ansatz breitflächig als Industriestandard verwendet, um Schwachstellen mit nachvollziehbaren Risiken zu versehen. Selbst die Verbesserungen in CVSSv3 haben das System aber nicht vor Kritik bewahrt. Der jüngst erschienene Nachfolger CVSSv4 stellt jedoch meines Erachtens einen konkreten Schritt in die falsche Richtung dar. Dieser Beitrag diskutiert, was schlechter wurde und warum ich hoffe, dass es sich nicht durchsetzen wird.

Unser Red Team ist bestens vertraut mit CVSS, denn schliesslich ist es fester Bestandteil unserer Risikoeinschätzungen, wie wir sie in Berichten und Präsentationen unseren Kunden zur Verfügung stellen. Hinzu kommt, dass scip knapp 20 Jahre für VulDB zuständig war und in dieser Zeit rund 150’00 Schwachstellen durch unser Moderationsteam mit CVSSv2 und CVSSv3 eingestuft wurde. Mittlerweile gehört VulDB nicht mehr zu scip. Dennoch begleiten wir auch dort gegenwärtige die Einführung von CVSSv4. Wir mussten uns also sowohl in Bezug auf Prozesse (z.B. Moderation) als auch technische Umsetzung (z.B. Implementierung, Kalkulationen, Parsing) sehr intensiv mit der neuen Iteration auseinandersetzen.

Hierbei sind uns Eigenheiten aufgefallen, die sich als potentiell diskussionswürdige Paradigmenwechsel oder Unschönheiten abtun lassen. Sie erfordern ein Umdenken oder verhindern die Vergleichbarkeit mit den Scores der vorangegangenen Versionen. Manche Aspekte stellen jedoch eine konkrete Verschlimmbesserung dar, die so wohl nicht in Kauf genommen werden will. Diese könnten eine breite Akzeptanz der neuen Version verhindern.

Viel zu langen Vektoren

Mit CVSS lassen sich quantitative Scores berechnen, die von 0.0 bis 10.0 reichen. Bevor ein solcher überhaupt berechnet werden kann, muss ein Vector String erstellt werden. Dieser besteht aus einzelnen Attributen, die die Beschaffenheit einer Schwachstelle skizzieren. Zum Beispiel wird der Attack Vector (AV) verwendet, um die Zugriffsmöglichkeiten eines Angriffs zu spezifieren. Ein AV:N bedeutet, dass der Angriff über das Netzwerk möglich ist. Andernfalls würde er AV:A für Adjacent Network (im LAN), AV:L für Local oder AV:P für Physical ausweisen.

Ein CVSSv2 Base Vector umfasst 6 Attribute. Eine nicht-authentisierte SQL-Injection, die sich über das Internet ausnutzen liesse, führt zu diesem simplen Vektor:

CVSS2#AV:N/AC:L/Au:N/C:P/I:P/A:P

Eine der Verbesserungen von CVSSv3 war das Einführen zusätzlicher Attribute, wodurch die Beschaffenheit einer Schwachstelle mit einem Mehr an Granularität skizziert werden konnte. Plötzlich sind Attributsnamen nun entweder eine oder zwei Stellen lang. Neu Eingeführt wurden User Interaction (UI) und Scope (S). Beide haben im etablierten SQL-Injection-Scenario keinen Einfluss, wodurch sich der neue Vektor mit seinen 8 Attributen wie folgt gestaltet:

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:L

Mit CVSSv4 wurden weitere Attribute hinzugefügt. Zusätzlich zu Attack Complexity (AC) wird nun ebenfalls Attack Requirements (AT) genutzt und der seit CVSSv3 eher stiefmütterlich eingesetzte Scope (S) wurde gleich in drei Attribute der Subsequent System Impact Metrics aufgeteilt. Der neue Vektor für die gleiche SQL-Injection sieht dann mit seinen ganzen 11 Attributen so aus:

CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:L/VI:L/VA:L/SC:N/SI:N/SA:N

Die Anzahl der minimal eingesetzten Attribute für den Base Score hat sich also seit CVSSv2 fast verdoppelt. Vorbei sind hiermit die Zeiten, in denen mit einem Blick die Struktur einer Schwachstelle ermittelt werden konnte. Die Simultanerfassung (Subitizing) des Menschen ist gar nicht mehr in der Lage, das zu tun, wird bei Erwachsenen nämlich bei Anzahlen grösser als 4 zunehmend Fehler gemacht. Stattdessen muss also in mühsamer Weise der Vektor dissektiert und die einzelnen Attribute für sich betrachtet werden. Diese Vektoren scheinen also nicht mehr für Menschen gemacht zu sein.

Doch auch das Erstellen der Vektoren ist mit einem Mehr an Aufwand verbunden. Da, wie wir gleich sehen werden, die Attribute nicht mehr das gleiche Gewicht haben, gestaltet sich das Ausarbeiten von CVSSv4-Vektoren als überaus mühsam. Vor allem dann, wenn gewisse Unbekannten gegeben sind.

Unwichtige Subsequent System Impact Metrics

Grundsätzlich wird in CVSSv4 der Impact in den Vulnerable System Impact Metrics (VSIM) definiert. Diese spezifizieren die Auswirkungen, die das angegriffene System erfährt. Neu wird VC statt C (Confidentiality), VI statt I (Integrity) und VA statt A (Availability) verwendet.

In CVSSv3 wurde das Attribut Scope (S) eingeführt. Es wird herangezogen, um zu deklarieren, ob ein Angriff nur das angegriffene System betrifft (S:U für Unchanged) oder ebenfalls Auswirkungen auf andere Komponenten hat (S:C für Changed). In CVSSv4 wird dieses eine Attribut in die Subsequent System Impact Metrics übernommen. Dort kommen nun zusätzlich die Attribute SC (Confidentiality), SI (Integrity) und SA (Availability) zum Tragen:

The Impact metrics reflect the direct consequence of a successful exploit, and represent the consequence to the “things that suffer the impact”, which may include impact on the vulnerable system and/or the downstream impact on what is formally called the “subsequent system(s)”.

Das grundsätzliche Problem ist, dass hier ein enormer Ermessensspielraum vorhanden ist, was nun als unterschiedliche Komponente betrachtet werden soll und inwiefern ein Angriff diese tangieren kann. Ein typisches Beispiel dieser Diskussion ist eine Cross Site Scripting-Schwachstelle in einer Webapplikation. Die Webapplikation ist eigentlich das verwundbare System, bei dem eine Schwachstelle (fehlerhafte Eingabeüberprüfung) ausgenutzt wird. Traditionellerweise würde der Impact in VSIM als VC:N/VI:L/VA:N definiert werden. Doch effektiv entfalten kann sich die Schwachstelle (Ausführen des injizierten Script-Codes) nur im Webbrowser, der seinerseits also als Subsequent System verstanden werden kann. Der gleiche Impact-Vektor müsste also mindestens auch in der Form SC:N/SI:L/SA:N übernommen werden.

Doch stimmt das? Schliesslich kann mit einer XSS-Schwachstelle ebenfalls Daten aus dem Browser getragen werden (z.B. Cookies), also gilt es den Vektor mindestens als SC:L/SI:L/SA:N anzupassen. Spätestens wenn der Browser mit administrativen Rechten ausgeführt wird, liesse sich auch darüber diskutieren, dass das Risiko auf SC:H/SI:H/SA:H hochgestuft wird. Der Score würde damit von 6.9 (Medium) auf 7.9 (High) angehoben werden. Ist das wirklich für alle XSS-Angriffe gerechtfertigt? Laut dem Paradigma von CVSS ist immer vom schlimmstmöglichen Szenario auszugehen.

Zudem müssen diese Attribute zwingend ausgefüllt werden. Es sind keine optionalen Attribute, die mit einem Not Defined (X) abgetan werden könnten. Oftmals weiss man jedoch gar nicht, ob und inwiefern die Schwachstelle nun Einfluss auf andere Systeme haben wird. Manchmal auch deswegen, weil es von Konfigurationseinstellungen und individuellen Mechanismen vor Ort abhängt. Deshalb gehören diese Attribute schon fast eher in die Environmental Metrics statt in die Base Metrics.

Unwirksame Supplemental Metrics

Neu gibt es die Supplemental Metrics, die durch den Supplier des Vektors auszufüllen sind. Diese 6 Attribute sind optional, definieren sie nämlich Eigenschaften wie die Anforderungen an Safety (S), ob ein Angriff automatisierbar ist (AU) und wie die Recovery (R) von einem Angriff auszusehen hat.

Diese Attribute sind nicht nur optional, sie sind nur eine zusätzliche Information und üben keinerlei Einfluss auf den Score aus. Nehmen wir einmal mehr das Beispiel der SQL-Injection, die ihrerseits ein Medizinalgerät mit heiklen Patientendaten betrifft. Der neue Gesamtvektor mit seinen zusätzlichen Anforderungen sähe nun wie folgt aus:

CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:L/VI:L/VA:L/SC:N/SI:N/SA:N/S:P/AU:Y/R:A/V:C/RE:H/U:Red

Der Score verharrt unverändert bei 6.9, unabhängig ob nun die Supplemental Metrics ausgefüllt werden oder nicht. Einen solch langen Vektor zu erstellen oder ihn zu verstehen setzt intensive Überlegungen voraus. Dass Provider Urgency (U) als einziges Attribut aller verfügbarer Attribute dann auch nicht als einzelner Buchstabe abgekürzt (z.B. U:R), sondern als ganzes Wort U:Red ausgeschrieben wird, ist hierbei wohl das kleinste Problem.

Threat Metrics als Temp Scores

In CVSSv2 und CVSSv3 wurde zwischen verschiedenen Score-Typen unterschieden. Der sogenannte Base Score beinhaltete alle statischen Informationen zu einer Schwachstelle, die für alle Benutzer und über die Zeit hinweg gleich blieben. Der Temp Score baute darauf auf und berücksichtigte zusätzlich Eigenschaften, die sich über die Zeit hinweg ändern, wie zum Beispiel die Verfügbarkeit von Exploits und Gegenmassnahmen. Und der Environmental Score bezog die individuellen Gegebenheiten je nach Kunde und Umgebung mit ein.

CVSSv4 handhabt das zwar im Prinzip ähnlich: Hier wird der Base Score als CVSS-B und der Environmental Score als CVSS-BE dargestellt. Es gibt zwar auch eine Art Temp Score, der als CVSS-BT dargestellt wird, jedoch einen Grossteil der beliebten Eigenschaften gänzlich vernachlässigt. Er wird enger definiert und als Threat Score gehandelt.

Bis anhin wurden nämlich die Report Confidence (RC), das Remediation Level (RL) und die Exploit Code Maturity (E) im Temp Score verwendet. Bei CVSSv4 wird hingegen nur noch die Exploit Maturity (E) (früher Exploitability) berücksichtigt. Diese sieht die Zustände Not Defined (X), Attacked (A), POC (P) und Unreported (U) vor. Was hier auffällt ist das Ungleichgewicht: Bei POC (P) handelt es sich um den Qualitätszustand eines Exploits und bei Attacked (A) um die bestätigte Handlung von böswilligen Akteuren. Hinzu kommt, dass es in der Regel vom POC (P) zu Attacked (A) nicht lange dauert, denn ein Angreifer mit technischem Verständnis ist in der Regel innert kürzester Zeit in der Lage einen Weaponized Exploit zu entwickeln. Und oftmals ist es halt auch so, dass mit einem POC ein Angriff umgesetzt werden kann. Vielleicht ein bisschen unhandlich und nicht vollständig automatisiert, aber ein Ausnutzen vermag durchaus möglich sein.

Diese Threat Metrics sind generell sehr einseitig, besprechen sie in erster Linie die Qualität bzw. die Aktivitäten auf der Angreiferseite:

This metric measures the likelihood of the vulnerability being attacked, and is based on the current state of exploit techniques, exploit code availability, or active, “in-the-wild” exploitation.

Dies mag für Red Teams interessant sein und Blue Teams zu einem kleinen Teil helfen den aktuellen Stand einzuschätzen. Die Qualität der Veröffentlichung und die Verfügbarkeit von Gegenmassnahmen ist jedoch mindestens so wichtig, um Risiken einschätzen zu können. Dass diese Aspekte einfach ersatzlos verworfen wurden, irritiert.

Hinzu kommt der unliebsame Effekt, dass das Auswählen der Threat Metrics stets einen gravierenden Einfluss auf den Score hat. Bleiben wir bei der SQL-Injection-Schwachstelle:

Hierbei fällt auf, dass der maximale Score von 6.9 erreicht wird, wenn entweder CVSS-B verwendet wird oder CVSS-BT mit der schlechtesten Annahme von Attacked. Es wird in diesem Zusammenhang also vom schlimmstmöglichen ausgegangen, sofern nichts anderes bekannt ist.

In den meisten Fällen ist der Zustand aber nicht Not Defined (X) sondern Unreported (U). Es sind also weder Exploits noch Angriffe bekannt. Hier wird aber plötzlich nicht mehr vom schlimmstmöglichen ausgegangen, sondern der Score auf ein 2.7 (Medium) heruntergestuft. Dies entspricht einer totalen Minderung von 4.2 Punkten (60.86%). Ich zweifle daran, dass dieser Widerspruch so gewollt sein kann. Es sei denn, man wollte den Kunden ein Werkzeug in die Hand geben, um die meisten Schwachstellen unkompliziert herunterstufen und damit marginalisieren zu können.

Dokumentation und Beispielimplementierung

In ihren Grundzügen, was Struktur und Ausrichtung betrifft, unterscheiden sich die Dokumentationen der verschiedenen CVSS-Versionen nicht voneinander. Was aber auffällt ist, dass bei CVSSv4 auf die Offenlegung und Darstellung der zugrundeliegenden mathematischen Formeln wie bei CVSSv3 verzichtet wird.

Stattdessen wird auf GitHub nur eine Beispielimplementierung in Javascript zur Verfügung gestellt. Es ist jene Umsetzung, die auch auf dem offiziellen CVSS v4.0 Calculator Verwendung findet. Diese weist einige Sonderheiten auf, die auf einen eigenwilligen Programmierstil zurückzuführen sind (z.B. werden oft komplexe negierte else if-Ausdrücke verwendet, obwohl ein simpler else-Ausdruck genauso möglich gewesen wäre; inkrementierende for-Schleifen werden nachvollziehbaren .forEach-Konstrukten vorgezogen).

Das Portieren und Umsetzen einer eigenen Implementierung gestaltet sich deshalb in CVSSv4 schwieriger, da man nicht auf eine neutrale Darstellung der Funktionsweise zurückgreifen kann. So gibt es auch bis heute nur sehr wenige Portierungen in anderen Sprachen. ZUdem gibt es scheinbar Abweichungen, wenn es um das Runden von Werten geht, was im schlimmsten Fall dazu führen kann, dass je nach Implementierung ein anderer Score generiert wird.

Fazit

CVSSv4 ist komplex und kompliziert. Das Einführen von zusätzlichen Attributen sollte wohl der Granularität dienlich sein und mit ihr die Präzision erhöhen. Doch zuerst hätte man sich die Frage stellen müssen, ob eine solche überhaupt wünschenswert oder gar erforderlich ist. Die meisten Nutzer von CVSS interessieren sich entweder sowieso nur für die Scores, ohne die Vektoren im Detail anzuschauen.

Oder sie lieben es unendlich lange darüber zu philosophieren, welcher Vektor nun wirklich das richtigste Szenario wiederzuspiegeln in der Lage ist:

[I]t is likely that many different types of individuals will be assessing vulnerabilities (e.g., software vendors, vulnerability bulletin analysts, security product vendors), however, note that CVSS assessment is intended to be agnostic to the individual and their organization.

Diese Diskussion kann sich nun auch über die verschiedenen Generationen von CVSS erstrecken, denn die zu Beginn ins Feld geführte SQL-Injection ist je nachdem eine 7.5 (CVSSv2), 7.3 (CVSSv3) oder 6.9 (CVSSv4). Die Genauigkeit von CVSS ist also generell nicht gegeben, weshalb ein Mehr an Komplexität nur über die Probleme hinwegtäuscht und zusätzliche Nachteile mit sich bringt.

Das Verkümmern der Temp Scores ist zudem eine absolute Fehlentscheidung. Ein Grossteil der CVSS-Anwender – gerade Administratoren und Blue Teams – orientiert sich massgeblich an diesen Attributen. Durch das Weglassen eben dieser wird die Nützlichkeit der Metrik für diese Nutzergruppe in absoluter Weise gemindert. Aus diesem Grund kann ich mir nicht vorstellen, dass sich CVSSv4 bei der breiten Masse durchsetzen können wird. Es müsste eine zusätzliche Metrik eingeführt werden, um das neu mitgebrachte Unvermögen wieder kompensieren zu können.

Ich bin der Meinung, dass sich CVSSv4 nicht reparieren lässt. Zwar werden voraussichtlich einige kleinere Mängel in einer Version 4.1 adressiert werden. Es sind jedoch bei der Ausarbeitung einige grundlegende Entscheidungen gefällt worden, deren Verbesserung ein komplettes Überarbeiten der Metrik erzwingen würde. Die Kompatibilität eines Minor-Releases würde dadurch gänzlich verloren gehen. Es bleibt also zu hoffen, dass mit CVSSv5 alles besser wird. Ein bisschen weniger Komplexität täte dem Ansatz definitiv wieder gut.

Die ersten Newsartikel und Beiträge zu CVSSv4 waren alle sehr optimistisch. Als aufmerksamer Leser hat man jedoch schnell gemerkt, dass die Autoren sich nicht mit den Details auseinandergesetzt oder die neue Metrik (produktiv) eingesetzt haben. Ich kann mir nur vorstellen, dass sich CVSSv4 durchsetzen kann, wenn auch weiterhin die Details der Metrik vernachlässigt und sich blindlings auf die Scores verlassen wird. Ich muss gestehen, dass das eine meiner grössten Befürchtungen ist. Denn in diesem Fall würde undankbarerweise CVSS zu einer Farce verkommen.

Über den Autor

Marc Ruef ist seit Ende der 1990er Jahre im Cybersecurity-Bereich aktiv. Er hat vor allem im deutschsprachigen Raum aufgrund der Vielzahl durch ihn veröffentlichten Fachpublikationen und Bücher – dazu gehört besonders Die Kunst des Penetration Testing – Bekanntheit erlangt. Er ist Dozent an verschiedenen Fakultäten, darunter ETH, HWZ, HSLU und IKF. (ORCID 0000-0002-1328-6357)

Links

• https://github.com/FIRSTdotorg/cvss-v4-calculator
• https://pubmed.ncbi.nlm.nih.gov/21509181/
• https://twitter.com/mruef/status/1709496828339589536
• https://twitter.com/mruef/status/1709496829795025262
• https://twitter.com/mruef/status/1709496832798138513
• https://twitter.com/mruef/status/1709496835688026182
• https://vuldb.com/de/
• https://vuldb.com/de/?cvssv2
• https://vuldb.com/de/?cvssv3
• https://www.first.org/cvss
• https://www.first.org/cvss/calculator/v4-0
• https://www.first.org/cvss/v2/guide
• https://www.first.org/cvss/v3-1/
• https://www.first.org/cvss/v3.1/specification-document#CVSS-v3-1-Equations
• https://www.first.org/cvss/v4-0/
• https://www.first.org/cvss/v4-0/specification-document
• https://www.first.org/cvss/v4.0/specification-document#Assessment
• https://www.first.org/cvss/v4.0/specification-document#Exploit-Maturity-E
• https://www.first.org/cvss/v4.0/specification-document#Metrics