CVSS: Characterizing and Scoring Vulnerabilities

The impact of potential vulnerabilities on our hardware and software increases significantly as our daily activities become more digitized. Preventing these vulnerabilities requires us to know how they work. But we also need an assessment mechanism to evaluate their criticality. The existence of varying web application vulnerability detection products in the field further complicates the standardization process involved in identifying and determining their severity ranking.

Sun Tzu, naturally, has something to say on the matter of enemies in The Art of War:

If you know the enemy and know yourself, you need not fear the result of a hundred battles. If you know yourself but not the enemy, for every victory gained you will also suffer a defeat. If you know neither the enemy nor yourself, you will succumb in every battle.

The Common Vulnerability Scoring System (CVSS) was developed in 2005 to fix the lack of standardization in the industry. CVSS is an open, independent and large-scale vulnerability scoring system that categorizes vulnerabilities. By using CVSS to categorize and grade vulnerabilities, it became possible to produce a vectoral string and score, which can be used in other vulnerability management systems.

In this article, we take a closer look at the details of the current CVSS version 3.0, and provide examples of a few vulnerability assessments from a web application security perspective.

Characterizing Vulnerabilities

In CVSS v3, vulnerabilities are characterized under 3 metric groups:

1. Base
2. Temporal
3. Environmental

Let's examine each by defining the additional metrics they use.

Base Score

Base metrics focus on the inherent qualities of a vulnerability that will not change in time, or depend on the environment.

The base score has two subscores: Exploitability and Impact. We can include two virtual categories among these subscores as we analyze the base metric group: Vulnerable Component and Impacted Component. The Scope value states whether the Vulnerable and Impacted Components are the same or not, and defines whether a vulnerability on a part of the system can affect the rest of the system, by allowing the attacker to use the vulnerability to escape the scope of the vulnerability and access the rest of the system.

Leaving aside the exceptional situations listed below, Vulnerable Component and Impacted Component are the same. The exceptions are:

• XSS vulnerability in a web application: Even though the web application would technically be the vulnerable component in this case, the browser is evaluated as an Impacted Component. This is because the confidentiality, integrity and availability of the browser will be impacted, since the XSS vulnerability will allow the attacker to steal private information and execute scripting code on the browser.
• Sandbox escape: Sandbox is a testing environment where we isolate applications or hardware to prevent them from spreading. In the event of a leak, the applications nearby will not be affected, escaping the sandbox.

Outside these two virtual categories, CVSS v3 handles the Base Score in two categories: Exploitability and Impact. While Exploitability grades the easiness of exploiting and the necessity of tools for exploiting the vulnerability, Impact defines the results of a potential exploit. Each is outlined below.

Exploitability Metrics

Exploitability metrics define the simplicity of exploiting the vulnerable component.

Attack Vector (AV): Where the Attack Originates From

Network (N): The Vulnerable Component may be exploited remotely, over the network.
Adjacent Network (A): The Vulnerable Component may be exploited from the same physical or logical network.
Local (L): The Vulnerable component may be exploited from a local authorized session, without the need of a network.

Physical (P):  The Vulnerable component may be exploited only through physical access to the component. This attack vector was introduced in CVSS v3.

Attack Complexity (AC): Skills Required

Low (L): The vulnerability may be exploited with no additional skills.
High (H): The vulnerability may be exploited with additional tools, conditions and skills.

Privileges Required (PR)

This metric was named 'Authentication (AU)' in CVSS v2 and it defines the necessity of privileges in order to exploit a vulnerability.

None (N): The attacker does not need any privileges to exploit the vulnerability.
Low (L): The attacker is required to have basic privileges in a system to exploit the vulnerability.
High (H): The attacker has to have higher privileges in a system to exploit the vulnerability. The necessity of higher privileges might seem contradictory but the vulnerable component and impacted component might be different.

User Interaction (UI)

None (N): The vulnerability may be exploited without the need for a user interaction.
Required (R): The vulnerability may be exploited if the user takes some action. For example, for the successful exploitation of a CSRF attack, the attacker should induce the victim to click on an external link or visit a certain webpage.

Scope (S)

This metric defines whether the Vulnerable Component and the Impacted Component are the same or not.

Unchanged (U): The Vulnerable Component and the Impacted Component are the same.
Changed (C): The Vulnerable Component and the Impacted Component are different. For instance, as stated in the XSS example we gave above, the vulnerable component is the web application, and the impacted component is the web browser.

Impact Metrics

The Impacted Component is evaluated based on the damage the attack might do to confidentiality (C), integrity (I), and availability (A).

Confidentiality (C)

This metric measures the impact of the exploited vulnerability on the confidentiality of the information within the system.

High (H): A large portion of the resources in the system can be acquired on exploitation of the vulnerability.
Low (L): A small portion of the resources in the system can be acquired on exploitation of the vulnerability.
None (N): The confidentiality of the resources in the system is not lost on exploitation of the vulnerability.

Integrity (I)

This metric measures the impact of the vulnerability exploit on the integrity and veracity of the resources.

High (H): All components can be modified or lost due to the vulnerability.
Low (L): Data can be modified but will not have a severe effect on the impacted component. The attacker does not have control over the consequences of the data modification.
None (N): There’s no loss of protection on the impacted component.

Availability Impact (A)

This metric measures the accessibility to the impacted component after the successful exploit of a vulnerability.

High (H): The access to the system is entirely denied, or there might be some loss of availability that heavily affects the Impacted Component.
Low (L): The access to the system isn’t completely denied but there are partial denials.
None (N): The system is not affected in terms of accessibility.

Temporal Score

Temporal metrics measure how the vulnerabilities are exploited, and how they may be fixed. For example, if a patch is released, the Temporal Score of the vulnerability will decrease. If a new method of exploiting the vulnerability is discovered, this score will increase. Temporal score also depends on the way the vulnerability exploit is reported. The score of the information found within these reports will affect the overall Temporal Score.

As indicated in the metric values below, unlike the Base Score, the Temporal Score changes over time.

Exploit Code Maturity (E)

The Exploit Code Maturity metric measures the probability of exploiting the vulnerability.

Not Defined (X): This will not change the score. It means that the metric is skipped from the scoring.
High (H): No exploit is required, or an effective exploit code is delivered autonomously.
Functional (F): Exploit codes are available. Exploitation of the vulnerability can be repeated using these codes.
Proof-of-Concept (P): Exploiting the vulnerability isn’t simple for most systems. The attacker has to demonstrate extra modifications.
Unproven (U): No exploit codes are available.

Remediation Level (RL)

This metric measures the existence of remedial actions for a vulnerability. Generally, vulnerabilities are unpatched in their initial release.

Not Defined (X): This will not change the score. It means that the metric is skipped from the scoring.
Unavailable (U): There is no solution available.
Workaround (W): There are unofficial methods of patching the vulnerability.
Temporary Fix (T): There is an official but temporary solution.
Official Fix (O): There’s a solution released by the vendor.

Report Confidence (RC)

The Report Confidence metric measures the amount of details in the vulnerability report and their credibility.

Not Defined (X): This will not change the score. It means that the metric is skipped from the scoring.

Confirmed (C): The vendor has confirmed the existence of the vulnerability or the public functional exploit. There are detailed reports to verify the research of the vulnerability.
Reasonable (R): There are important details available, but the source code isn’t open to public access, so the research cannot be verified.
Unknown (U): The report only states that the vulnerability exists. Causes or effects are not reported.

Environmental Score

Generally, Base and Temporal scores are used by people like security analysts and developers who are informed about the vulnerability characteristics. Environmental scores, on the other hand, are used by organizations as end users who evaluate the effects of the vulnerability on the environmental context.¹

Environmental scores measure the impact of the vulnerability characteristics, defined with the Base score on the given context, such as an organization’s department.

For example, normally when the Base score is calculated, Confidentiality, Integrity, and Availability are three independent, equal values.² However in some situations or systems, Availability might be far more important than the others. In that case, the value of Availability in the score can be assigned a greater factor.

Another example is that when the exploitation of a vulnerability requires authorization, the environmental condition might not require authorization. Therefore, the Privileges Required metric will be given the value None, increasing the overall score of the vulnerability.

Calculation

The JavaScript library published on the First website of can be used to calculate CVSS v3 scores.³

Calculating Base Scores

First the Impact Subscore Base (ISC Base) value is calculated:

ISCBase = 1 - ((1−ImpactConf) × (1−ImpactInteg) × (1−ImpactAvail))

Next, depending on whether the scope changes or not, Impact Subscore (ISC) is calculated with two different methods:

 // Calculate ISC
 if(Scope=="U") {  // U=Unchanged
   ISC = 6.42 * ISCBase;
 } else {
   ISC = 7.52 * (ISCBase-0.029)-3.25*Math.pow((ISCBase-0.02), 15);
 }

Then the Exploitability Subscore (ESC) is calculated:

ESC = 8.22 × AttackVector × AttackComplexity × PrivilegeRequired × UserInteraction

After the calculations of ISC and ESC, it’s time to calculate the Base Score

If the ISC value is 0, the Base Score is 0, too. If ISC value is 0 or greater we enter this code:

if(ISC<=0) {
		BaseScore=0;
	} else {
		if($("#S").val()=="U") {
			BaseScore = roundUp1(Math.min((ISC+ESC),10));
		} else {
			BaseScore = roundUp1(Math.min((1.08*(ISC+ESC)),10));
		}
	}

The roundUp1 function should catch your attention. Here’s the description of it in the specifications:

function roundUp1(d) {
  return Math.ceil (d * 10) / 10;
}

After finding the Base Score, we can calculate Temporal Score with the following formula:

Round up(BaseScore × ExploitCodeMaturity × RemediationLevel × ReportConfidence)

CVSS Vector String

CVSS vector strings are the textual representations of the CVSS scores. They are a useful way to demonstrate and store the CVSS scores. CVSS vector strings begin with the CVSS tag, followed by the numeric CVSS version used in the scoring. Following this is the forward slash (/), the metrics and their values.

The metrics can be specified in any order in a vector string. However, the preferred order is given in the table below.

Another rule is that the Base metrics must take place in the strings, but the listing of Temporal and Environmental metrics depend on the preference of the user.

The optional group metrics not specified in the CVSS vector string will be considered as Not Defined (X). The metrics that are specifically given the Not Defined (X) value do not have to appear in the CVSS vector string.

For example:

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

In the vector string above, where Temporal and Environmental metric groups aren’t set, the following metrics and values are given:

• Attack Vector: Network
• Attack Complexity: Low
• Privileges Required: High
• User Interaction: None
• Scope: Unchanged
• Confidentiality: Low
• Integrity: Low
• Accessibility: None

Every Temporal and Environmental metric not stated above will be considered as Not Defined (X).

For example:

CVSS:3.0/S:U/AV:N/AC:L/PR:H/UI:N/C:L/I:L/A:N/E:F/RL:X

In this example, Exploitability Mature (E) is given the Functional (F) value, and the Remediation Level (RL) is given the Not Defined (X) value. There’s no particular order of the list of metric values.

Example Score Calculation

We can demonstrate a sample score calculation for a vulnerability by using CVSS v3.0. The GNU Bourne-Again Shell (Bash) 'Shellshock' Vulnerability (CVE-2014-6271) vulnerability, which affected many Linux based servers in 2014, is ideal as an example.⁴

Before we begin, it’s useful to refresh our memories on what the vulnerability was. The Apache servers that worked in the CGI mode formed environment variables with the request header and stored the header variables in these environment variables.

Shellshock is a security bug that causes Bash to execute commands when setting environment variables unintentionally, if environment contains the bash command. In other words, if exploited, this vulnerability allows the attacker to remotely issue commands on the server. This is also known as a remote code execution.

Read more about the Shellshock vulnerability in our blogpost Shellshock Bash Remote Code Execution Vulnerability Explained and How to Detect It.

Attack Vector: Network

In this case, the vulnerability may be exploited by the attacker over the network. The vulnerable component in this attack is a web server.

Attack Complexity: Low

In this case, the vulnerability may be exploited with no additional skills. The attacker will exploit the vulnerability in every situation where the HTTP request can be edited manually. This is even possible with the built-in HTTP Request Builder of the browsers.

Privileges Required: None

The attacker does not need any privileges to exploit the vulnerability.

User Interaction: None

The vulnerability may be exploited without the need for a user interaction. The vulnerability may be exploited with a HTTP request crafted specifically for exploits.

Scope: Unchanged

Scope doesn’t change because the vulnerability is caused by Bash and all the impact is on the Bash shell.

Confidentiality, Integrity, and Availability Impact: High

Since the attacker can take full control over the system through Bash, the confidentiality, integrity, and availability is under high risk.

CVSS v3.0 Base Score: 9.8
CVSS v3.0 Vector String: CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H

Netsparker and CVSS

Netsparker added CVSS to vulnerability reports in the version released in October 2016. Netsparker scores all the vulnerabilities it checks in the Base and Temporal metrics. The user can configure the Environmental metrics by adjusting the Report Policy settings. CVSS values, CVSS vectoral strings, and the severity scores are all listed in the reports, alongside the vulnerability classifications.

Authored by Ziyahan Albeniz
Reviewed by Sven Morgenroth
Translated by Umran Yildirimkaya

--------------------

¹ https://www.first.org/cvss/specification-document
² Please view the Metric Values table.
³ https://www.first.org/cvss/use-design
⁴ https://www.cvedetails.com/cve-details.php?t=1&cve_id=2014-6271