What’s new in CVSSv3 vulnerability scoring system?
In June 2015 The Forum of Incident Response and Security Teams (FIRST) has announced the availability of version 3 of the Common Vulnerability Scoring System (CVSS). Let's see the changes it brings in comparison to CVSSv2.
Since years High-Tech Bridge has been using CVSSv2 vulnerability scoring system both for our services and security research. In June 2015 The Forum of Incident Response and Security Teams (FIRST) has announced the availability of version 3 of the Common Vulnerability Scoring System (CVSS).
We have recently migrated ImmuniWeb® web application security testing platform as well as our security advisories to CVSSv3, and we are pretty much happy with the changes came up with the third version. Let’s have a look what’s new it brings to the security industry.
First of all, the format of CVSS score is now slightly different. Let’s take a simple SQL injection vulnerability as an example. CVSSv2 base score has the following format:
7.5 (AV:N/AC:L/Au:N/C:P/I:P/A:P)
While the CVSSv3 base score will look like this:
8.8 [CVSS:3.0/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H]
One of the biggest and most significant changes are four new metrics in the Base Score:
Attack Complexity (AC) – is aimed to replace less comprehensible “Access Complexity” of the second version of CVSS. Attack Complexity metric can have only values now: “High”(H) and “Low” (L), previously available “Medium” (M) is eradiated. On one hand it’s definitely a good change, as in the past a lot of vendors were underscoring the final CVSS score by using overstated and pretty subjective Medium value. Now, it’s much easier to choose between two possible values. However, it provides a little bit less flexibility for some cases, as even pretty common XSS vulnerabilities may have low, medium and high complexity of exploitation.
Privileges Required (PR) – replaces the “Authentication” (Au) metrics from the second version of the standard. It has a little bit less comprehensive, but more adopted to a modern environment, possible values: “None” (N), “Low” (L) and “High” (H). Their meanings and usages are pretty obvious.
User Interaction (UI) – is a completely new and very useful metrics, especially for certain classes of web vulnerabilities, such as XSS and CSRF. It compensates a missing Medium value in Attack Complexity metrics. The values are pretty straightforward: “None” (N) and “Required” (R).
Scope (S) – is also a novation of CVSSv3 that can have “Unchanged” (U) and “Changed” (C) values. The second value shall be attributed if the exploited vulnerability can affect resources beyond the authorization privileges intended by the vulnerable component. For example it’s the case for a vulnerability allowing uploading a web shell on the server and compromising the entire web server and its environment.
All impact metrics now also have slightly different values: None(N), Low(L) and High(H). However, they are very similar to the CVSSv2 ones: None (N), Partial (P) and Complete(C).
So far, the new version is much more adopted for assessing web vulnerabilities, and we strongly recommend using it. CVSSv3 calculator is available here.
Blind Cross-Site Scripting (XSS) attacks in the wild
Continuous monitoring and web security: Are you competitive with Black Hats?
In the comment you reference a completely different scenario, where the resource is a network service that can be used to alter certain files, but do not disrupt the service itself.
You can refer to example No 19 (https://www.first.org/cvss/example s) – CSRF in SearchBlox. Here Availability Impact metric is set, because the Scope metric is not changed and the vulnerability can be used to render the website inaccessible.