October 22, 2015

Vulnerability Assessment According to CVSS 3.0


We have been using this assessment system since we created our vulnerability base and developed our first product, XSpider (I hope there are some who remember it). It is very important for us to maintain the knowledge base that we use in our products and services and keep it up-to-date. Since the guidelines to CVSS metrics do not cover all the possible vulnerabilities, the question arises: what is the best way to make the index reflect the real severity level of a vulnerability?

We are constantly monitoring the development of the standard, so we have been waiting for the final version of CVSS. When I opened the specification, I wanted answers to the following questions. What was improved? What exactly was changed? Can we apply the new standard to our products? And — considering the fact that the database is often managed by new specialists — how much time do you need to master the assessment procedure? And how clear are the criteria?

This article appeared in the course of studying the standard and will, hopefully, help you to understand the new vulnerability assessment procedure.

Milestones in the history of CVSS

The Common Vulnerability Scoring System was developed by the National Infrastructure Advisory Council, which consists of experts from CERT/CC, Cisco, DHS/MITRE, eBay, IBM Internet Security Systems, Microsoft, Qualys, Symantec.

The standard was first published in 2005. The standard's basic principles for calculating the vulnerability index have remained thus far.

Then the Common Vulnerability Scoring System Special Interest Group (CVSS-SIG) supported the standard within the scope of the Forum of Incident Response and Security Teams (FIRST). The group's members are not constrained from supporting and distributing the standard.

The second version of the standard was published in 2007: with a changed indicator list and new final metric formula for a more precise severity assessment of vulnerabilities.

In 2014, such respected organizations as NIST and ITU that develop manuals and standards for telecommunications and information systems issued guidelines for CVSSv2.

Using CVSS metrics for vulnerability assessment was enshrined in PCI DSS and industry-specific standards.

In 2015, FIRST published the third and most recent version of the standard, CVSSv3, which we will explore in this article.

Basic principles

CVSS offers a set of tools to calculate a ten-point scale severity index, due to which security specialists promptly decide how to handle the vulnerability. The higher the index, the more prompt reaction is required.

The standard includes three metric groups:

Base metrics describe vulnerability characteristics that do not change over time and do not depend on the environment. These metrics describe the difficulty of vulnerability exploitation and potential damage for data confidentiality, integrity, and availability.

Temporal metrics correct the total score for confidence in the information about the vulnerability, exploit code maturity (if any), and patch availability.

Environmental metrics are used by IS experts to correct the final score with regard to information environment parameters.

Temporal and Environmental metrics are optional and are used for a more precise threat assessment for a particular infrastructure.

The value of a metric is usually published as a vector (particular values of specific parameters) and a numeric value calculated on the basis of all the parameters by a formula defined in the standard.

New features in CVSSv3

Since comprehensive documentation on CVSSv2 is available [6, 9], we are going to have a more detailed look at modifications to the standard.

Base metrics
System components, for which metrics are calculated
The standard introduces the following terms:

  • vulnerable component — an information system component that is vulnerable;
  • impacted component — a component, whose confidentiality, integrity, and availability may suffer from a successful attack.

In most cases, these two components are the same thing, but there are some vulnerability classes, for which this is not true:

  • sandbox escape;
  • gaining access to user data saved in a browser through a web application vulnerability (XSS);
  • escape from a guest virtual machine.

According to the new standard, Exploitability metrics are calculated for a vulnerable component, while impact metrics — for an impacted one. CVSSv2 had no means to describe a situation where a vulnerable component and an impacted component are different things.

Exploitability metrics

Attack Vector
The Attack Vector metric describes how far an attacker is from the vulnerable object.

CVSSv2
CVSSv3
Metric name
Access Vector (AV)
Attack Vector (AV)
Possible metric values
Network (N)
Network (N)
Adjacent Network (A)
Adjacent Network (A)
Local (L)
Local (L)

Physical (P)

Note: from now on letter mnemonics used for CVSS vector description will be given in brackets.

The previous versions of the standard used the term "Local" to describe any action not affecting the network. The new version provides the following definitions:
  • Local — an attacker needs a local session or some particular action by an authorized user,
  • Physical — and attacker needs physical access to a vulnerable subsystem.
Let's look at two vulnerabilities that have the same CVSSv2 score:


CVE-2015-2363. The win32k.sys Windows driver processes some memory objects incorrectly, which allows an attacker with local system access to gain administrative privileges and execute arbitrary code in kernel mode.

CVE-2015-3007. The Juniper network gateways (SRX series) incorrectly implement the function of disabling password recovery by an unauthorized user through the console port (set system ports console insecure). The vulnerability allows an attacker with physical access to the console port to gain administrative privileges on the device.

The metrics for the same vulnerabilities are different according to the new standard.

Vulnerability
Vector CVSSv3
CVSSv3 score
7.8
6.8

You can see that CVSSv3 assesses vulnerability severity more precisely, without averaging, as CVSSv2 did.

Exploitation difficulty
The Access Complexity metric describes how easy or difficult it is to conduct an attack. The more conditions are to be fulfilled to exploit a vulnerability, the higher is the difficulty level.

CVSSv2
CVSSv3
Metric name
Access Complexity (AC)
Attack Complexity (AC)
Possible metric values
Low (L)
Low (L)
Medium (M)

High (H)
High (H)

"Difficulty level" is a subjective thing, therefore the metric was always interpreted differently. For instance, you can find different Access Complexity scores for the MitM vulnerability in the NVD.

CVE-2014-2993. A vulnerability in the function of SSL certificate verification for the Birebin.com Android application, which allows an attacker to conduct man-in-the-middle attacks and obtain sensitive information. [Access Complexity — Low]

CVE-2014-3908. A vulnerability in the function of SSL certificate verification for the Amazon.com Kindle Android application, which allows an attacker to conduct man-in-the-middle attacks and obtain sensitive information. [Access Complexity — Medium]

CVE-2014-5239. A vulnerability in the function of SSL certificate verification for the Microsoft Outlook.com Android application, which allows an attacker to conduct man-in-the-middle attacks and obtain sensitive information. [Access Complexity — High]

The new standard offers only two difficulty levels with clear criteria in order to make interpretation of this metric easier. All the vulnerabilities allowing MitM attacks are classified as High.

The factors taken into consideration in CVSSv2 by Access Complexity are now handled by two metrics — Attack Complexity and User Interaction.

Authentication / Privileges Required
The metric shows whether authentication is needed to conduct an attack and if so, which one.

CVSSv2
CVSSv3
Metric name
Authentication (Au)
Privileges Required (PR)
Possible metric values
Multiple (M)

Single (S)


High (H)

Low (L)
None (N)
None (N)

Metric calculation based on the number of independent authentication procedures to be undergone by an attacker does not fully show the purpose of the privileges necessary for operation.

You come across the Multiple value in the NVD quite seldom; it is mostly used for vulnerabilities, the information about which is not detailed enough.

CVE-2015-0501. An unspecified vulnerability in Oracle MySQL Server that allows remote authenticated users to affect DBMS availability via unknown vectors related to Server : Compiling’.

The Single value doesn't allow to determine whether you have to be a privileged user to exploit the vulnerability, or standard user authentication is enough.

Let's look at two vulnerabilities that have the same CVSSv2 score:

9.0 (AV:N/AC:L/Au:S/C:C/I:C/A:C)

CVE-2014-0649. The RMI interface in Cisco Secure Access Control System (ACS) does not properly enforce authorization requirements, which allows remote authenticated users to obtain administrator privileges.

CVE-2014-9193. Innominate mGuard allows remote authenticated attackers with restricted administrative rights to obtain root privileges by changing a PPP configuration setting.

The metrics for the same vulnerabilities according to CVSSv3:

Vulnerability
CVSSv3 vector
CVSSv3 score
8.8
7.2

As you can see from the table, CVSSv3 underscores severity of the vulnerabilities that demand authorized access.

User Interaction
The metric shows whether there any user actions needed for a successful attack.

CVSSv2
CVSSv3
Metric name

User Interaction (UI)
Possible metric values

None (N)

Required (R)

CVSSv2 took this factor into account as a part of Access Complexity; the new standard has it as a separate metric.

Let's look at two vulnerabilities that have the same CVSSv2 score:

9.3 (AV:N/AC:M/Au:N/C:C/I:C/A:C).

CVE-2014-0329. The ZTE ZXV10 W300 routers have a hardcoded password — "XXXXairocon" — for the admin account, where "XXXX" is the last four characters of the device's MAC address. A remote attacker can obtain the admin password and use it to get access to the device via the TELNET service.

CVE-2015-1752. Microsoft Internet Explorer does not process memory objects properly, which allows an attacker to execute arbitrary code, when a user clicks a malware link.

Metrics for CVSSv3

Vulnerability
CVSSv3 vector
CVSSv3 score
9.8
8.8

This example shows that CVSSv3 assesses severity more properly.

Scope 
The Scope metric shows whether the vulnerable component and the impacted component are different things, i.e. whether exploitation of the vulnerability allows affecting confidentiality, integrity, and availability of any other system component.

CVSSv2
CVSSv3
Metric name

Scope (S)
Possible metric values

Unchanged (U)

Changed (C)
Let's look at two vulnerabilities that have the same CVSSv2 score: 


CVE-2014-0568. The NtSetInformationFile system call hook feature in Adobe Reader and Acrobat on Windows allows attackers to bypass a sandbox protection mechanism and execute arbitrary code in a privileged context.

CVE-2015-3048. Buffer overflow in Adobe Reader and Acrobat on Windows and MacOS X allows an attacker to execute arbitrary code.

The new standard assigns a higher score to the vulnerabilities, whose vulnerable and impacted components are different things.

Impact metrics
Impact metrics measure the impact on confidentiality, integrity, and availability of the impacted component.

CVSSv2
CVSSv3
Metric name
Confidentiality Impact (C), Integrity Impact (I),
Availability Impact (A)
Possible metric values
None (N)
None (N)
Partial (P)

Complete (C)


Medium (M)

High (H)

The approach to calculating impact metric values has completely changed from quantitative (Partial—Complete) to qualitative (Medium—High).

Let's look at two vulnerabilities that have the same CVSSv2 score:

5.0 (AV:N/AC:L/Au:N/C:P/I:N/A:N).

CVE-2014-0160. TLS and DTLS implementations in OpenSSL do not properly handle Heartbeat Extension packets. This vulnerability allows remote attackers to obtain sensitive information from process memory via crafted packets that trigger a buffer over-read.

CVE-2015-4202. Cable Modem Termination Systems (CMTS) in Cisco uBR10000 routers does not properly restrict access to the IP Detail Record (IPDR) service, which allows remote attackers to obtain sensitive information via crafted IPDR packets.

Vulnerability
CVSSv3 vector
CVSSv3 score
7.5
5.3

As you can see from the example, the qualitative approach allows assessing severity more precisely.

Temporal metrics
Temporal metrics have not been changed much.

Exploit Code Maturity
The Exploit Code Maturity metric measures whether the code or other attacks means are publicly available, or exploitation is only theoretically possible.

CVSSv2
CVSSv3
Metric name
Exploitability (E)
Exploit Code Maturity (E)
Possible metric values
Not Defined (ND/X)
High (H)
Functional (F)
Proof-of-Concept (POC/P)
Unproven (U)
Only the name of the metric has been changed for a more precise one.

Remediation Level
The Remediation Level metric shows whether there are official or unofficial remediation means.

CVSSv2
CVSSv3
Metric name
Remediation Level (RL)
Possible metric values
Not Defined (ND/X)
Unavailable (U)
Workaround (W)
Temporary Fix (TF/T)
Official Fix (OF/O)

This metric was not changed.

Report Confidence
The Report Confidence metric measures the degree of detail of the available vulnerability reports.

CVSSv2
CVSSv3
Metric name
Report Confidence (RC)
Possible metric values
Not Defined (ND)
Not Defined (X)
Unconfirmed (UC)

Uncorroborated (UR)


Unknown (U)

Reasonable (R)
Confirmed (C)
Confirmed (C)

The new standard has more precise criteria for labeling vulnerability reports:

  • Unknown — the reports indicate that the cause of the vulnerability is unknown, or reports may differ on the cause or impacts of the vulnerability;
  • Reasonable — the reports allow judging on vulnerability causes with enough confidence (for example, the report gives and example of exploit code);
  • Confirmed — the vendor has confirmed the pretense of the vulnerability or there is a publicly available functional exploit.

Temporal metrics impact 
Let's look at the following vulnerability.

CVE-2015-2373.The Remote Desktop Protocol (RDP) server service in Microsoft Windows allows remote attackers to execute arbitrary code via a series of crafted RDP packets.

Version of the standard
CVSS vector
Base score
Final score
CVSSv2
10.0
7.4
CVSSv3
9.8
8.5

As you can see, the new standard has a modified formula: the overall impact of Temporal metrics on the final score has been decreased.

Environmental metrics
Environmental metrics were modified in order to simplify the assessment of environmental impact on the final score.

Security requirements
Environmental metrics allow to define which characteristic of a target component (confidentiality, integrity or availability) has the most impact on the operation of the business system or business processes.

CVSSv2
CVSSv3
Metric name
Confidentiality Requirement (CR), Integrity Requirement (IR),
Availability Requirement (AR)
Possible metric values
Not Defined (ND/X)
High (H)
Medium (M)
Low (L)

This metric was not changed.

Adjusted base metrics
Exploitability and potential damage within the context of a company's IT infrastructure.

CVSSv2
CVSSv3
Metric name

Modified Attack Vector (MAV)
Modified Attack Complexity (MAC)
Modified Privileges Required (MPR)
Modified User Interaction (MUI)
Modified Scope (MS)
Modified Confidentiality (MC)
Modified Integrity (MI)
Modified Availability (MA)
Possible metric values

Values defined in the section Base Metrics or Not Defined (X).

This metric can boost the final score if application configuration is weak, or to lower it if some compensating measures are implemented, which decrease exploitation risk or potential damage from a successful attack.

Eliminated metrics
The following metrics are excluded from the standard:

Collateral Damage Potential, CDP. A qualitative assessment of potential damage for equipment or other assets upon vulnerability exploitation. This metrics considered financial damage as a result of production downtime or revenue loss.

Target Distribution, TD. Percentage of systems in a company's information environment that can be affected by vulnerability exploitation.

Other modifications
Vulnerability Chaining
CVSS was initially designed for the assessment of each vulnerability separately. However, it is possible to cause more damage by exploiting several vulnerabilities sequentially.

The new standard recommends using CVSS metrics to describe vulnerability chains, combining exploitation characteristics of one vulnerability with impact metrics of another.

Let's go through an example.

Vulnerability 1. Local privilege escalation; no interaction with the user is required.
Vulnerability 2. Allows an unauthorized attacker to remotely modify files of a vulnerable component. For a successful attack, certain actions are required from the user, e.g. clicking a malicious link.

Vulnerability
CVSSv3 vector
CVSSv3 score
Vulnerability 1
8.4
Vulnerability 2
4.3

If upon the exploitation of vulnerability 2 it is possible to modify files in a way that leads to the exploitation of vulnerability 1, we have a vulnerability chain with the following characteristics.

Vulnerability
CVSSv3 vector
CVSSv3 score
Vulnerability 1 —> Vulnerability 2
8.8

As we can see, the final score of a chain can be higher than the severity level of each vulnerability taken separately.

Qualitative Severity Rating Scale
Different companies have elaborated various approaches to calculating the qualitative severity rating based on CVSS metrics:
  • Nvd.nist.gov: 0—3.9 Low; 4.0—6.9 Medium; 7.0—10.0 High;
  • Tenable: 0—3.9 Low; 4.0—6.9 Medium; 7.0—9.9 High; 10.0 Critical;
  • Rapid 7: 0—3.9 Moderate; 4.0—7.9 Severe; 8.0—10.0 Critical.
The CVSSv3 standard recommends using the following qualitative rating scale:

Quantitative score
Qualitative rating
0
None
0.1—3.9
Low
4.0—6.9
Medium
7.0—8.9
High
9.0—10.0
Critical

The most significant changes
In this clause, we are going to summarize briefly the conclusions and outline the most significant modifications to CVSSv3.
  • The the following terms were introduced: a vulnerable component and an impacted component. Exploitability metrics are calculated for a vulnerable component, while impact metrics — for an impacted one.
  • Physical access is added as a step required for exploitation.
  • The User Interaction metric was introduced.
  • The Authentication metric was revised. It is possible now to consider the necessity of privileged access to a system.
  • The Impact metric shifted from quantitative to qualitative values.
  • The Environmental metrics Collateral Damage Potential and Target Distribution were replaced by more illustrative Modified factors.
  • Guidance on assessing multiple vulnerabilities is provided.
  • The Qualitative Rating Scale is brought to standard.
Due to the proposed assessment approach, infosec specialists can get a more in-depth look at factors that impact on vulnerability severity, so companies that deal with security issues will most likely implement the standard before long.

New metrics has little impact on the process of assessment. Some of them simplified the process (Attack Complexity, User Interaction). Others, such as exploitation scope, qualitative assessment of the impact on confidentiality, integrity, and availability, are a little bit more difficult.

For those who wants to master the vulnerability assessment process according to CVSS, we would recommend, apart from CVSSv3 Specification [1], to refer to CVSSv3 Examples [3] and the CVSSv3 User Guide [2] that provide typical examples of how to use the standard to assess a vulnerability.

A number of companies (IBM X-Force and Security Database among them) have already implemented the standard in their products and services. In Positive Technologies, we are in the process of laying the groundwork for using CVSSv3 in our corporate knowledge base and in MaxPatrol, one of our products.

Bonus: CVSS metrics for named vulnerabilities
Starting from the Heartbleed vulnerability in OpenSSL that got a recognizable name and a nice logo with a bleeding heart, IS experts created a new trend towards naming vulnerabilities, especially those ones related to SSL/TLS. Let's find out how dangerous these named vulnerabilities are.

The Heartbleed vulnerability in OpenSSL (CVE-2014-0160). The TLS and DTLS implementations in OpenSSL do not properly handle Heartbeat Extension packets. This vulnerability allows remote attackers to obtain sensitive information from process memory via crafted packets that trigger a buffer over-read.

Version of the standard
CVSS vector
Base score
Final score
CVSSv2
5.0
4.1
CVSSv3
7.5
7.0

The BERserk vulnerability in Mozilla NSS (CVE-2014-1568). Mozilla Network Security Services (NSS) does not properly parse ASN.1 values in SSL certificates, which makes it easier for remote attackers to spoof RSA signatures in a certificate and gain unauthorized access to sensitive data.

Version of the standard
CVSS vector
Base score
Final score
CVSSv2
8.8
6.5
CVSSv3
7.4
6.4

The POODLE vulnerability in the SSLv3 protocol (CVE-2014-3566). The SSLv3 protocol, as used in OpenSSL and other products, uses nondeterministic CBC padding, which makes it easier for man-in-the-middle attackers to obtain cleartext data via a padding-oracle attack. The vulnerability was later found in several TLS implementations (CVE-2014-8730).

Version of the standard
CVSS vector
Base score
Final score
CVSSv2
4.3
3.5
CVSSv3
3.1
2.8

The Sandworm vulnerability in Windows OLE (CVE-2014-4114). A vulnerability in Microsoft Windows OLE, which allows a remote attacker to execute arbitrary code when a user opens a file containing a crafted OLE object.

Version of the standard
CVSS vector
Base score
Final score
CVSSv2
9.3
7.7
CVSSv3
7.8
6.8

The Shellshock vulnerability in Bash (CVE-2014-6271, CVE-2014-7169). A vulnerability in GNU Bash caused by improper processing of strings after function definitions in the values of environment variables. The vulnerability can be exploited via various attack vectors — DHCP, HTTP, SIP, FTP, SMTP — and allows an attacker to execute arbitrary bash code.

Version of the standard
CVSS vector
Base score
Final score
CVSSv2
10.0
8.3
CVSSv3
9.8
9.1

The FREAK vulnerability in the OpenSSL (CVE-2015-0204). The ssl3_get_key_exchange function in OpenSSL allows decreasing encryption strength of the SSL/TLS connection (RSA to RSA_EXPORT). A successful attack allows an attacker to decode these connections.

Version of the standard
CVSS vector
Base score
Final score
CVSSv2
4.3
3.2
CVSSv3
3.7
3.2

The GHOST vulnerability in glibc (CVE-2015-0235). Heap-based buffer overflow in the function __nss_hostname_digits_dots в glibc that allows an intruder to execute arbitrary code by calling the function gethostbyname или gethostbyname2.

Version of the standard
CVSS vector
Base score
Final score
CVSSv2
7.6
6.3
CVSSv3
8.1
7.5

The Venom vulnerability in visualization systems (CVE-2015-3456). A vulnerability in QEMU emulators used in various virtualization systems. It allows an attacker to escape a guest virtual machine and execute code in the host system.

Version of the standard
CVSS vector
Base score
Final score
CVSSv2
7.7
6.0
CVSSv3
9.0
8.1

The Logjam vulnerability in the TLS protocol (CVE-2015-4000). A vulnerability in the TLS protocol allows an intruder to weaken TLS connection cipher (from DHE to DHE_EXPORT). A successful attack allows an attacker to decode these connections.

Version of the standard
CVSS vector
Base score
Final score
CVSSv2
4.3
3.2
CVSSv3
3.7
3.2

29 comments:

  1. This comment has been removed by a blog administrator.

    ReplyDelete
  2. This comment has been removed by a blog administrator.

    ReplyDelete
  3. This comment has been removed by a blog administrator.

    ReplyDelete
  4. This comment has been removed by a blog administrator.

    ReplyDelete
  5. This comment has been removed by a blog administrator.

    ReplyDelete
  6. This comment has been removed by a blog administrator.

    ReplyDelete
  7. This comment has been removed by a blog administrator.

    ReplyDelete
  8. This comment has been removed by a blog administrator.

    ReplyDelete
  9. This comment has been removed by a blog administrator.

    ReplyDelete
  10. This comment has been removed by a blog administrator.

    ReplyDelete
  11. This comment has been removed by a blog administrator.

    ReplyDelete
  12. This comment has been removed by a blog administrator.

    ReplyDelete
  13. This comment has been removed by a blog administrator.

    ReplyDelete
  14. This comment has been removed by a blog administrator.

    ReplyDelete
  15. This comment has been removed by a blog administrator.

    ReplyDelete
  16. This comment has been removed by a blog administrator.

    ReplyDelete
  17. This comment has been removed by a blog administrator.

    ReplyDelete
  18. This comment has been removed by a blog administrator.

    ReplyDelete
  19. This comment has been removed by a blog administrator.

    ReplyDelete
  20. This comment has been removed by a blog administrator.

    ReplyDelete
  21. This comment has been removed by a blog administrator.

    ReplyDelete
  22. This comment has been removed by a blog administrator.

    ReplyDelete
  23. This comment has been removed by a blog administrator.

    ReplyDelete
  24. This comment has been removed by a blog administrator.

    ReplyDelete
  25. This comment has been removed by a blog administrator.

    ReplyDelete
  26. This comment has been removed by a blog administrator.

    ReplyDelete
  27. This comment has been removed by a blog administrator.

    ReplyDelete
  28. This comment has been removed by a blog administrator.

    ReplyDelete
  29. This comment has been removed by a blog administrator.

    ReplyDelete