Understanding the CVSS Metrics for Exploitability

Instead of fixing hundreds of CVEs, manufacturers can provide enough security measures to make the exploitation unlikely. The decrease of the CVSS metrics is a useful indicator how effective the security measures are. This post is about understanding the CVSS metrics.

Understanding the CVSS  Metrics for Exploitability

The Importance of Exploitability Metrics

The ultimate goal of the CRA is that products "shall be made available on the market without known exploitable vulnerabilities" (Annex I.I.2a) - relative to the manufacturer's risk assessment. Given the available security measures for a specific product, we as the manufacturer must answer a crucial question.

How likely is the exploitation of a vulnerability? Do we have to do anything about the vulnerability?

If enough security measures make the exploitation unlikely, we will not do anything about a vulnerability. Otherwise, we must mitigate the threat emanating from the vulnerability by eliminating the threat, by introducing a security measure to reduce the threat or by fixing the vulnerability.

The exploitability metrics of the Common Vulnerability Scoring System (CVSS) help manufacturers answer the crucial question and select appropriate mitigation methods. The CVSS score ranges from 0.0 to 10.0 and measures the severity of a vulnerability. The higher the severity score is, the more easily it can be exploited and the more likely the exploitation is. It is not a logical implication but it's the best indicator we have.

The exploitability metrics - attack vector, attack complexity, privileges required and user interaction - are one part of the CVSS base metrics. The other two parts are Scope and Impact Metrics, which I'll briefly explain in the section Decoding CVSS Vector Strings. The base metrics rate a vulnerability in the environment (desktop, mobile, web, embedded, etc.) where attackers can exploit the vulnerability most easily and where they can cause the worst damage.

The base metrics don't take existing security measures or the special operating environment of an embedded system into account. This is where the modified base metrics come into play. If we put enough security measures in place to make a network or adjacent attack unlikely, we can lower the base metrics AV:N to the modified base metrics MAV:L. See the section Modified Base Metrics for Exploitability for more details.

As a running example, I'll use heat pumps in private homes. You'll find a short description of a notoriously insecure heat pump in my post Running Example for CRA: Heat Pumps in Private Homes.

Base Metrics for Exploitability

The original definitions are from the section Exploitability Metrics of the CVSS 3.1 specification.

Attack Vector (AV)

Attack Vector: Network (AV:N)

The vulnerable component is bound to the network stack [...] Such a vulnerability can be thought of as an attack being exploitable at the protocol level one or more network hops away (e.g., across one or more routers). An example is an attacker causing a denial of service (DoS) [...]

An attack on the heat pump must happen from outside the home network - to be at least one network hop away. An attacker could gain access to the manufacturer's admin panel and flood the heat pump with MQTT messages. This classical DoS attack violates the CRA's availability property. If you think such an attack is unlikely, read in Episode 61 of my newsletter how easy it is to start and stop cars remotely through the manufacturer's admin panel.

Attack Vector: Adjacent (AV:A)

The vulnerable component is bound to the network stack [...] An attack must be launched from the same shared physical [...] or logical [...] network or from within [an VPN].

If the attacker runs a DoS attack from inside the home network, we have an example of an adjacent attack. There is no network hop between the attacking device and the heat pump.

The relevant characteristic of network and adjacent attacks is that an attacker sends messages to the heat pump. The messages can be malformed to elicit a buffer overflow allowing remote code execution or to simply crash the heat pump. The attacker may just flood the heat pump with messages. The attack can happen on the application, transport, internet or link layer. That's what "bound to the network stack" or "exploitable at the network level" means.

Attack Vector: Local (AV:L)

The vulnerable component is not bound to the network stack and the attacker's path is via read/write/execute capabilities. Either:
- the attacker exploits the vulnerability by accessing the target system locally (e.g., keyboard, console) or remotely (e.g., ssh); or
- the attacker relies on User Interaction by another person required to exploit the vulnerability [...]

The heat pump runs an ssh server so that service engineers can log in to debug problems. An attacker cracks the password by a brute-force attack and logs in as root to the heat pump via ssh. The attacker can read and write any file and execute any program. He can encrypt the root filesystem and demand ransom. He can heat up all rooms to 35 °C in the middle of the summer or switch off warm water. In short, he owns the heat pump.

Why isn't this a network attack? First, the attacker doesn't exploit a vulnerability in the network stack. Second, he needs read, write or execute permissions to do his evil deed. Such permissions are not needed in a network attack.

In the second attack path, another person is tricked into performing an action that enables the attacker to exploit a vulnerability. Phishing attacks are the textbook example, but they don't apply well to heat pumps or other machines. You'll see a better example in User Interaction: Required.

Attack Vector: Physical (AV:P)

The attack requires the attacker to physically touch or manipulate the vulnerable component.

The heat pump has a serial port on the main board inside the casing. An attacker must remove the front cover and make a custom serial cable before he can start the serial console. He could break into the U-Boot prompt and remove the boot script, start a different Linux image or erase the disk partitions.

Attack Complexity (AC)

Attack Complexity: Low (AC:L)

Specialised access conditions or extenuating circumstances do not exist. An attacker can expect repeatable success when attacking the vulnerable component.

The attack complexity is low,

  • if the heat pump stops working properly when flooded with MQTT messages,
  • if the attacker can execute malicious code when an application runs into a buffer overflow due to a malformed MQTT message, or
  • if the password for ssh login is empty, written in the user manual or easy to guess.

If the attacker requires neither special privileges nor the interaction from the homeowners, the attack complexity is low.

Attack Complexity: High (AC:H)

A successful attack depends on conditions beyond the attacker's control. That is, a successful attack cannot be accomplished at will, but requires the attacker to invest in some measurable amount of effort in preparation or execution against the vulnerable component [...]

As described in Privileges Required: High, the manufacturer generates a strong root password unique to each heat pump and stores the passwords safely in a password manager. Social engineering might be the most promising path although with very little prospect for success. Figuring out a password would cost an attacker a significant effort. Such an attack needs a serious "effort in preparation", because the attacker must overcome strong security measures.

If an attacker must restart the heat pump many times to elicit a race condition, the attack complexity is certainly high. Such an attack needs a serious "effort in execution".

A man-in-the-middle attack is also considered highly complex. An attacker places a server between the official server and the heat pumps. The server in the middle manipulates the messages the heat pumps exchange with the official server.

In general, the attack complexity increases, if the attack vector, the privileges required or the user interaction make an attack more difficult. The more security measures make an exploitation harder the higher the attack complexity is.

Privileges Required (PR)

Privileges Required: None (PR:N)

The attacker is unauthorised prior to attack, and therefore does not require any access to settings or files of the vulnerable system to carry out an attack.

An attacker doesn't need any authorisation to control the heat pump from its HMI. He could use the available information to reverse-engineer the MQTT messages exchanged with the server. Or, he could try to enter the configuration mode.

Heat pumps have a configuration mode, which the technician uses during commissioning - e.g., for adapting the heating curve. When the technician commissioned my heat pump, he told me the password xymaster right away, where xy are the first two letters of the manufacturer name. Other manufacturers print this "password" or service code in the user manual. If the password is hard-coded or can be figured out with a bit of social engineering, the CVSS specification strongly recommends to set the privileges required to None instead of Low.

The situation is exacerbated if the HMI application runs with root privileges. If an attacker succeeds in executing code because of a buffer overflow in the HMI application, he can remove all files or encrypt the root filesystem. He can do everything with the heat pump. This is a case of privilege escalation.

Privileges Required: Low (PR:L)

The attacker requires privileges that provide basic user capabilities that could normally affect only settings and files owned by a user [...]

Let us ramp up security a notch. We prevent privilege escalation by running the HMI application with normal-user privileges. Even if an attacker can execute malicious code due to a vulnerability, he can only manipulate files or run programs of the normal user. He cannot manipulate system files.

When the heat pump receives a request to enable the diagnostic mode, homeowners must confirm the request by entering their username and password. If the attacker doesn't have the homeowners' credentials, he cannot leverage the diagnostic mode for exploitation. This is also an example where user interaction is required.

Privileges Required: High (PR:H)

The attacker requires privileges that provide significant (e.g., administrative) control over the vulnerable component allowing access to component-wide settings and files.

To gain "significant (e.g., administrative) control" over the heat pump, an attacker needs root privileges. Then, he could manipulate or remove every file.

One way to get root privileges is to crack the password for ssh login. However, we took precautions. As the manufacturer, we generate a strong password unique to each heat pump. We store the passwords in a password manager, to which only a few select people have access. Hence, the privilege required to exploit a root shell is high.

User Interaction (UI)

User Interaction: None (UI:N)

The vulnerable system can be exploited without interaction from any user.

Once logged in to the admin panel, service technicians can enable the diagnostic mode of any heat pump. They click a button and the server sends a simple MQTT message to the heat pump. Technicians can do this without any interaction from the homeowner. So can an attacker - once he can send the right message to the heat pump.

As mentioned for a network attack, one of the easiest ways is to get access to the admin panel. An alternative could be to exploit a vulnerability in the encryption of MQTT messages. Another alternative could be to record messages to the heat pump and replay them.

User Interaction: Required (UI:R)

Successful exploitation of this vulnerability requires a user to take some action before the vulnerability can be exploited.

Let us make exploiting the diagnostic mode a bit more difficult. The attacker cannot enable the diagnostic mode without the explicit confirmation of the homeowner. The attacker requests the enabling of the diagnostic mode, which the homeowner must accept by clicking on a button in the app or in the HMI of the heat pump. If the homeowner rejects the request, the attacker will never enter the diagnostic mode.

The attacker must deceive the homeowner into believing that he is a technician and make the owner accept the request. He needs a second person to be present locally. This is an example of the second condition of the local attack vector.

Decoding CVSS Vector Strings

The CVSS base metrics of a CVE are encoded in a vector string.

The CVSS base metrics consist of metrics for exploitability, scope and impace. By now, you should be able to decode the exploitability part AV:L/AC:L/PR:H/UI:N as attack vector Local, attack complexit Low, privileges required High and user interaction None.

The scope metric has two values Unchanged (U) and Changed (C), where Changed is more severe than Unchanged. Let us assume that the base Linux system of the heat pump runs the HMI and control applications in a container. The container is a trust boundary. The applications and the base Linux system run in different security scopes. If a vulnerability allows an attacker to manipulate files in the Linux from the applications inside the container or vice versa, the scope has Changed. If a vulnerability doesn't enable crossing of a trust boundary, the scope remains Unchanged.

The impact metrics rate the confidentiality C, the integrity I and the availability A. Each metric can have the values High (H) (total loss), Low (L) (some loss) and None (N) (no loss). The impact metrics correspond to the CRA product properties confidentiality protection (Annex I.I.2e), integrity protection (Annex I.I.2f) and Availability of Essential and Basic Functions (Annex I.I.2h).

Of course, an online CVSS vector decoder is available. We enter the CVSS vector string in the input field at the top and the tool returns the decoding.

Modified Base Metrics for Exploitability

A critical CVE in the MQTT stack might have the following vector string resulting in a CVSS base score of 9.8.

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H

All metrics except for the scope S:U have their worst value. If the scope were Changed (C), we would have a "perfect" 10.

The base score of 9.8 doesn't consider any security measures specific to the heat pump. Here are some of the security measures the manufacturer implemented.

The heat pump is not reachable from the public Internet. It connects to the MQTT server every 15 minutes, sends its status data, waits a short time for some commands from the homeowner's app and disconnects again. Before the heat pump can establish a connection with the server, it must authenticate.

This security measure makes a network or adjacent attack unlikely. It also makes the successful repetition of attacks more difficult. We could modify the base metric AV:N to MAV:L and AC:L to MAC:H. When we add the modified values to the vector string

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H/MAV:L/MAC:H

and feed the string into the decoder, the resulting environmental score is 7.4 down from the base score of 9.8.

Furthermore, this security measure makes a total loss of availability (A:H) unlikely. We can add MA:L to the vector string, which brings down the environmental score to 6.9. As the MQTT communication is encrypted and the MQTT client must authenticate with the server on establishing a connection, we could modify the base score to MC:N and MPR:H. The environmental score is now 4.7.

We have long reached the point where we can accept the threat from this CVE. We can wait for the maintainers of the MQTT component to fix the flaw. Our heat pumps receive the fix with the next regular update.

💡
As the manufacturer, we neither have to fix the CVEs ourselves nor have to hire someone to do so. Instead, we can provide enough security measures to make an exploitation unlikely. The CVSS exploitability metrics are a useful indicator which security measures are most effective. They are the best indicator we have.

Read next