Assigning a severity to a vulnerability is an important part when describing the vulnerability in the report. It helps the organization to understand how important a vulnerability is and allows for prioritizing the remediation actions. It is obvious that most organizations will focus on a high severity vulnerability first rather than medium or low.
Assigning a severity can be done based on “the feeling” of a penetration tester about how dangerous a vulnerability is or in a more organized and standardized way.
The first method is subject to interpretation. The same vulnerability can have different severity assigned depending on who discovers it.
The second method leaves much less room for interpretation and therefore I will describe it in this article.
!This is the third out of six articles in the series “Web application Penetration Testing Report”. If you haven’t read the previous one you can find it by the title: What does a good executive summary look like in a penetration testing report?. You will understand what to expect out of a good executive summary section of a penetration testing report.
To assign severity in Zigrin Security, we use the Common Vulnerability Scoring Standard (CVSS). The first version of this standard was introduced back in 2005. Now, as of 2022, the latest version is 3.1, and this is the version I will cover here.
To quickly get a grasp of the CVSS aspects we created the following cheat sheet:
First of all, with CVSS a vulnerability has a severity assigned, not a risk (more about it in the next articles). Severities are assigned based on the score calculated and are the following:
- Critical 10.0 – 9.0
- High 8.9 – 7.0
- Medium 6.9 – 4.0
- Low 3.9 – 1.0
- None – 0
So for example, if a vulnerability results in a score of 7.1 its severity is High.
There are three main ways to calculate the score. The Base Score, Temporal Score, and Environmental Score. The most popular is the Base Score so I will focus on this one for now.
To calculate the Base Score, a penetration tester has to take eight factors into account:
The three main factors of the CVSS (on the right side of the screenshot above) represent the impact of a vulnerability using the CIA triad:
This allows distinguishing the impact on each of those aspects separately where a penetration tester has to select None, Low, or High for all parts of the CIA triad.
For example, if a vulnerability allows stealing some limited data, then Confidentiality would be Low, and both Integrity and Availability are None.
On the other hand, confidentiality would be None, and Integrity and Availability would be High if a vulnerability allows modifying all data in the database and breaking the application making it unavailable to users.
There can be all variations of those factors depending on the vulnerability impact.
Next, we will go to the left side of the screenshot. The Attack Vector basically explains where the attacker has to be placed to exploit the vulnerability.
In web applications, most vulnerabilities have CVSS Attack Vector assigned as Network. This is because web applications are accessible over an internal network or Internet most of the time. This means that the attacker just needs network access to the application.
An Adjacent Attack Vector is a situation where exploitation of the vulnerability requires the attacker to be in a specific logical subnet, physical network (like Bluetooth), or a privileged area like an administrative network connected over a VPN.
Local Attack Vector in CVSS is whenever the attacker has to have access to the machine where the vulnerability resides to exploit it. Usually, these are privilege escalation vulnerabilities in Windows, Linux, and other operating systems but not only.
A Physical attack vector is when an attacker needs to have physical access to the machine where a vulnerable component exists. If you have a tablet in a waiting room of your company, and there is a vulnerability that can be exploited, this is a good example of a physical attack vector.
Attack complexity reflects external factors outside of the attacker’s control that has to occur to exploit the vulnerability. This could mean a custom configuration or another vulnerability that needs to exist and be exploited.
This CVSS factor describes what permissions the attacker has to have to exploit a vulnerability. If the vulnerability is exploitable only by administrators, then it’s High, for regular users it’s Low, and for unauthenticated visitors it’s None.
CEO, Cybersecurity Expert
Let’s talk about securing your web application
Book a chat with me
The User Interaction factor in CVSS describes if other users have to conduct some action on the application that would allow the attacker to exploit the vulnerability. A typical example here is an XSS vulnerability, where a victim user has to at least open a specific page or click on a link.
The final factor of a CVSS 3.1 described in this article is a Scope, very often difficult to understand. The scope is assigned as Changed in situations where a vulnerability exists in one component but can impact a different component. An example of such a situation is a command injection vulnerability where the attacker gets access to the operating system of a vulnerable component. In that case, the vulnerable component is a web application but the impacted component is the operating system and internal network.
Other examples are XSS vulnerabilities where a vulnerable component is a web application and the impacted component is a user’s browser.
When a vulnerable component is the same as the impacted component, the Scope of CVSS should be Unchanged. An example of scope unchanged would be an authentication bypass in a web application. A vulnerable component is the authentication functionality of the application and the impacted component is the application itself.
CVSS Vector String
All of those factors are part of the CVSS Base Score, which then reflects the severity of the vulnerability. There are certain math equations involved in it but I won’t go into the details of it as it is not required to understand this scoring system.
This system may seem complex, and overwhelming but I will show you an easy way to understand the score when you see it in a penetration testing report or calculate a severity when you find a vulnerability.
When a company uses a CVSS for findings in a penetration test, you will most likely see some strange text next to every finding. Something like:
This is a shortcut for all factors I described above. You can see a version of CVSS used to calculate the score and the factors themselves. For example, AV:N stands for Attack Vector assigned as None, AC:L stands for Attack Complexity assigned as Low, and so on.
You don’t need to remember all of that. The best way to see the exact factors is to use an online calculator provided by the FIRST organization.
Simply, open a calculator and provide the CVSS shortcut in an URL like that:
You will see a nice way of visualizing all of the vulnerability factors together with the final score and severity.
Now you can understand better how a severity was calculated during a penetration test of your web application.
Additional articles about the CVSS severity scoring system can be found below:
- Common Vulnerability Scoring System SIG – https://www.first.org/cvss/
- CVSS 3.1 Calculator – https://www.first.org/cvss/calculator/3.1
- Current CVSS Score Distribution For All Vulnerabilities with assigned CVE – https://www.cvedetails.com/cvss-score-distribution.php
! In the next article, I will describe what are the important elements of a finding description section in a pentest report.
Is this article helpful to you? Share it with your friends.