CVSS 3.1 Scoring Series - Attack Complexity

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

Classifications

There are only two classifications of Attack Complexity:

1. Low (AC:L)
2. High (AC:H)

A Low (AC:L) classification means that a vulnerability can be exploited consistently without any special circumstances outside of the attacker's control.

A High (AC:H) classification means that a vulnerability can only be exploited if extenuating circumstances beyond the attacker's control are met. This is kind of vague, but it can apply in numerous situations. For instance:

Example 1: An attacker must know about the environment

An OpenShift API server vulnerability can only be exploited if the attacker knows the exact OAuth client secret for the cluster’s authentication integration with an external identity provider (IdP). The secret isn’t guessable - the attacker would first need to compromise another system (e.g., an admin’s workstation or a Git IaC configuration source code repository) to retrieve it. Without that prior knowledge, the exploit fails entirely.

Example 2: An attacker must prepare the target environment

A kernel privilege escalation bug in a Red Hat Enterprise Linux system only triggers reliably when a specific sequence of memory allocations occurs. The attacker might have to run a crafted workload in a loop for hours to cause memory fragmentation, increasing the chance that the vulnerable memory layout or register state appears. Until that preparation succeeds, the exploit has a very low probability of working.

Example 3: An attacker must inject themselves into the logical network path

A flaw in the TLS certificate validation logic of an internal banking application would let an attacker impersonate a Kubernetes API server — but only if they can intercept the traffic between the application client and the API server. This would require the attacker to first compromise a router in the bank’s WAN or gain access to a jump host in the same network path. Without this man-in-the-middle position, the vulnerability can’t be exploited.

Considerations

One major caveat to the Attack Complexity rating is that "the assessment of this metric excludes any requirements for user interaction in order to exploit the vulnerability". Which is kind of funny, in my opinion. If I require a Secret Service agent of the United States Presidential Office to fly Air Force One across the globe to hand-deliver a malware-loaded USB to my target, as long as that USB does its job every time its plugged in (without relying on kernel memory layouts, network traffic, or unknown secret) - I get a Low Attack Complexity rating! Sweet!

Luckily the CVSS scoring will involve user interaction in later classifications, so its still considered when calculating the score. More on that later.

Remembering the Difference

I'll leave you with a final visual on how to know the difference between an AC:L and a AC:H rating. If Lady Luck is on your side (or if she's required at all), to exploit a vulnerability, then its more than likely an AC:H. If you're able to pull off the exploit consistently no matter what the circumstances call for, then you get an AC:L.

Remember, just because an exploit may require a little luck sometimes, does not mean you and your assets are safe from AC:H vulnerabilities. These extenuating circumstances will arise, whether naturally or forcefully.

Hopefully that explains the CVSS 3.1 Attack Complexity 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