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

Crime Doesn't Pay (Except when it Does)

Situation

Imagine you are a nurse in a large regional hospital. Your worn insoles make your feet ache, the crick in your neck doesn't seem to go away no matter how many pills you down, and your fourth cup of coffee keeps you alert enough to guard over dozens of lives. You shuffle over to your "workstation on wheels" (WOW) to input the time you gave a patient his fourth Warfarin. You go to swipe your badge and notice the following on your screen:

Its not just you. Other patient care faculty are looking up from their desks wondering if its some kind of prank on the resident gone awry. Soon, the floor is abuzz with doctors coming out of their offices and hurried footsteps rushing down the hall to see what can be done. Within minutes, the rude IT guy is looking at some computers at the nurses' station and gets a call from his boss's boss. The call does not go well. Panic sets in as patients realize something is amiss. Is the life-saving surgery able to go forward without the doctor being able to access the patients blood type? Is the diagnosis that a family hangs onto with bated breath able to be released today, or will the nightmare continue indefinitely?

Congratulations, you are a victim of Ransomware.

What is Ransomware?

Ransomware is a malicious software or program that infects your computer with no intention of stealing information. Instead, it purposefully removes your access to any data by encrypting the contents of the computer with encryption keys and passphrases that could never be guessed as long as the universe shall live. The way it actually works looks something like this:

This is a clever way to encrypt files and essentially throw away the key until payment is made.

Normally, a scary-looking window will appear stating that everything is encrypted and to pay the hacker to get your data decrypted. There will usually be a nuclear-countdown-style timer showing how much time you have left to pay until the files are wiped, or the hacker will delete the corresponding private key that would've decrypted the used symmetric key. So what do they expect? Payment made through a secret channel to a secret location.

Anonymity

Ransomware is interesting because you actually get to talk with your hacker! Indeed, communication between victim and attacker must be established in order to accomplish steps 7 and 9 above.

Most ransomware proprietors are fans of the "Dark Web", which I cover in other posts and have my own thoughts about. Through layered proxying and obfuscation, browsers such as "The Onion Router" (ToR)  allow individuals to anonymize their internet browsing to require nation-state level of surveillance and tracking to break. Ransomware hackers often urge their victims to set up a gateway into the ToR network in order to submit payment and exchange keys.

Payment

Notoriously, ransomware threat actors demand payment through Bitcoin, with up to 98% of ransomware payments being made through the cryptocurrency. 70% of CISOs also keep a stash of Bitcoin on hand to quickly pay ransoms should they be infected.

Bitcoin (or any cryptocurrency) makes sense as a perfect hacker direct deposit slip with its anonymity and blockchain technology.

On Reputation

If you're paying attention and have a good head on your shoulders, you are obviously thinking:

> Okay, if I do "negotiate with the terrorists" here and send payment, what are the odds they're going to actually give me the decryption key? Would they not just turn tail and run, and now I'm left with no files AND no money?

Great question, and the truth is that *most* ransomware hacker groups out there will actually cooperate with you and send you the decryption key. Why? Reputation. If they took the money and ran, the company would promptly tell every other company out there not to deal with hacker "im2cool69" and their Bitcoin wallet ending in 0047. Then when this particular denizen of society deals with another victim, they would know not to pay.

Now, you may think its extremely easy to go get another hacker nickname and Bitcoin wallet, and constantly rotate through a cycle of never-ending cash-filled accounts. This is true, but these ransomware adversaries have rating systems as well, just like an eBay seller. I'm not sure if they have client testimonials and glowing reviews, but at the same time, you're much less likely to pay a hacker who has zero successful decrypts and data recoveries compared to one who may have done several already. There's no honor among thieves, but even they have to market their (forced) services!

CVSS 3.1 Scoring Series - Attack Vector

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

Classifications

There are four different classifications of Attack Vector:

1. Network (AV:N)
2. Adjacent (AV:A)
3. Local (AV:L)
4. Physical (AV:P)

A Network (AV:N) classification means that a vulnerability can be exploited across a Wide Area Network (WAN). This applies to the public Internet, corporate and remote business sites, or even traffic that must traverse at least one router to reach the target. Therefore, the simplest way to classify this is "can I exploit a vulnerability (directly) across at least one network router?"

An Adjacent (AV:A) classification means that a vulnerability can only be exploited within the same Local Area Network as the target. If I must exploit this inside the same OSI Layer 2 network as the target (same VLAN, same broadcast domain, etc.), then the vulnerable system would get an AV:A scoring.

A Local (AV:L) classification means that a vulnerability can only be exploited with logical local access to the system. For example, you must have a terminal or shell on the local system in order to exploit a vulnerability.

Finally, a Physical (AV:P) classification means you must have direct physical access to the machine or component in order to exploit a vulnerability. Think "pressing a key combo during boot lets you bypass authentication", or a physical USB stick must be plugged into the device to execute malware, etc.

When determining which classification a vulnerable application or system falls into, it is extremely important to note that this is NOT about the physical medium. SSH as a protocol traverses the network, yes, but if SSH is a necessity in order for me to be on the same host as the vulnerable component, it is a *Local* attack vector.

Example

Pop quiz time! So what if to exploit a vulnerability in a company's server from my laptop I had to SSH to a bastion host in a shared co-located server room in a leased datacenter, craft malformed data frames from my server to the company server in the same L2 domain, spawn a reverse shell inside their server, then attack localhost:6336 to exploit a SQL database vulnerability? Which attack vector classification should the database have?

To summarize:
- I move from my laptop on the public Internet to a bastion host (Network)
- I move from the bastion host to a company server in the same LAN (Adjacent)
- I spawn a shell inside the company server and attack the database (Local)

This would result in a CVSS 3.1 Attack Vector classification of Local. Yes, I can do all this in my slippers from the comfort of my home while watching Finding Nemo. Yes, it requires a lateral movement inside the same L2 network. However, I cannot start attacking SQL until I get onto the local server. Since we care about scoring the database specifically (even if the rest of the network seriously needs to be checked for holes), the database would get a vulnerability scoring of AV:L.

Considerations

One major caveat to note here is that if an attack has to originate from within a corporate intranet (and not the public Internet) in order to be successful, it would *still* be of a Network type. Sorry, you don't get points for having a private intranet for this sort of thing.

This kind of makes sense, right? If I can hijack communication from a retail POS system in a remote site to get all the way to customer financial data across the country in a central site, even if that communication travels across a company intranet - you wouldn't call that an Adjacent attack vector. There are many, many hops and L2 networks in between those points, so it still counts as Network.

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