CVSS v4.0 will be published on October 1, 2023, with major changes compared to CVSS v3.1. While the specification may still be subject to change, I have taken a look at the expected changes to the Base Metric Group. The following image summarizes the changes.
Changes of the Base Metric Group in CVSS v4.0 compared to CVSS v3.1
This blog posts discusses these changes in detail and provides example vulnerabilities to clarify the new concepts.
Let’s dive in! 👇
User Interaction
One of the Base metrics that will change is User Interaction. As a web application pentester, I can’t wait for this change to finally happen. Let me tell you why!
Suppose you are pentesting a web application and discover a stored cross-site scripting (XSS) vulnerability. This means that you can execute JavaScript in the browser of any user who visits the vulnerable page. In CVSS v3.0 and v3.1, the User Interaction could take the values None or Required.
So what would you choose here? Obviously, user interaction is required because a user must use the web application. However, no more interaction is required than the typical use of the application.
Compare this to a reflected XSS vulnerability, where the user would have to click a malicious link for the payload to be triggered. The probability of occurrence is much higher for a stored XSS. Thus, it should be rated more critically and have a higher CVSS score.
CVSS v4.0 finally changes the User Interaction metric values to None, Passive and Active. Here’s a summary from the specification:
- Passive: Successful exploitation requires limited interaction, which is considered involuntary, by the targeted user. Examples include stored XSS or CSRF.
- Active: Successful exploitation requires a targeted user to perform specific, conscious interactions. Examples include reflected or self XSS.
Attack Requirements
A new exploitability metric is Attack Requirements. Let’s work out the differences to Attack Complexity!
Up to CVSS v3.1, the only metric for the technical conditions for a successful attack was the Attack Complexity (AC) metric. It could take two values: High and Low. These values often do not reflect the potentially significant differences between the conditions that have to be met.
Thus, CVSS v4.0 is going to add another exploitability metric: Attack Requirements (AT), whose possible values are again High and Low.
Summarized from the specification: Attack Requirements capture the prerequisite execution conditions of the vulnerable system that enable the attack. These differ from security-enhancing conditions in that they emerge naturally as a consequence of the deployment, not explicitly as an attack mitigation.
Two examples from the specification are:
- race conditions that must be won for a successful attack.
- network injection like machine-in-the-middle attacks.
Accordingly, the previous definition of the Attack Complexity has been adjusted. It now measures actions taken by the attacker to actively circumvent existing built-in security-enhancing conditions.
Two examples for Attack Complexity are:
- address space layout randomization (ASLR) or data execution prevention (DEP).
- target-specific secrets that an attacker has to gather before the attack.
Examples
To evaluate the changes, I came up with some more examples and tried to assign them to either Attack Requirement or Attack Complexity. Please note: My reasoning is not an absolute truth, but rather a tendency. I am curious to hear other opinions.
Example 1
- Vulnerability: Java deserialization in the cookie of a web application.
- Condition: The attacker has to find a gadget chain to achieve remote code execution.
- Attack Requirement (AT): High
- Reason: The gadget chain is a natural consequence of deployment.
Example 2
- Vulnerability: A web application is vulnerable to web cache poisoning.
- Condition: To poison the cache, the attacker has to be the first one to send their request after the cache expires.
- Attack Requirement (AT): High
- Reason: The attacker’s request only has a certain probability to poison the cache.
Example 3
- Vulnerability: A web application is vulnerable to cross-site scripting but the web application firewall (WAF) rejects malicious requests.
- Condition: This is a defensive measure that the attacker has to actively bypass.
- Attack Complexity (AC): High
- Reason: The WAF explicitly is a defensive measure.
Example 4
- Vulnerability: A PDF generator is vulnerable to local file inclusion. The service is running with low privileges on the system and cannot read sensitive files.
- Condition: The attacker must find a way to escalate privileges.
- Attack Complexity (AC): High
- Reason: Low-privileged services are a defensive measure.
Example 5
- Vulnerability: SQL injection but your payload is limited to 10 characters by the server.
- Condition: The payload must be short enough.
- AT or AC? Not sure!
- Reason: If the limit emerges from technical restrictions, e.g. SQL data type is
VARCHAR(10), it’s an Attack Requirement. Whereas, if the limit was introduced as a mitigation to SQLi, it is Attack Complexity.
Deployment Consequence or Security Measure?
This leads us to a pitfall: Attack Requirements and Attack Complexity cannot be clearly separated in some cases
Consider an adaptation of the PDF generator vulnerable to LFI from Example 4: The PDF generator now runs in a container, which separates sensitive data of the underlying system from the services.
In general, containers can be considered as attack mitigation because the container is separated from the underlying system. However, they are also often used to provide scalable applications, which makes them a consequence of deployment.
This basically breaks down to the question, whether a feature in a piece of software was written with the purpose to be an attack mitigation or not. But no one apart from the developer certainly knows this.
I have submitted this feedback to first.org and am curious to see whether there will be changes in the final definition.
Machine-in-the-middle
Side note: I appreciate that the official specification is using the word machine-in-the-middle instead of man-in-the-middle. Seems like this is an official term now.
Scope Retirement
The Scope metric will be retired! Instead, the impact metrics will be split into impact on Vulnerable Systems and Subsequent Systems. Let’s look at the differences!
Up to CVSS v3.1, the impact metrics reflected the direct consequences of a successful exploit, measured in Confidentiality, Integrity and Availability (CIA). An additional Scope metric captured whether the vulnerability affects components other than the vulnerable one. If a scope change occurred, the impact metrics reflected either the vulnerable or the impacted components, whichever suffered the most severe outcome.
As you can tell, this is quite inaccurate because it was not possible to know whether the impact refers to the vulnerable or impacted components. CVSS v4.0 will fix this problem by retiring Scope and splitting the impact metrics into Vulnerable Systems and Subsequent Systems.
System of Interest
To understand the difference, let’s first take a look at the definition of a system of interest: A system is formally defined as “the set of computing logic that executes in an environment with a coherent function and set of security policies”. Additionally, systems that solely provide functionality or are exclusively used by a system are considered to be the same system. Example from the specification: A database solely used by a smart speaker is considered a part of the smart speaker system.
If a vulnerability exists in one or more components of such a system, the entire system is considered to be vulnerable, i.e. the Vulnerable System. If there are impacts outside of the Vulnerable System, these should be reflected in the Subsequent System metrics.
Example
Vulnerability: A web application is vulnerable to stored XSS. A successful attack requires the attacker to be authenticated with low privileges.
Impact: The attacker can obtain the session ID of an administrator. This provides access to the CMS, which in turn gives access to the database of the application.
The CVSS vectors look as follows. Changes in the v4.0 vector are emphasized.
-
CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:C/C:H/I:H/A:H - 9.0 Critical
-
CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:P/VC:H/VI:H/VA:H/SC:L/SI:L/SA:N - 8.6 High
A depiction of the above CVSS vectors
Observations and considerations regarding the v4.0 vector:
- Instead of S, C, I and A, there now is VC, VI, VA and SC, SI, SA.
- XSS causes a scope change because it has an impact on the browser, which is a Subsequent System.
- I rated the impact on the browser as Low in confidentiality and integrity: The attacker obtains the session ID. However, this is information from the Vulnerable System, not the browser. As for integrity, the attacker can manipulate the content of the affected browser window.
- The impact on the Vulnerable System is High for every metric: Database and web application are considered to be the Vulnerable System.
Conclusion
Replacing the Scope metric with Subsequent Systems metrics lengthens the CVSS v4.0 vector. However, a finer granularity is achieved through this. If there is no impact on any Subsequent System, all three impact metrics (CIA) can be set to None.
Wrapping Up
This wraps up my blog post on the CVSS v4.0 public preview. Did you find it valuable?
-
Share it with your friends and colleagues!
-
Follow me on Mastodon for early access to my web security content!