The First.org defined the meanwhile widely adopted Common Vulnerability Scoring System (CVSS) to help describing and understanding vulnerabilities better. The CVSS specification is available currently in version 3.1 and can be found here.
In the specification a methodology is presented, that helps to calculate a base score using values depending on specific conditions, taking into consideration impact and exploitability. The exploit score is an expression of the exploitability of the vulnerability. Or in other words: How simple is it, to make use of the vulnerability.
The exploit score is the result of formula that has been compiled using some arcane expert knowhow - reflected in a fixed value - and a set of constants described in the specification in section #7. Together with the Impact Score and the Scope it builds the Base Score.
A. The Formula
Four aspects determine exploitability:
- Attack Vector
- Attack Complexity
- Privileges Required
- User Interaction
Selecting the right values the following formula can be used to calculate the exploitability:
Exploitability = 8.22 * AV * AC * PR * UI
1. Attack Vector (AV)
This metric characterises the context an attacker requires to exploit the vulnerability. In general it can be assumed that the value increases the more remote the vulnerability can be applied. The value can be derived using the following categories:
- Network (N = 0.85): Vulnerable component is accessible over the TCP/IP or comparable network connection and exploit works over that connection.
- Adjacent (A = 0.62): Vulnerable component is bound to a network stack and can be access using the protocol level. However, attacks must be launched from a shared device or any access point within the same network.
- Local (L = 0.55): Something like using keyboard or console or through another user session from a user at the machine.
- Physical (P = 0.2): Attacker requires physical access to the target.
2. Attack Complexity (AC)
This describes the conditions the attacker must hit to launch a successful attack. It has two possible values: low (L = 0.77) and high (H = 0.44). The latter will be selected, when the success of an attack lies partly out of the control of the attacker, e.g. a particular state of another, probably not vulnerable function is required to allow the attack to succeed.
3. Privileges Required (PR)
This describes the sort of privileges the attacker requires to execute the attack. it is distinguished between none (N = 0.85), low (L = 0.62/0.68) or high (H = 0.27/0.5), where low indicates that basic user capabilities are required while high will require specific privileges that go beyond the scope of a standard user, e.g. administrational rights.
4. User Interaction (UI)
This identifies whether the exploit requires a real user to interact with system to allow the attacker to succeed or whether it can be executed without others. Therefor the options are none (N = 0.85) and required (R = 0.62).
B. An Example
Assuming a vulnerability could be exploited over the internet, it requires an expert knowledge to craft the malicious strings but does not require an authenticated session and no user being active, say, just the API. The calculation would look as follows:
- AV: Network = 0.85
- AC: low = 0,77
- PR : none = 0.85
- UI: none = 0.85
Exploitability = 8.22 * 0.85 * 0.77 * 0.85 * 0.85 = 3.89
See also the Impact and Base Score description, to get a better understanding.
Comments
0 comments
Article is closed for comments.