CVSS - The Vector String
Vulnerabilities are defined in terms of an ID, a Name, Description and other details including platform info. Consumers of the data in a vulnerability description need to know the conventions for capturing the relevant information about the software affected, how the vulnerability affects other systems, and what has transpired since the information has been made public.
Here we’re going to look at how vendors arrive at a ‘CVSS score’ - yes, there’s a formula for doing this; in fact there are several, and they’ve been honed in successive versions of the CVSS, where the current version is 3.1 and is discussed here.
Here’s an example of a vector string: CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:H
It’s taken from here: https://nvd.nist.gov/vuln/detail/CVE-2022-22977 - nothing specific about this entry in the NVD that makes me share it here...
Vector String Components
Inherently the Vector String is a complex-looking combination of several constituent parts - at a high level 3 ‘groups’:
- Base Metrics
- Environmental Metrics
- Temporal Metrics
Below, we’ll look at how these are constructed.
Base Metric Group
The bulk of the scoring in CVSS and often the most used element is the Base Score. This involves:Exploitability, Impact and Scope of the vulnerability.
AV - Attack Vector: one of
N - Network: attack can originate via a network - often classed as ‘remote exploit’;
A - Adjacent: maximum 1 hop away via a remote technology [WiFi; Bluetooth; Ethernet; etc.];
L - Local: not network, but within the system - attack originates within the system;
P - Physical: requires physical access to the system - usually plugging in a peripheral device
AC - Access Complexity: one of
L - Low: not difficult to exploit - no special conditions necessary (higher risk).
H - High: difficult to exploit and needs certain conditions to be satisfied in order to exploit
PR - Privileges Required: one of
N - None: represents the highest level of risk (no privileges required to gain access!).
L - Low: medium level of risk
H - High: high-level privileges required (lower risk calculation)
UI - User Interaction: one of
N - None: higher risk;
R - Required - lower risk since e.g. social engineering required to gain access
S - Scope
U - Unchanged: exploitation of component will not impact other systems
C - Changed: exploitation affects other elements
Impact Assessment - CIA elements:
C - Confidentiality:
H - high: significant impact on confidentiality of the device);
L - low;
N - None
I - Integrity:
H / L / N
A - Availability:
H / L / N
Until now, the ‘CVSS score’ is a reflection of the impact of the vulnerability on a device. This score should be modifiable if, for example, a patch is or is not available, and whether the threat is imminent (threat actors already have weaponised exploit code). This is where we employ Temporal (and also Environmental - later) metrics.
Here we have 3 specific assignments:
E - Exploit code maturity:
X - not defined;
H - high;
F - functional
P - PoC;
U - unproven
RL - Remediation level:
X - not defined;
U - unavailable;
W - workaround;
T - temp fix;
O - official fix
RC - Report confidence:
X - not defined: high risk;
C - confirmed: high risk;
R - reasonable: lower risk;
U - unknown: lowest risk
Requirements - Impact Subscore Modifiers
Most people will understand the concept of the CIA ‘triad’: Confidentiality; Integrity; Availability - being the cornerstones of how information systems are described, and against how risk can be determined.
So if a system is required to have High Integrity, it may need to be relied on for very accurate data, and any erroneous data could have large consequences. Similarly a system with low availability may be a simple blogging site, and its being down is not a huge problem. These aspects of the system in review can be conveyed in the Impact Subscore Modifiers portion of the Environmental metrics, in the CIA nomenclature and an 'R' postfix.
In order to properly reflect the impact of a vulnerability within a defined system, analysts can apply relevant modifiers to the Base Metrics.
So, we can take the list of Base Metric elements, and apply a ‘M’ as a prefix (such that AV becomes ‘MAV’ - Modified Access Vector), then all the possible values are consistent with the Base Metric ‘Access Vector’. According to the analyst’s requirements per system or environment, the values can be modified for each Base Metric, and a revised CVSS overall score is computed.
Now that we understand the elements of the scoring let’s view the actual NIST / NVD calculator - this time for CVE-2022-30190, and take a look at how modifying certain facets alters the overall score. This is the so-called ‘Folina’ vulnerability in the MS Diagnostic Toolkit.
From this page we see the following structure for the 7.8 CVSS score.
If we however, confirm that there is a workaround, and that practically we can exploit the vulnerability remotely (through social engineering), then we obtain a higher score:
The outcome of this exercise is that of being able to adjust the severity of certain vulnerabilities dependent on our own local environment & configuration (in this case there is a workaround - by adjusting the Windows registry).
References: CVSS 3.1 specification: https://www.first.org/cvss/v3.1/specification-document