Common Vulnerability Scoring System (CVSS)

Durch unsere Arbeit beschäftigen wir uns sehr oft mit Schwachstellen verschiedenster Art.

Bei jeder erstellten Massnahmenliste werden wir mit der Frage konfrontiert: Wie schätzen wir diese Massnahme oder Schwachstelle ein? “Hoch”? Oder eher “Mittel”? Oder eher “Gering”?

Doch Schwachstelle ist nicht gleich Schwachstelle, da gibt es verschiedene Kaliber und Charakterzüge. Die Ausnutzung einer Schwachstelle kann beispielsweise hoch komplex oder sehr simpel sein (beispielsweise bei der Verwendung von Standard-Kennwörtern). Für die Ausnutzung mancher Schwachstellen müssen sehr spezifische Bedingungen gegeben sein (z.B. muss ein User mit einer bestimmten Berechtigung vorhanden sein) andere sind wiederum universell ausnutzbar (z.B. Schwachstellen, welche ohne Berechtigung von extern ausgenutzt werden können). Eine Schwachstelle kann bei einer erfolgreichen Ausnutzung durch einen Angreifer auch entweder einen hohen Schaden mit sich bringen (z.B. Ausführung von beliebigen Code auf dem System) oder einen geringen Schaden mit sich bringen (beispielsweise die Preisgabe von nicht sensiblen Informationen).

Da sich unterschiedliche Schwachstelle in ihren Voraussetzungen und Charakteristiken sehr stark voneinander unterscheiden können, erschwert dies oft die Einschätzung und vor allem die Vergleichbarkeit zwischen Schwachstellen. Welches ist die wichtigere von zwei Schwachstellen? Welches ist die riskantere? Welche soll bei einer Behebung priorisiert werden? Doch genau zu dieser Problematik gibt es etablierte Lösungen.

Wie kann man Schwachstellen vergleichen?

Damit man Schwachstellen vergleichen und vor allem in der Umsetzung und Behebung priorisieren kann, erstellt man am besten einen Zahlenwert, einen sogenannten Score. Damit diese Scores auch vergleichbar sind, muss jede Schwachstelle nach denselben Kriterien bewertet werden können. Es braucht also eine Art Formel oder System. Theoretisch kann jeder selbst ein eigenes Scoring System erstellen. Dies ist aber nicht wirklich produktiv, denn es gibt bereits bekannte und weit verbreitete Frameworks und Scoring Systeme, welche weitreichend verwendet und stetig weiterentwickelt werden.

In diesem Blog möchte ich etwas genauer auf eines dieser Scoring Systeme eingehen und aufzeigen, wie die Berechnung eines solchen Scores genau aussieht und welche Aspekte den Score einer Schwachstelle beeinflussen.

Was ist CVSS?

CVSS steht für Common Vulnerability Scoring System und ist ein Framework, welches seit dem Jahr 2005 durch das Forum of Incident Response and Security Teams (FIRST) betreut und entwickelt wird. Die erste Ausgabe von CVSS entstand 2005 mit der initialen CVSSv1. Über die Jahren wurden neue Versionen veröffentlicht. Die aktuellste Version (Stand Februar 2026) ist CVSSv4, welche im November 2023 veröffentlicht wurde.

Das Ziel war es, eine einheitliche metrische Einschätzung von Schwachstellen zu ermöglichen, welche aufgrund mathematischer Formeln berechnet werden können. Ein CVSS Score besteht aus einer Zahl von 0.0 – 10.0 und erlaubt es den Schweregrad einer Schwachstelle in Kategorien wie “Critical”, “High”, “Medium” und “Low” einzuteilen.

CVSS Score	Rating
0.00	None
0.1 – 3.9	Low
4.0 – 6.9	Medium
7.0 – 8.9	High
9.0 – 10.0	Critical

Wie setzt sich ein CVSS Score zusammen?

Die Berechnung eines CVSS Scores ist je nach CVSS-Version unterschiedlich. Da es sich bei Version 4 um die aktuelle Version aus dem Jahr 2023 handelt, möchte ich mich für diesen Blog auf diese Version beschränken. Der eigentliche Score, welcher durch CVSSv4 berechnet wird, setzt sich aus 4 metrischen Gruppen zusammen: Base Metric Group, Threat Metric Group, Environmental Metric Group und Supplemental Metric Group. Jede dieser Gruppen enthält wiederum einzelne Metriken, welche für einen Score einzeln bewertet werden müssen.

Zusammensetzung des CVSSv4 Score in 4 Gruppen [2]

Grob zusammengefasst kann man diese 4 Gruppen folgendermassen beschreiben:

Die Base Metric Gruppe enthält Metriken, welche die grundlegenden Charaktereigenschaften des verwundbaren Systems beschreiben. Wie einfach ist die Schwachstelle auszunutzen (Exploitability)? Welche Konsequenzen entstehen durch eine erfolgreiche Ausnutzung (Impact)?
Die Threat Metric Gruppe beschreibt Charakteristiken, welche sich mit der Zeit ändern können. So beispielsweise, ob es öffentliche Exploits zur Schwachstelle gibt. Dies kann den Score einer Schwachstelle auch nachträglich noch ändern.
Die Environmental Metric Gruppe enthält Metriken, welche zusätzlich die spezifische Umgebung von einzelnen Unternehmen miteinbeziehen. Gibt es Faktoren oder Sicherheitsvorkehrungen in unserer Umgebung, welche die Folgen einer erfolgreichen Ausnutzung der Schwachstelle abmildern?
Die Supplemental Metric Gruppe enthält zusätzliche Metriken, welche weitere extrinsische Eigenschaften der Schwachstelle messen.

Für einen CVSS Score müssen mindestens die Metriken aus der Base Metric Gruppe evaluiert werden. Sind nur diese gegeben, spricht man auch von einem CVSS-B Score. Zusätzlich können optional auch die drei weiteren Gruppen evaluiert und miteinbezogen werden. So bezeichnet ein CVSS-BT beispielsweise ein CVSS Base Score mit zusätzlicher Bewertung der Threat Metriken. Einfachheitshalber möchte ich im Rahmen dieses Blogs nur auf die Base Metric Gruppe beschränken und die einzelnen erforderlichen Metriken dieser Gruppe genauer betrachten.

Wichtig zu beachten ist, dass sich der Base Score (CVSS-B) auf den intrinsischen Schweregrad (severity) der Schwachstelle bezieht, nicht aber auf das Risiko, welches diese Schwachstelle für ein einzelnes Unternehmen darstellt.

“The Common Vulnerability Scoring System (CVSS) is a method used to supply a qualitative measure of severity [of a vulnerability]. CVSS is not a measure of risk.”

“Das Common Vulnerability Scoring System (CVSS) ist eine Methode zur qualitativen Bewertung des Schweregrads [einer Schwachstelle]. CVSS ist kein Mass für Risiko.”

– NIST [1]

Der Unterschied zwischen Schweregrad und Risiko ist ein wichtiger. Schweregrad ist die Antwort auf die Frage “wie schlimm wäre es, wenn diese Schwachstelle ausgenutzt würde?” und Risiko, definiert als Wahrscheinlichkeit x Impact ist die Antwort auf die Frage “Wie hoch ist die Wahrscheinlichkeit, dass mein Unternehmen von dieser Schwachstelle betroffen ist und wie gross wären die Auswirkungen?”. Risiko ist immer Kontext abhängig, während der Schweregrad einer Schwachstelle Kontext unabhängig ist. Zwei gleiche Systeme mit der gleichen Schwachstelle können also zwei verschiedene Risiken mit sich bringen, wenn beispielsweise ein System ohne Authentifizierung aus dem Internet erreichbar ist und produktive Daten enthält (hohes Risiko) und das andere nur intern mit Authentifizierung erreichbar ist.

Wie berechnet man einen CVSS Base Score
(CVSS-B)?

Um einen CVSS-B Score zu berechnen, müssen die Metriken in der Base Metrics Gruppe erfasst und bewertet werden. Schauen wir uns diese also etwas genauer an. In den meisten Fällen macht es Sinn, dass die Angaben zu den Base Metriken durch den Hersteller der Applikation oder des verwundbaren Systems zusammengestellt werden. Dies kommt daher, dass die Hersteller oder Entwickler eine viel detailliertere Sicht auf ihre eigenen Systeme/Applikationen haben als Externe.

Einfachheitshalber habe ich hier die verschiedenen Metriken zusammengefasst und diese etwas umgangssprachlicher ins Deutsche übersetzt. Die tatsächlichen Beschreibungen sind sehr formell definiert und würden diesen Blog noch trockener machen, als er bereits ist. Deshalb hier ein kurzer Hinweise, dass die Umformulierungen nur der Veranschaulichung dienen und nicht für eine echte Einschätzung einer Schwachstelle genutzt werden sollten. Für eine exakte Definition und Beschreibung der einzelnen Werte, sollte die offizielle Dokumentation (https://www.first.org/cvss/v4.0/specification-document) beachtet werden.

Exploitability Metric	Beschreibung	Mögliche Werte
Attack Vector (AV)	Wie greift ein Angreifer bei der Ausnutzung der Schwachstelle auf das verwundbare System zu?	Network (N): Ein Angreifer kann über das Netzwerk auch von extern/remote auf das verwundbare System zugreifen. Adjacent (A): Ein Angreifer kann über das Netzwerk auf Protokoll-Ebene von einem angrenzenden System auf das verwundbare System zugreifen (zum Beispiel über WiFi oder über das gleiche Subnetz). Local (L): Ein Angreifer kann nicht über das Netzwerk auf das verwundbare System zugreifen, sondern muss lokal auf das Gerät zugreifen können (zum Beispiel durch eine Verbindung auf das lokale System durch eine SSH-Verbindung). Physical (P): Ein Angreifer braucht physischen Zugriff auf das verwundbare Gerät.
Attack Complexity (AC)	Wie komplex ist eine erfolgreiche Ausnutzung der Schwachstelle?	Low (L): Es sind keine komplexen Aktionen erforderlich. Eine Ausnutzung kann zuverlässig wiederholt werden. High (H): Eine erfolgreiche Ausnutzung erfordert oft mehrere komplexe und bestimmte system-spezifische Aktionen, um vorhandene Sicherheitsvorkehrungen zu umgehen (zum Beispiel Umgehung von Address Space Layout Randomization bei einer Stack Overflow Schwachstelle).
Attack Requirements (AT)	Müssen bestimmte system-relevante Voraussetzungen gegeben sein für eine erfolgreiche Ausnutzung?	None (N): Es müssen keine weiteren Voraussetzungen gegeben sein. Present (P): Bestimmte Konfigurationen oder zeit-basierte Voraussetzungen müssen auf dem verwundbaren System gegeben sein für eine erfolgreiche Ausnutzung der Schwachstelle. Ein Angreifer muss zum Beispiel auf den richtigen Zeitpunkt warten.
Privileges Required (PR)	Welches Level an Berechtigung muss ein Angreifer für eine Ausnutzung der Schwachstelle haben?	None (N): Ein Angreifer kann die Schwachstelle unauthentifiziert ausnutzen. Low (L): Ein Angreifer muss über geringe oder limitierte Berechtigungen für eine Ausnutzung verfügen. High (H): Ein Angreifer benötigten hohe oder administrative Berechtigungen auf dem verwundbaren System.
User Interaction (UI)	Ist für eine Ausnutzung der Schwachstelle die Teilnahme von weiteren Benutzern (Angreifer ausgeschlossen) erforderlich?	None (N): Das verwundbare System kann ohne weitere Benutzerinteraktion durch die Schwachstelle ausgenutzt werden. Passive (P): Eine erfolgreiche Ausnutzung erfordert begrenzte und oft nur unbewusste Interaktion von anderen Benutzern (z.B. Besuch einer modifizierten Unterseite einer Webanwendung, welche ein gespeichertes Cross-Site-Scripting Script enthält). Active (A): Eine erfolgreiche Ausnutzung erfordert spezifische und bewusste Aktionen eines Benutzers, welche teils auch vorhandene Sicherheitsmassnahmen und Warnungen umgehen (z.B. Import einer bestimmten Datei an einen bestimmten Ort trotz Warnhinweisen)

Exploitability Metric

Beschreibung

Mögliche Werte

Attack Vector (AV)

Wie greift ein Angreifer bei der Ausnutzung der Schwachstelle auf das verwundbare System zu?

Network (N): Ein Angreifer kann über das Netzwerk auch von extern/remote auf das verwundbare System zugreifen.
Adjacent (A): Ein Angreifer kann über das Netzwerk auf Protokoll-Ebene von einem angrenzenden System auf das verwundbare System zugreifen (zum Beispiel über WiFi oder über das gleiche Subnetz).
Local (L): Ein Angreifer kann nicht über das Netzwerk auf das verwundbare System zugreifen, sondern muss lokal auf das Gerät zugreifen können (zum Beispiel durch eine Verbindung auf das lokale System durch eine SSH-Verbindung).
Physical (P): Ein Angreifer braucht physischen Zugriff auf das verwundbare Gerät.

Attack Complexity (AC)

Wie komplex ist eine erfolgreiche Ausnutzung der Schwachstelle?

Low (L): Es sind keine komplexen Aktionen erforderlich. Eine Ausnutzung kann zuverlässig wiederholt werden.
High (H): Eine erfolgreiche Ausnutzung erfordert oft mehrere komplexe und bestimmte system-spezifische Aktionen, um vorhandene Sicherheitsvorkehrungen zu umgehen (zum Beispiel Umgehung von Address Space Layout Randomization bei einer Stack Overflow Schwachstelle).

Attack Requirements (AT)

Müssen bestimmte system-relevante Voraussetzungen gegeben sein für eine erfolgreiche Ausnutzung?

None (N): Es müssen keine weiteren Voraussetzungen gegeben sein.
Present (P): Bestimmte Konfigurationen oder zeit-basierte Voraussetzungen müssen auf dem verwundbaren System gegeben sein für eine erfolgreiche Ausnutzung der Schwachstelle. Ein Angreifer muss zum Beispiel auf den richtigen Zeitpunkt warten.

Privileges Required (PR)

Welches Level an Berechtigung muss ein Angreifer für eine Ausnutzung der Schwachstelle haben?

None (N): Ein Angreifer kann die Schwachstelle unauthentifiziert ausnutzen.
Low (L): Ein Angreifer muss über geringe oder limitierte Berechtigungen für eine Ausnutzung verfügen.
High (H): Ein Angreifer benötigten hohe oder administrative Berechtigungen auf dem verwundbaren System.

User Interaction (UI)

Ist für eine Ausnutzung der Schwachstelle die Teilnahme von weiteren Benutzern (Angreifer ausgeschlossen) erforderlich?

None (N): Das verwundbare System kann ohne weitere Benutzerinteraktion durch die Schwachstelle ausgenutzt werden.
Passive (P): Eine erfolgreiche Ausnutzung erfordert begrenzte und oft nur unbewusste Interaktion von anderen Benutzern (z.B. Besuch einer modifizierten Unterseite einer Webanwendung, welche ein gespeichertes Cross-Site-Scripting Script enthält).
Active (A): Eine erfolgreiche Ausnutzung erfordert spezifische und bewusste Aktionen eines Benutzers, welche teils auch vorhandene Sicherheitsmassnahmen und Warnungen umgehen (z.B. Import einer bestimmten Datei an einen bestimmten Ort trotz Warnhinweisen)

Neben den Exploitability Metriken müssen auch die Impact Metriken bewertet werden. Hier muss der Einfluss der Schwachstelle auf die altbekannte CIA-Triad (Confidentiality/Vertraulichkeit, Integrity/Integrität und Availability/Verfügbarkeit) beachtet und gemessen werden. Als kurze Wiederholung sind das folgende:

Confidentiality/Vertraulichkeit: Auf ein System können nur Personen zugreifen, denen der Zugriff ausdrücklich gestattet wurde.
Integrity/Integrität: Das System speichert nur die korrekte (nicht manipulierte) Informationen.
Availability/Verfügbarkeit: Die Benutzer, die auf das System zugreifen sollen, können dies tun.

Der Impact auf diese CIA-Triad muss sowohl jeweils für das verwundbare System selbst, wie auch jeweils für die sogenannten “subsequent”, also nachfolgenden oder abhängigen Systeme, beantwortet werden. Somit werde sämtliche Systeme bewertet, welche durch die erfolgreiche Ausnutzung der Schwachstelle beeinträchtigt werden können. Wenn es einem Angreifer beispielsweise gelingt durch eine Schwachstelle in einer virtuellen Maschine aus dieser auszubrechen, wäre das Host-System und eventuelle weitere virtuelle Maschinen, welche auf dem Host zu finden sind als nachfolgende Systeme betroffen.

Impact Metric	Beschreibung	Mögliche Werte
Confidentiality Impact to the Vulnerable System / Subsequent System (VC/SC)	Welchen Einfluss hat eine erfolgreiche Ausnutzung der Schwachstelle auf die Vertraulichkeit des verwundbaren Systems sowie auf die nachfolgenden Systeme?	High (H): Eine erfolgreiche Ausnutzung der Schwachstelle führt zu einem totalen Verlust der Vertraulichkeit. Ein Angreifer hat Zugriff auf sämtliche Daten und kann diese auslesen. Low (L): Eine erfolgreiche Ausnutzung der Schwachstelle führt zu einem gewissen Verlust der Vertraulichkeit. Ein Angreifer hat Zugriff auf gewisse Daten, kann aber nicht steuern welche. None (N): Kein Verlust der Vertraulichkeit.
Integrity Impact to the Vulnerable System / Subsequent System (VI/VS)	Welchen Einfluss hat eine erfolgreiche Ausnutzung der Schwachstelle auf die Integrität des verwundbaren Systems sowie auf die nachfolgenden Systeme?	High (H): Eine erfolgreiche Ausnutzung der Schwachstelle führt zu einem totalen Verlust der Integrität. Ein Angreifer kann entweder sämtliche Daten manipulieren oder kann nur gewisse Daten ändern, welche aber einen direkten und schweren Einfluss auf die Sicherheit der Systeme mit sich trägt. Low (L): Eine erfolgreiche Ausnutzung der Schwachstelle führt zu einem gewissen Verlust der Integrität. Ein Angreifer kann bestimmte Daten verändern, kann die Konsequenzen dieser Änderungen aber nicht direkt steuern. None (N): Kein Verlust der Integrität.
Availability Impact to the Vulnerable System / Subsequent System (VA/SA)	Welchen Einfluss hat eine erfolgreiche Ausnutzung der Schwachstelle auf die Verfügbarkeit des verwundbaren Systems sowie auf die nachfolgenden Systeme?	High (H): Eine erfolgreiche Ausnutzung der Schwachstelle führt zu einem totalen Verlust der Verfügbarkeit. Ein Angreifer ist in der Lage den Zugriff auf Ressourcen der Systeme vollständig zu verweigern oder kann nur gewisse Verfügbarkeiten blockieren, was aber zu einer schweren Beeinträchtigung der Systeme führt. Low (L): Eine erfolgreiche Ausnutzung der Schwachstelle führt zu einem gewissen Verlust der Verfügbarkeit. Die Performance des Systems ist beeinträchtigt, aber es kann immer noch vereinzelt oder teilweise darauf zugegriffen werden. None (N): Kein Verlust der Verfügbarkeit.

Impact Metric

Beschreibung

Mögliche Werte

Confidentiality Impact to the Vulnerable System / Subsequent System (VC/SC)

Welchen Einfluss hat eine erfolgreiche Ausnutzung der Schwachstelle auf die Vertraulichkeit des verwundbaren Systems sowie auf die nachfolgenden Systeme?

High (H): Eine erfolgreiche Ausnutzung der Schwachstelle führt zu einem totalen Verlust der Vertraulichkeit. Ein Angreifer hat Zugriff auf sämtliche Daten und kann diese auslesen.
Low (L): Eine erfolgreiche Ausnutzung der Schwachstelle führt zu einem gewissen Verlust der Vertraulichkeit. Ein Angreifer hat Zugriff auf gewisse Daten, kann aber nicht steuern welche.
None (N): Kein Verlust der Vertraulichkeit.

Integrity Impact to the Vulnerable System / Subsequent System (VI/VS)

Welchen Einfluss hat eine erfolgreiche Ausnutzung der Schwachstelle auf die Integrität des verwundbaren Systems sowie auf die nachfolgenden Systeme?

High (H): Eine erfolgreiche Ausnutzung der Schwachstelle führt zu einem totalen Verlust der Integrität. Ein Angreifer kann entweder sämtliche Daten manipulieren oder kann nur gewisse Daten ändern, welche aber einen direkten und schweren Einfluss auf die Sicherheit der Systeme mit sich trägt.
Low (L): Eine erfolgreiche Ausnutzung der Schwachstelle führt zu einem gewissen Verlust der Integrität. Ein Angreifer kann bestimmte Daten verändern, kann die Konsequenzen dieser Änderungen aber nicht direkt steuern.
None (N): Kein Verlust der Integrität.

Availability Impact to the Vulnerable System / Subsequent System (VA/SA)

Welchen Einfluss hat eine erfolgreiche Ausnutzung der Schwachstelle auf die Verfügbarkeit des verwundbaren Systems sowie auf die nachfolgenden Systeme?

High (H): Eine erfolgreiche Ausnutzung der Schwachstelle führt zu einem totalen Verlust der Verfügbarkeit. Ein Angreifer ist in der Lage den Zugriff auf Ressourcen der Systeme vollständig zu verweigern oder kann nur gewisse Verfügbarkeiten blockieren, was aber zu einer schweren Beeinträchtigung der Systeme führt.
Low (L): Eine erfolgreiche Ausnutzung der Schwachstelle führt zu einem gewissen Verlust der Verfügbarkeit. Die Performance des Systems ist beeinträchtigt, aber es kann immer noch vereinzelt oder teilweise darauf zugegriffen werden.
None (N): Kein Verlust der Verfügbarkeit.

Für eine korrekte Einschätzung kann auch der von FIRST publizierte User Guide hilfreich sein [3]. Dieser bietet praktische Flow-Charts für eine Einschätzung aller Base Metriken an.

Flow Chart für Bewertung der PR-Metrik [3]

Schlussendlich kann eine Schwachstelle als sogenannter Vector String zusammengestellt werden. Ein solcher String könnte beispielsweise folgendermassen aussehen: CVSS:4.0/AV:N/AC:L/AT:N/PR:H/UI:N/VC:L/VI:L/VA:N/SC:N/SI:N/SA:N.
Dieser Vector String charakterisiert den Base Score und kann optional noch durch die weiteren Metrik Gruppen ergänzt werden.

Die Berechnung des Scores erfolgte in früheren Versionen durch eine mathematische Formel. So ist beispielsweise die Berechnung des CVSSv3-B Scores durch folgende Formel definiert.

Formel für die Berechnung des CVSSv3-B Scores [4]

Wenn Ihr Gehirn beim Betrachten dieser Definition gerade einen kleinen Aussetzer hatte und Ihre Augen kurz am Monitor vorbei ins Leere gestarrt haben, geht es Ihnen ähnlich wie mir. Vollständigkeitshalber wollte ich die genaue Definition der Formel aufzeigen, um zu veranschaulichen, wie formal die genaue Berechnung des Scores ist.

Bei der Entwicklung der Version 4 von CVSS wurde die Berechnung mit einer fixen Formel durch einen anderen Ansatz ersetzt. In diesem neuen Ansatz (genannt MacroVector-Ansatz) wurden alle möglichen Kombinationen von String Vectors klassifiziert und einem vordefiniertem Bewertungsbereich zugeordnet. Glücklicherweise müssen die Scores nicht jedes mal von Hand berechnet werden, sondern es existieren sehr praktische Rechner, welche Online aufzufinden sind. So beispielsweise der Rechner, welcher von FIRST zur Verfügung gestellt wird: Common Vulnerability Scoring System Version 4.0 Calculator.

In diesen Rechner können die verschiedenen Werte entsprechend der Tabelle oben ausgefüllt und eingegeben werden. Wenn wir unseren Vector String (CVSS:4.0/AV:N/AC:L/AT:N/PR:H/UI:N/VC:L/VI:L/VA:N/SC:N/SI:N/SA:N) von vorher eingeben, können wir den CVSSv4 Score der fiktiven Schwachstelle berechnen lassen.

CVSSv4 Rechner [5]

Beispiel

Das System haben wir also nun verstanden. Die Theorie ist schön und gut, aber wie könnte das ganze in der Praxis bewertet werden. Hier möchte ich ein altes Beispiel aufnehmen, welches regelmässige Leser aus dem Blog “Github Copilot & Co.” wiedererkennen werden. Konkret geht es um eine SQL-Injection Schwachstelle im Login einer einfachen Webapplikation. Bei dieser Applikation kann man sich mit einem Benutzernamen und einem Passwort anmelden.

Durch folgende Eingaben kann in der Applikation eine SQL-Injection durchgeführt werden, wodurch ein Benutzer ohne ein gültiges Login den Authentifizierungsprozess umgehen kann.

Möchten wir für diese SQL-Schwachstelle einen CVSS Score erstellen, können wir nun einfach die verschiedenen Base-Score Metriken durchgehen.

Exploitability Metric	Beschreibung	Mögliche Werte
Attack Vector (AV)	Network (N)	Zwar handelt es sich in Wahrheit bei diesem Beispiel nur um ein lokal gehostetes Beispiel – um die Schwachstelle aber etwas interessanter zu gestalten, nehmen wir an, dass es sich bei der Applikation um eine öffentliche, aus dem Internet erreichbare Platform handelt.
Attack Complexity (AC)	Low (L)	Die Schwachstelle kann sehr einfach ausgenutzt werden und ist in der Komplexität sehr limitiert.
Attack Requirements (AT)	None (N)	Für die Ausnutzung der Schwachstelle werden keine weiteren expliziten Voraussetzungen benötigt.
Privileges Required (PR)	None (N)	Um die Schwachstelle auszunutzen, ist keine Authentifizierung nötig.
User Interaction (UI)	None (N)	Es wird keine weitere Interaktion von anderen Benutzern verlangt, um die Schwachstelle auszunutzen.
Confidentiality Impact to the Vulnerable System / Subsequent System (VC/SC)	Vulnerable System: Low (L) Subsequent System: None (N)	In unserem Beispiel geschieht nicht viel mehr als dass die Meldung “login success” angezeigt wird. Es ist aber nicht unrealistisch anzunehmen, dass ein Angreifer bei einer “echten” Applikation dadurch bereits auf gewisse Daten Zugriff erhält. Wir nehmen auch an, dass keine weiteren Systeme betroffen sind.
Integrity Impact to the Vulnerable System / Subsequent System (VI/VS)	Vulnerable System: Low (L) Subsequent System: None (N)	Auch hier geschieht im Beispiel nicht viel mehr als “login success”. Wir können aber annehmen, dass durch eine erfolgreiche Anmeldung in der Applikation, ein Angreifer bereits die Berechtigung erhält einige Inputs einzugeben und verschiedene Einträge zu ändern. Auch hier beschränken wir uns nur auf das Hauptsystem und nehmen auch an, dass keine weiteren Systeme betroffen sind.
Availability Impact to the Vulnerable System / Subsequent System (VA/SA)	Vulnerable System: None (N) Subsequent System: None (N)	Durch eine einfache Anmeldung entsteht normalerweise keine Auswirkung auf die Verfügbarkeit der Systeme. Auch legitime Benutzer können sich weiterhin am System anmelden.

Aus dieser Aufstellung ergibt sich nun unser Vector String folgendermassen: CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:L/VI:L/VA:N/SC:N/SI:N/SA:N.
Berechnen wir gemäss diesem Vector den Score, so würde diese Schwachstelle einen CVSSv4 Score von 6.9 erhalten, was einem mittleren Schweregrad der Schwachstelle entspricht.

Fazit

Falls Sie bis hierhin gelesen haben, gratuliere ich Ihnen. Obwohl es sich beim CVSS Framework um eine eher formelle Angelegenheit handelt, müssen sich die meisten nicht so tief mit der Berechnung der Scores auseinandersetzen. Und das ist auch gut so. Denn das schlussendliche Resultat von einem einfachen Score von 0.0 – 10.0 kann durch jeden und jede sehr einfach gedeutet werden.

Trotzdem ist es wichtig zu verstehen was CVSS genau ist und was es nicht ist. Wie wir gesehen haben ist CVSS ein System zur Einstufung des Schweregrads einer Schwachstelle. Sie ist Kontext- und Umgebungsunabhängig und kann daher nicht das tatsächliche Risiko einer Schwachstelle beschreiben. Wie wir in diesem Blog gesehen haben, gibt es bei einer Bewertung auch immer etwas Spielraum bei der genauen Einstufung der Metriken, insbesondere wenn eingeschätzt werden soll, wie hoch der mögliche Impact der Schwachstelle ist. Daher macht es immer Sinn, dass eine Bewertung durch Instanzen und Personen gemacht wird, die sich besonders gut mit dem betroffenen System auskennen, wie beispielsweise die Hersteller. Manchmal kommt es durchaus auch vor, dass mehrere unterschiedliche CVSS-Scores vorliegen.

Schlussendlich bietet CVSS nicht eine perfekte Bewertung sondern lediglich eine von vielen Möglichkeiten, um die intrinsischen Charakteristiken von Schwachstellen zu kategorisieren und zu bewerten. Für eine effektive Priorisierung und Management von Schwachstellen braucht es aber immer noch den Einbezug des Umfelds der Schwachstelle. Denn in der Realität existieren Schwachstellen nie isoliert ohne ihre Umgebung.

Ressourcen

[1] Vulnerability Metrics
https://nvd.nist.gov/vuln-metrics/cvss

[2] Common Vulnerability Scoring System – Specification Document
https://www.first.org/cvss/v4.0/specification-document

[3] Common Vulnerability Scoring System – User Guide
https://www.first.org/cvss/v4.0/user-guide

[4] Common Vulnerability Scoring System Calculator
https://nvd.nist.gov/vuln-metrics/cvss/v3-calculator

[5] Common Vulnerability Scoring System Version 4.0 – Calculator
https://www.first.org/cvss/calculator/4.0

Informationen zum Autor: Annika Salzmann

Ein Programmierkurs hat bei mir als Kind die Leidenschaft für Computer und IT geweckt. Während meinem Informatikstudium habe ich dann meine Faszination für die IT-Security entdeckt. Seit Herbst 2022 darf ich nun bei der goSecurity, begleitend zu meinem Studium, meinem Wissensdrang nachkommen und meine Kenntnisse im Bereich Softwareentwicklung einbeziehen.

goSecurity BLOG