Was ist neu bei CVSS 4.0?
8. November 2023
0 Min. LesezeitIn diesem Blogbeitrag stellen wir Snyks Einschätzung des neuen Frameworks zur Bewertung von Schwachstellen vor: CVSS 4.0, veröffentlicht am 1. November 2023.
Warum war das notwendig?
Das überarbeitete Framework ist eine natürliche Weiterentwicklung angesichts der zunehmenden Cybersecurity-Schwachstellen und soll Schwachstellen der bisherigen Methodik beheben. Seit seiner Veröffentlichung im Jahr 2016 hat sich CVSS 3 als robustes Bewertungsinstrument bewährt, mit dem Fachleute die potenziellen Auswirkungen und den Risikograd verschiedener Schwachstellen ermitteln können. So unterstützt es Unternehmen und Einzelpersonen dabei, sich besser vor Cyberbedrohungen zu schützen.
Sieben Jahre später ist CVSS 4.0 die nächste Iteration. Sie soll eine präzisere Abstufung ermöglichen und die Bewertungsmethodik weiter verfeinern, damit sie der sich wandelnden Dynamik von Cybersecurity-Bedrohungen und der digitalen Welt besser gerecht wird.
Was ändert sich?
Sehen wir uns die Änderungen an, die mit einem technischen Vergleich der Frameworks 3.1 und 4.0 deutlich werden.
Hinweis: Die Schweregrade und Wertebereiche (Niedrig, Mittel, Hoch und Kritisch) für die einzelnen qualitativen Schweregrade bleiben unverändert.
Parameter Attack Vector
Der neue Parameter Attack Vector erfüllt denselben Zweck wie bisher. Er umfasst einige semantische Änderungen, die für eine umfassendere Spezifikation sorgen sollen (z. B. Komponente statt System oder physisch statt Nähe).
Wir erwarten daher keine Änderungen bei der Verwendung dieses Parameters zur Bewertung von Schwachstellen mit CVSS 4.0.
Parameter Attack Complexity
Der Parameter Attack Complexity aus CVSS 3.1 wird in Attack Complexity und Attack Requirements aufgeteilt, um eine präzisere Abstufung zu ermöglichen.
Der neue Parameter Attack Complexity ist für hochspezialisierte Angriffe vorgesehen, bei denen „Sicherheitstechniken umgangen oder ausgehebelt werden“.
Attack Requirements deckt dagegen Fälle ab, in denen eine erfolgreiche Ausnutzung „vom Vorhandensein bestimmter Bereitstellungs- und Ausführungsbedingungen des anfälligen Systems abhängt, die den Angriff ermöglichen“.
Der wesentliche Unterschied zwischen Attack Complexity und Attack Requirements liegt im Zweck der jeweiligen Bedingungen, die den Angriff ermöglichen. Laut Spezifikationsdokument erfasst Attack Requirements ausschließlich Szenarien, die NICHT vom neuen Parameter Attack Complexity abgedeckt werden (d. h. dieser Parameter ist nicht für Szenarien vorgesehen, in denen Techniken zur Abwehr von Exploits umgangen werden).
Im Open-Source-Ökosystem erwarten wir eine geringere Nutzung dieses Parameters, da Attack Complexity nur bei hochspezialisierten Angriffen zum Einsatz kommt. Attack Requirements wird dagegen vermutlich häufiger verwendet, da dieser Parameter Bedingungen erfasst, die „als natürliche Folge der Bereitstellung und Ausführung des anfälligen Systems entstehen“.
Parameter Privileges Required
Der neue Parameter Privileges Required umfasst lediglich kleinere Änderungen, die für mehr Klarheit und eine präzisere Formulierung sorgen sollen. Auch der Wert des Parameters bleibt unverändert.
Wir gehen davon aus, dass sich die Verwendung dieses Parameters bei der Bewertung von Schwachstellen nicht ändern wird.
Parameter User Interaction
Im Spezifikationsdokument zu CVSS 4.0 sind deutliche Änderungen am neuen Parameter User Interaction zu erkennen – genauer gesagt an seinen möglichen Werten. Das ermöglicht eine präzisere Bewertung der Angriffsbedingungen.
Für User Interaction gibt es drei mögliche Werte (statt zwei in CVSS 3.1).
None — Die Definition wurde präzisiert und hebt den menschlichen Benutzer stärker hervor. Dieser Wert kommt daher infrage, wenn „das anfällige System ohne Interaktion eines menschlichen Benutzers außer dem Angreifer ausgenutzt werden kann“.
Passive — Dieser Wert ist für Angriffe vorgesehen, die durch unbeabsichtigte Handlungen des Opfers ausgeführt werden können.
Active — Im Gegensatz zum vorherigen Fall wird dieser Wert verwendet, wenn der Angriff voraussetzt, dass das Opfer „bestimmte bewusste Interaktionen mit dem anfälligen System und der Payload des Angreifers ausführt“. Alternativ können die „Interaktionen des Opfers Schutzmechanismen aktiv aushebeln und so die Schwachstelle ausnutzbar machen“.
Diese Ergänzungen ermöglichen eine bessere Verteilung der Schweregrade von Schwachstellen, indem sie die bisherigen Werte für User Interaction ersetzen. Die Verwendung dieses Parameters bei der Bewertung von Schwachstellen wird sich daher ändern.
CIA-Triade
Abgesehen von kleineren Umformulierungen, die für einheitliche Definitionen im gesamten Spezifikationsdokument sorgen sollen, gibt es keine nennenswerten Änderungen an der CIA-Triade.
Die Verwendung dieser Parameter wird sich wahrscheinlich nicht ändern.
Parameter Scope
Der Parameter Scope wird durch Subsequent System Impact Metrics ersetzt. Dadurch wird eine gleichmäßigere Verteilung der Schweregrade ermöglicht und die Auswirkungen einer Schwachstelle lassen sich präziser bewerten.
Mit dieser Änderung wird nicht nur die Änderung des Scopes parametrisiert, sondern auch werden die Auswirkungen auf das nachgelagerte System genauer erfasst.
Der neue Ansatz verändert den Prozess zur Bewertung von Schwachstellen und ermöglicht gleichzeitig eine präzisere Beurteilung der Auswirkungen.
Threat Metrics
Auch bei den Threat Metrics (früher Temporal Score) gibt es deutliche Änderungen. Wir sehen uns jedoch nur Exploit Code Maturity an. Dieser Parameter wird in Exploit Maturity umbenannt und umfasst vier mögliche Werte statt fünf. Der Wert Functional entfällt. Die Definitionen der Werte für Exploit Maturity wurden verbessert und enthalten nun konkrete Anforderungen, die erfüllt sein müssen, um die jeweilige Einstufung zu rechtfertigen.
Not Defined — Dieser Wert ist zu verwenden, wenn „keine zuverlässigen Threat-Intelligence-Informationen vorliegen, anhand derer sich die Eigenschaften der Exploit Maturity bestimmen lassen“.
Attacked (zuvor High) — Dieser Wert kommt infrage, wenn 1) Angriffe gemeldet wurden oder 2) der Exploit einen Reifegrad erreicht hat, der seine Integration in verschiedene Lösungen ermöglicht, beispielsweise in Exploit-Kits, die das Ausnutzen von Schwachstellen vereinfachen und automatisieren sollen.
PoC — Dieser Wert ist zu verwenden, wenn eine der folgenden Bedingungen zutrifft:
„Ein Proof of Concept ist öffentlich verfügbar.“
„Es sind keine Versuche bekannt, diese Schwachstelle auszunutzen.“
„Es sind keine öffentlich verfügbaren Lösungen bekannt, die Versuche zum Ausnutzen der Schwachstelle vereinfachen.“
Unreported — weder PoC noch Attacked, aber nicht gleichzusetzen mit Not Defined (für Fälle, in denen Threat-Intelligence-Informationen verfügbar sind).
Diese Änderungen wirken sich auf die Verwendung des Parameters Exploit Maturity aus.
Wie wirken sich die Änderungen auf Benutzer aus?
Ergänzend zu den im vorherigen Abschnitt vorgestellten Änderungen sehen wir uns drei Beispiele für Schwachstellen an und versuchen, sie mit CVSS 4.0 zu bewerten. Dabei erläutern wir unser Vorgehen.
Remote Code Execution in microsoft.chakracore, Version 1.10.1
CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:H/I:H/A:H — 7.5 Hoch
CVSS:4.0/AV:N/AC:H/AT:N/PR:N/UI:P/VC:H/VI:H/VA:N/SC:L/SI:L/SA:L — 7.6 Hoch
Der Angriff kann über das Netzwerk ausgeführt werden, daher AV:N. Laut Spezifikation ist AC:H zu verwenden, wenn Schutzmaßnahmen wie ASLR umgangen werden müssen. Aufgrund der verfügbaren Informationen zu dieser Schwachstelle gehen wir davon aus, dass dies hier zutrifft. Es gibt keine Hinweise auf erforderliche geringe oder hohe Berechtigungen, daher PR:N. Eine erfolgreiche Ausnutzung setzt die Beteiligung eines weiteren menschlichen Benutzers voraus. Es gibt jedoch keine ausreichenden Belege dafür, dass dieser aktiv mit der Payload des Angreifers interagieren muss, daher UI:P. Da „ein Angreifer, der die Schwachstelle erfolgreich ausnutzt, die Kontrolle über ein betroffenes System übernehmen könnte“, sind Vertraulichkeit und Integrität betroffen. Daher gelten VC:H, VI:H und VA:N. Wir gehen davon aus, dass sich die Auswirkungen auch auf das nachgelagerte System erstrecken, in diesem Fall auf den Computer des Opfers. Die Auswirkungen hängen jedoch davon ab, über welche Berechtigungen der Angreifer auf dem Computer des Opfers verfügt. Daher gelten SC:L, SI:L und SA:L.
Remote Code Execution in ipython, Version 8.10.0
CVSS:3.1/AV:L/AC:H/PR:L/UI:R/S:U/C:L/I:L/A:L — 4.2 Mittel
CVSS:4.0/AV:L/AC:L/AT:P/PR:L/UI:A/VC:N/VI:N/VA:N/SC:L/SI:L/SA:N — 1.0 Niedrig
Aufgrund des Verwendungszwecks des Pakets kann der Angriff nur lokal ausgeführt werden, daher AV:L. Eine erfolgreiche Ausnutzung erfordert keine Umgehung von Sicherheitsmechanismen, hängt aber vom Betriebssystem und einer bestimmten Bereitstellungskonfiguration ab (die Bibliothek `ctypes`, die bei Python-Installationen standardmäßig enthalten ist, muss deaktiviert sein). Dieses Szenario erfüllt die Kriterien für AC:L und AT:P. Der Angreifer benötigt außerdem Zugriff auf die lokale Umgebung, daher PR:L. Das Opfer muss aktiv und bewusst mit der Payload des Angreifers interagieren, indem es die anfällige Funktion unter „Windows in einer Python-Umgebung, in der `ctypes` nicht verfügbar ist“ aufruft. Daher gilt UI:A. Aufgrund der verfügbaren Informationen zu dieser Schwachstelle gehen wir davon aus, dass die CIA-Triade im anfälligen System nicht betroffen ist, sondern nur im nachgelagerten System. Das liegt daran, dass die Befehle auf dem Host-System ausgeführt werden und die Python-Installation selbst nicht direkt betroffen ist. Die Shell-Befehle sind außerdem „auf den Umfang des aktuellen Prozesses beschränkt“, was SC:L und SI:L entspricht. Da es keine Hinweise darauf gibt, dass die Verfügbarkeit des nachgelagerten Systems beeinträchtigt wird, gilt SA:N.
Cross-Site-Scripting in org.jenkins-ci.plugins:rundeck, Version 3.6.11
CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:C/C:L/I:L/A:N — 5.4 Mittel
CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:P/VC:N/VI:N/VA:N/SC:L/SI:L/SA:N — 5.1 Mittel
Der Angriff kann über das Netzwerk ausgeführt werden. Für eine erfolgreiche Ausnutzung müssen weder „Techniken zur Abwehr von Exploits“ umgangen noch besondere Bereitstellungskonfigurationen verwendet werden. Daher gelten AV:N, AC:L und AT:N. Der Angreifer benötigt jedoch ein aktives Konto, um den Exploit auszuführen. Da es sich um ein gespeichertes XSS handelt, muss das Opfer keine bestimmten Aktionen mit der Payload ausführen. Daher gilt UI:P. Die Auswirkungen betreffen das nachgelagerte System, da der Angreifer Daten im Browser des Opfers lesen oder ändern kann. Daraus ergeben sich die Werte VC:N/VI:N/VA:N/SC:L/SI:L/SA:N.
Offizielle Beispiele wurden von first.org veröffentlicht.
Allgemeine Schlussfolgerungen
Schon jetzt ist erkennbar, dass CVSS 4.0 Verbesserungen bei der Bewertung von Schwachstellen bietet. Benutzer können die Auswirkungen auf die Sicherheit präziser bestimmen. Das ermöglicht eine bessere Priorisierung von Sicherheitsproblemen. Bei der Verteilung der Schweregrade ist aufgrund der genaueren Abstufungen von CVSS 4.0 eine ausgewogenere Verteilung zu erwarten. So wird verhindert, dass sich zu viele Schwachstellen in einem bestimmten Schweregradbereich konzentrieren. Außerdem rechnen wir mit weniger Schwachstellen mit einem erhöhten Schweregrad, zumal CVSS 4.0 „die Wertebereiche für die einzelnen qualitativen Schweregrade unverändert lässt“.
Wann ist CVSS v4.0 verfügbar?
Seit dem 18. Juni weist das Snyk Security Team allen neuen Sicherheitslücken, die von Snyk Open Source erkannt werden, einen CVSS-v4.0-Wert zu. Neben der Bewertung neuer Probleme anhand von CVSS v4.0 wird Snyk die neuen Vektorattribute schrittweise in die Workflows der verschiedenen Produktlinien integrieren und die Möglichkeiten zur direkten Nutzung dieser Informationen entsprechend aktualisieren.
Wenn Sie mehr darüber erfahren möchten, wie Sie das CVSS-Framework zur Bewertung des Schweregrads von Schwachstellen einsetzen, lesen Sie unseren Blogbeitrag „Sicherheitslücken bewerten: die Grundlagen“.
Referenzen:
CVSS 4.0:
https://www.first.org/cvss/v4.0/examples