CVSS 3.1 Scoring Series - Privileges Required

In this part of my CVSS 3.1 Scoring Series, I will explain how the "Base Score - Exploitability - Privileges Required" classifications work.

Classifications

There are three classifications of Privileges Required:

1. None (PR:N)
2. Low (PR:L)
3. High (PR:H)

A None (PR:N) classification means that an attacker can be completely unauthorized prior to a successful attack, and does not require any access to settings or files of the vulnerable system to carry it out.

A Low (PR:L) classification means that an attacker must have basic user capabilities that would be accessible under normal BAU for a normal user in order to exploit a vulnerability.

A High (PR:H) classification means that an attacker must have elevated privileges (such as administrator) over the vulnerable component that would allow access to component-wide settings and files in order to carry out a successful attack.

Example 1: PR:N

An interesting example is CVE-2014-2005, where an attacker with physical access to a machine can bypass authentication when Sophos Disk Encryption doesn't have a login screen. The reason this is interesting is that even though you need physical access to the machine (AV:P if you've been following along in this series), you technically need no rights or privileges. Many factors get combined to produce the one CVSS score, and I find it interesting that a high barrier to entry of AV:P is lessened by the absence of required permissions (PR:N).

Example 2:  PR:L

Typically you might see these associated with XSS attacks or anything that the browser will load as a malicious link. For instance, I may have an account with a social media application giving me basic user entitlements to post comments or articles. Within a comment, I add a <script> tag that loads malicious JavaScript whenever someone views my comment. I required basic privileges to post (cannot post anonymously), but I was able to exploit an XSS vulnerability.

Example 3: PR:H

You will normally see this associated with large configuration-based vulnerabilities such as loading entirely new web applications into a web server. Normally when an attacker already has high privileges to an application like this, they are actually attempting to "break out" of the application and get rights to the underlying system. Another good example is a container escape that requires root permission to run. You've already compromised the whole container since you are root, but you're really leveraging a vulnerability of PR:H inside of it to compromise the layer below you.

Considerations

It is important to remember that the Privileges Required score describes the level of permissions an attacker must have *before*  successfully exploiting the vulnerability in the component. Reading through a vulnerability scoring and quickly glancing over "Privileges ... None" may make you think that an attacker gains no extra permissions after a successful exploit. However, this is actually the worst rating classification because the actor can attack a vulnerable system with no prerequisite privileges required.

Hopefully that explains the CVSS 3.1 Privileges Required scoring! If you have any questions, feel free to reach out to me on LinkedIn or via email (chris@sinclairsecurity.com). See you next time!

References

More information on this scoring can be found in the official specification: FIRST CVSS 3.1 Spec