Mastering CVSS version 3.1, Elearning Course Transcript

Module 1: CVSS Elearning Course Introduction

Welcome to the elearning course on CVSS.

CVSS stands for The Common Vulnerability Scoring System and is a vendor-agnostic, industry-open standard designed to convey vulnerability severity and help determine urgency and priority of response. CVSS was commissioned by the National Infrastructure Advisory Council, or NIAC, tasked in support of the global Vulnerability Disclosure Framework. It is currently maintained by the Forum of Incident Response and Security Teams, or FIRST.

Let’s start with some learning objectives and an agenda.

In this course, you will first learn about Base metrics, Temporal metrics, Environmental metrics, and then move on to CVSS Severity Ratings and Vector String.

From there, you will get to practice working with different kinds of vulnerabilities, culminating in a course project.

Module 2: CVSS v3.0 to CVSS v3.1

Here’s some background on the move from CVSS version 3.0 to CVSS version 3.1.

• CVSS version 3.0 was released in June 2015 with updated numerical formulas that retained the existing scoring range of 0 to 10.
• CVSS version 3.1 released in June 2019 retains that scoring framework while emphasizing that CVSS measures severity, not risk.
• The language in CVSS version 3.1 has been updated to specify that a comprehensive risk assessment should employ more than just a CVSS Base Score, and many definitions and sections have been updated for better clarity.
• CVSS version 3.0 introduced the Scope, or S, metric, which was designed to make clear which vulnerabilities may be exploited and then used to attack other parts of a system or network. CVSS version 3.1 has updated the Scope explanation and the concepts of the impacted component and the vulnerable component for better clarity.
• In CVSS version 3.1 there are additional privileges assigned to the Impact metrics.
• And CVSS version 3.1 includes additional guidance around scoring software libraries and vulnerability changes.

And now, please read about how the metrics in CVSS version 3.1 work.

Module 3: Working with CVSS v3.1 Base Metrics

First, let’s examine how to work with Base metrics in CVSS version 3.1.

Your first set of tasks will be to evaluate a threat by using CVSS Base metrics, via a simulation of the CVSS version 3.1 calculator. The CVSS calculator implements the formula defined in the CVSS version 3.1 standard, generating scores based on the metric values you enter. You should refer to the standard for details of the metrics to ensure you pick the correct values for a given vulnerability. Hovering your mouse pointer over metric group names, metric names and metric values displays a summary of the information in the standard. This feature is not available on devices with no pointer, such as touchscreen. Also, the calculator is not yet accessible to people who are blind or low-sighted, so we will describe the calculator textually.

The calculator is actually three calculator applications, to determine Base metrics, Temporal metrics, and Environmental metrics.

Base metric calculator buttons are listed below by metric and value.

Temporal metric calculator buttons are listed below by metric and value.

Environmental metric calculator buttons are listed below by metric and value.

Let's define some terminology we need, and then go through the metrics one by one.

We will introduce the Base metrics using the scenario of a web application that has a vulnerability. The web application requires all users to log in, but it denies access to those on a blacklist of banned users. This blacklist is accessible only to privileged users, and blacklist changes require a separate administrative password. A vulnerability exists in the application, but only in specific non-default configurations. It allows a privileged user to change the blacklist without entry of the administrative password. The vulnerability can be exploited via a malicious HTTP GET request.

Here is the intended normal execution flow:

1. The GET request is made to the server with actions to be performed only on the web application configuration file containing the list of blacklisted users.
2. The server checks the requestor’s privileges.
   • If the requestor is not a privileged user, then the server discards the request.
   • If the requestor is a privileged user, the server generates an authorization prompt. If the request is authorized, the server executes the actions specified in step 1. If it is not, the request is discarded.

Here is how the vulnerability allows the following execution flow: It’s the same flow as the one directly previous, but when the server checks the privileges of the requestor:

• If the requestor is not a privileged user, then the server discards the request.
• If the requestor is a privileged user, the actions are executed as specified in step 1.

So, again, previously, once the server identified a privileged user, it issued a request for authorization. In this scenario, the server executes actions.

An attacker with unprivileged access to the web application may trick a user with administrative privileges, for example by creating a support request, into visiting a specially crafted URL; by escaping certain parameters of the GET request in the URL, the attacker may force the software module that manages the request to erroneously bypass the authentication prompt and execute the requested actions without the explicit authorization of the privileged user.

A successful attack allows an attacker to modify only the configuration file that contains the blacklist. The modification of these files may allow the attacker to add arbitrary users to the blacklist file, thus preventing those users from accessing the web application.

We will explain more details of this vulnerability as we introduce each metric. This module will take you through the Base metrics in detail, followed up by Temporal metrics and Environmental metrics, so that you can create a CVSS score for this vulnerability.

Before we get further into the vulnerability, you need to know some key terminology.

This hypothetical vulnerability is caused by a faulty management of URL requests in the software module of the web application.

Under normal conditions, a privileged user would be prompted with an authentication dialogue for every request passed to the software module. However, in this case the module fails to properly handle all input from privileged users, which may lead to the execution of the requested actions without the prompt of the authentication dialogue.

Here the software module is controlled by the web application. The web application is considered an authorization scope because it implements its own privilege system consisting of users, passwords, and permissions restricting users to specific data. The web application is therefore the part of the overall system that is considered the vulnerable component.

Let’s start with the first Base metric, Attack Vector. This metric reflects the context by which vulnerability exploitation is possible. The Attack Vector metric value, and consequently the Base Score, will be larger the more remote logically, and physically, an attacker can be while exploiting the vulnerable component. The assumption is that the number of potential attackers for a vulnerability that could be exploited from across the Internet is larger than the number of potential attackers that could exploit a vulnerability requiring physical access to a device, and therefore warrants a greater score.

If an attacker physically touches or manipulates the hardware of the vulnerable component, Attack Vector is Physical.

When a vulnerability is bound to the network stack, Attack Vector is either Network or Adjacent. If a vulnerability requires user interactions to either download or receive malicious content, such as through USB drives, that is then executed locally, then Attack Vector is Local. An example of this might be a code execution through a file-parsing vulnerability in a PDF reader.

Attack Vector for vulnerabilities exploited via Secure Shell, or SSH, Remote Desktop, VMWare Remote Console, and other remote access methods may be Local or not, depending on how the protocol or application is used as part of the vulnerability.

For example, if a vulnerability is exploited in the SSH protocol itself, such as a remote script execution through a vulnerability in sshd, then Attack Vector is Network or Adjacent.

For another example, if shell access on a system is required to exploit a system vulnerability and SSH is simply the method for obtaining the shell, then Attack Vector is Local.

If the vulnerable system is inside a private but nonrestrictive network behind a Network Address Translation, or NAT, and the attacker has to be on the private network to exploit it, then the Attack Vector is Network. If the attacker needs to be in the same network collision domain, secure domain, or limited administrative domain as the vulnerable system, then the Attack Vector is Adjacent.

Examine the Attack Vector Scoring Rubric. The rubrics are visual devices and we will give the logic descriptions for the rubrics throughout the module in the following bullet-point format.

• If the attacker is able to exploit the vulnerable component via the network:

  • The Network rating says that the vulnerability is exploitable from a remote network, such as across the Internet. By the way, metrics and metric values have an abbreviated form used in the vector string that we'll explain later in the course. For example, Network can be abbreviated as "N".

  • If the attacker is not able to exploit the vulnerable component via the network, the Adjacent rating states that the vulnerability is limited at the protocol level to a logically adjacent topology such as Bluetooth or Wi-Fi.

• If the attacker is unable to exploit the vulnerable component via the network, the next question is, does the attacker require physical access to the target?

  • If not, the Local rating states that the attack is committed through a local application vulnerability, or the attacker is able to log in locally.
  • If yes, the Physical rating states that the attacker requires physical access to the vulnerable component.

Keep in mind that the Base Score increases the farther logically and physically the attacker can be from the target.

The attacker can perform all steps of the attack against the vulnerable web application over a network, so the Attack Vector is rated as Network. A vulnerability exploitable with Adjacent network access would mean the vulnerable component is bound to the network stack, but the attack must be performed from the same shared physical or logical network, that is, an attack is only possible over a Bluetooth network. A vulnerability exploitable with Local access would mean that the vulnerable component is not bound to the network stack, and the attacker's path is via read/write/execute capabilities. A vulnerability exploitable with Physical access would require the attacker to physically touch or manipulate the vulnerable component.

Now let’s talk about Attack Complexity. This metric describes the conditions beyond the attacker's control that must exist to enable them to exploit the vulnerability. Such conditions may require the collection of more information about the target, the presence of certain configuration settings on the target, or significant computational work, such as brute-forcing a secret. Importantly, the assessment of this metric excludes any requirements for user interaction in order to exploit the vulnerability, and such conditions are captured in the User Interaction metric. The Base Score increases the most for the least complex attacks.

Let’s examine the Attack Complexity rubric.

• If the attacker cannot exploit the vulnerability at will, the score is High.
• If the attacker can reliably exploit the vulnerability at any time, the score is Low.

The Base Score is greater when the attack can be performed at will.

In scoring the authentication bypass vulnerability, keep in mind that this vulnerability is triggered by a non-default setting of the web application that allows remote HTTP GET requests to modify a configuration file of the web application that contains a blacklist of users. If a specific configuration is required for an attack to succeed, the Base metrics must be scored assuming that the vulnerable component is in that configuration. Attack Complexity is therefore rated as Low.

Now let’s talk about Privileges Required. This metric describes the level of privileges an attacker must possess before successfully exploiting the vulnerability. This metric is greatest if no privileges are required.

Let’s examine the Privileges Required rubric.

• If the attacker is authorized to the vulnerable component prior to attack and administrator privileges are not required, the score is Low.
• If the attacker is authorized to the vulnerable component prior to attack and administrator privileges are required, the score is High.
• If the attacker is not authorized to the vulnerable component prior to attack, the score is None.

In this case, the Base Score increases as fewer privileges are required.

In scoring the authentication bypass vulnerability, a successful attack requires the attacker to login to the vulnerable web application to send the crafted URL to a privileged user; for example, by creating a support request. This attack would not be possible if the attacker did not have access to the web application prior to attempting the attack. As the attacker only needs an account providing basic user capabilities, Privileges Required is rated as Low.

Privileges Required would be rated as None if the attacker did not need to log in to the web application to perform the attack. It would be rated High if the attacker needed to log in to the web application as a privileged user to perform the attack.

Now let’s talk about User Interaction. This metric captures the requirement for a user, other than the attacker, to participate in the successful compromise of the vulnerable component. This metric determines whether the vulnerability can be exploited solely at the will of the attacker, or whether a separate user or user-initiated process must participate in some manner. This metric value is greatest when no user interaction is required.

Let’s examine the User Interaction rubric.

Does the attacker require some other user to perform the action to let an attack unfold?

• If yes, the score is Required.
• If no, the score is None.

Here the Base Score is greater when no user interaction is required.

In scoring the authentication bypass vulnerability, a successful attack requires a privileged user to open the malicious URL. As the attack requires an action by a user other than the attacker, User Interaction is rated as Required. User Interaction would be rated as None for a vulnerability where an attack is possible without the involvement of other people.

Now let’s check your learning on the Base metrics by asking a question about the Base metrics.

Take a minute to figure out which of these statements about the Base metrics you’ve learned are true or false.

• [ ] Attack Vector reflects the context by which vulnerability exploitation is possible.
• [ ] Attack Complexity describes the level of privileges an attacker must possess before successfully exploiting the vulnerability.
• [ ] Privileges Required describes the conditions beyond the attacker's control that must exist in order to exploit the vulnerability.
• [ ] User Interaction captures the requirement for a user, other than the attacker, to participate in the successful compromise of the vulnerable component.

Here are the answers:

It’s true that Attack Vector reflects the context by which vulnerability exploitation is possible.

Attack Complexity does not describe the level of privileges an attacker must possess before successfully exploiting the vulnerability. This is the description for Privileges Required.

Privileges Required does not describe the conditions beyond the attacker's control that must exist in order to exploit the vulnerability. This is the description for Attack Complexity.

It’s true that User Interaction captures the requirement for a user, other than the attacker, to participate in the successful compromise of the vulnerable component.

Now let’s talk about the Scope metric. When we talk about Scope, we need to examine vulnerable components and impacted components.

• Remember that a vulnerable component is the thing that is vulnerable; another way to look at it is that it is the security scope that contains the vulnerability.
• An impacted component is is the thing that suffers the impact; another way to look at it is that it is the security scope that is affected by the vulnerability

What you need to do is consider the authorization scope of both components and determine whether they are different.

Security scopes can be represented graphically, showing the vulnerable components and the impacted components.

Let’s examine the Scope rubric.

• If the attacker cannot affect a component whose authority is different than the vulnerable component, the Scope is Unchanged.
• If, on the other hand, the attacker can affect a component whose authority is different than the vulnerable component, the Scope is Changed.

Note that the Base Score is greater when systems beyond the vulnerable component are impacted.

To give you some context on the Scope metric, here is how the various Base metrics work together. Exploitability metrics reflect the characteristics of the vulnerable component. They include:

• Attack Vector,
• Attack Complexity,
• Privileges Required, and
• User Interaction.

The Scope metric is either:

• Unchanged, which means an exploited vulnerability affects resources managed by the same authority, or
• Changed, which means an exploited vulnerability affects resources beyond those of the vulnerable component.

Impact metrics are scored according to the impacted component, or the thing that suffers the worst outcome in a successful attack. They include:

• Confidentiality,
• Integrity, and
• Availability.

The Base Score is greater when a scope change has occurred.

Earlier, we determined that our hypothetical vulnerability was caused by a faulty management of URL requests in the software module. This module operates under the control of the web application, which is therefore the vulnerable component.

A successful attack allows the attacker to modify the configuration files of the same web application. Therefore, the web application is also the impacted component.

As the vulnerable component and the impacted component are the same, the Scope is Unchanged. If an alternate vulnerability resulted in an impact to a different security scope, for example, an attack allowed unauthorized actions to be taken directly on the underlying operating system, the Scope would be Changed.

Now let’s check your learning on the Base metrics by asking a question about a different vulnerability to test your understanding of the Scope metric.

Karen works on the computer security incident response team, or CSIRT, for an international bank. She gets an email from a constituent showing that the bank's website is vulnerable to reflected cross-site scripting, or XSS. A successful attack requires an attacker to trick a legitimate bank user into browsing to a specific URL. This URL points to the bank's website, but it contains malicious URL parameters that trigger the vulnerability.

A successful attack could allow the attacker to run malicious code on the legitimate user's web browser. However, the malicious code is only able to access information associated with the bank's vulnerable web site due to Same Origin Policy, or SOP, restrictions in web browsers.

What is the Scope metric value Karen assigns from these four choices?

• [ ] Changed
• [ ] Unchanged
• [ ] Low
• [ ] High

Answer: The vulnerable component is the web server vulnerable to cross-site scripting, and the impacted component is the victim's browser, so the Scope is Changed. The vulnerable component and the impacted component are not the same thing, so the Scope cannot be Unchanged. Low and High are values assigned to another type of CVSS metric.

Let's return to our original authentication bypass vulnerability, and review: The impacted component in this case, as we established a bit earlier, is the web application.

Let’s talk about Confidentiality Impact. This metric measures the impact to the confidentiality of the information resources managed by a software component due to a successfully exploited vulnerability. Confidentiality refers to limiting information access and disclosure to only authorized users, as well as preventing access by, or disclosure to, unauthorized ones. This metric value increases with the degree of loss to the impacted component.

Let’s examine the Confidentiality Impact rubric.

• If there is no impact to confidentiality, the score is None.
• Is there is an impact to confidentiality and either (a) the attacker cannot obtain all information from the impacted component and (b) the disclosed information is not critical, the score is Low.
• Is there is an impact to confidentiality and either (a) the attacker can obtain all information from the impacted component or (b) the disclosed information is critical, the score is High.

In this case, the Base Score increases with the degree of information disclosed.

In scoring the authentication bypass vulnerability, the Confidentiality Impact is rated None because a successful attack does not allow the attacker to access any information he or she did not already have access to. Remember that the attacker cannot gain full administrative privileges. Confidentiality would be rated as Low if a successful attack allowed the attacker to obtain information that he or she did not already have access to. Confidentiality would be rated High if a successful attack allowed the attacker to access all the information managed by the web application, or access limited data that presents a direct, serious impact on this metric, for example, user passwords that can be used to cause further harm.

Now let’s talk about Integrity Impact. This metric measures the impact to data trustworthiness and veracity resulting from a successfully exploited vulnerability. Integrity refers to the trustworthiness and veracity of information. This metric value increases in accordance with the amount of consequence to the impacted component.

Let’s examine the Integrity Impact rubric.

• If there is no impact to integrity, the score is None.
• If there is an impact to integrity and (a) the attacker cannot modify all information of the impacted component and (b) the modified information is not critical, the score is Low.
• If there is an impact to integrity and (a) the attacker can modify all information of the impacted component or (b) the modified information is critical, the score is High.

The Base Score increases with the degree of information that can be modified.

In scoring the authentication bypass vulnerability, the Integrity Impact is rated Low because a successful attack allows the attacker to only modify a configuration file that he or she did not already have the ability to change. Again, remember that the attacker cannot gain full administrative privileges. Integrity would be rated as None if a successful attack did not allow the attacker to modify information he or she did not already have the ability to change. Integrity would be rated High if a successful attack allowed the attacker to either modify all data managed by the web application, or modify limited data that presents a direct, serious impact to this metric, for example, passwords that can be used to cause further harm.

Now let’s talk about Availability Impact. This metric measures how the successfully exploited vulnerability affects the availability of impacted component. While the Confidentiality Impact and Integrity Impact metrics apply to the loss of confidentiality or integrity of data, for example, information or files, used by the impacted component, this metric refers to the loss of availability of the impacted component itself, which can include networked services such as web, database, or email. Because availability refers to the accessibility of information resources, attacks that consume network bandwidth, processor cycles, or disk space all affect the availability of an impacted component. This metric value increases with the amount of consequence to the impacted component.

Let’s examine the Availability Impact rubric.

• If there is no impact to availability, the score is None.
• If there is an impact to availability and (a) the attacker cannot completely deny access to the affected component and (b) the resource is not critical, the score Is Low.
• If there is an impact to availability and (a) the attacker can completely deny access to the affected component or (b) the resource is critical, the score Is High.

The Base Score increases in accordance with the degree of disruption to availability.

In scoring the authentication bypass vulnerability, the attacker can make the service unreachable to potentially all users by modifying the blacklist configuration file. The Availability Impact is therefore rated as High. Availability would be rated None if a successful attack did not impact the availability of the web application. Availability would be rated Low for vulnerabilities that noticeably reduced performance or caused interruptions in service.

The CVSS version 3.1 Base Score you derive for the vulnerability, based on all the Base metrics, is 6.3. A Base Score of 6.3 is rated as a Medium severity using the Severity Rating system.

Now let’s check your learning on the Base metrics by asking a question about the Confidentiality Impact, Integrity Impact, and Availability Impact metrics.

Pick the statement that is true about Confidentiality Impact, Integrity Impact, and Availability Impact metrics.

• [ ] The Confidentiality Impact and Integrity Impact metrics measure, respectively, the loss of confidentiality and integrity of the impacted component itself. The Availability Impact metric measures the loss of availability of the impacted component’s data.
• [ ] The Confidentiality Impact and Integrity Impact metrics measure, respectively, the loss of confidentiality and integrity of data used by the impacted component. The Availability Impact metric measures the loss of availability of the impacted component itself.
• [ ] The Confidentiality Impact and Integrity Impact metrics measure, respectively, how much confidence and integrity a user will assign to an impacted component. The Availability Impact metric measures how available a user expects an impacted component to be.

Answer: This statement is true and the other two are false: The Confidentiality Impact and Integrity Impact metrics measure, respectively, the loss of confidentiality and integrity of data used by the impacted component. The Availability Impact metric measures the loss of availability of the impacted component itself.

Module 4: CVSS v3.1 Temporal Metrics, Environmental Metrics, and Vector String

Let’s review: We have just talked about the Base Metric group, which represents the intrinsic characteristics of a vulnerability that are constant over time and across user environments. There are two other metric groups we will cover now:

1. The Temporal Metric group reflects the characteristics of a vulnerability that may change over time but not across user environments.
2. The Environmental Metric group represents the characteristics of a vulnerability that are relevant and unique to a particular user’s environment.

This module will focus on the Temporal and Environmental metrics.

• Common Vulnerability Scoring System (CVSS-SIG)
  • Calculator
  • Specification Document
  • User Guide
  • Examples
  • Frequently Asked Questions
  • CVSS v4.0 Documentation & Resources
    • CVSS v4.0 Calculator
    • CVSS v4.0 Specification Document
    • CVSS v4.0 User Guide
    • CVSS v4.0 Examples
    • CVSS v4.0 FAQ
  • CVSS v3.1 Archive
    • CVSS v3.1 Calculator
    • CVSS v3.1 Specification Document
    • CVSS v3.1 User Guide
    • CVSS v3.1 Examples
    • CVSS v3.1 Calculator Use & Design
  • CVSS v3.0 Archive
    • CVSS v3.0 Calculator
    • CVSS v3.0 Specification Document
    • CVSS v3.0 User Guide
    • CVSS v3.0 Examples
    • CVSS v3.0 Calculator Use & Design
  • CVSS v2 Archive
    • CVSS v2 Complete Documentation
    • CVSS v2 History
    • CVSS-SIG team
    • SIG Meetings
    • Frequently Asked Questions
    • CVSS Adopters
    • CVSS Links
  • CVSS v1 Archive
    • Introduction to CVSS
    • Frequently Asked Questions
    • Complete CVSS v1 Guide
  • JSON & XML Data Representations
  • CVSS On-Line Training Course
  • Identity & logo usage