Vulnerability chaining: part 2, breaking through the exterior

Turning ideas into action.

All models are wrong, but some are useful.

- British statistician George E. P. Box

Building on the previous post on vulnerability chaining, in which I introduced the concepts of direct and indirect chaining, I’ll now turn to modeling out a vulnerability chaining attack.

The key question to answer here, from an security practitioner perspective, is “what is the probability of exploitation of vulnerability A, given that vulnerability B is also in the same network?”

In this post I propose a way to answer that question in certain circumstances.

I’ll give a major warning ahead of time that my model is very limited in scope and requires many assumptions. But it can serve as the basis for more advanced modeling techniques and is an important first step.

Vulnerability chaining definitions

• Asset: a distinct entity running computer code that has its own internet protocol (IP) address. For the purposes of this analysis only, an asset is equivalent to a “host.”

• Network exterior: a category including all internet-facing assets.

  • If you can see a given vulnerability just by using Shodan or equivalent tool, then it is on the network exterior.

  • Without any compensating controls, every vulnerability where the Attack Vector is Network - per the National Vulnerability Database (NVD) and using Common Vulnerability Scoring System (CVSS) - can be accessed on the network exterior (although not necessarily exploited, as this will depend on other vectors).

    • I acknowledge I have been critical of both the NVD and CVSS, but think some of the latter’s base metrics are useful, specifically Attack Vector, Privileges Required, and User Interaction Required.

    • And the NVD is the most detailed freely available source of information for determining the latter’s vectors.

    • Thus, I will use them both in building my model.

• Network interior: a category including any asset not on the network exterior.

Vulnerability chaining model assumptions

• You treat vulnerability exploitation calculations as a probabilistic exercise and use the Exploit Prediction Scoring System (EPSS) or similar model for predicting the likelihood of such events occurring. If you are of the school that says “a scanner flagged this, ergo you are vulnerable and there is no point in determining the likelihood of exploitation,” then you should probably stop reading here.

• Vulnerability A is in the network interior and has an Attack Vector of Network, Adjacent, or Local.

  • My assumption here is that, even with firewalls or other types of controls in place, once you get past the network exterior, you will eventually be able to exploit these types of vulnerabilities remotely.

    • Adjacent-accessible vulnerabilities can be attacked from the “same shared physical (e.g., Bluetooth or IEEE 802.11) or logical (e.g., local IP subnet) network, or from within a secure or otherwise limited administrative domain” per the CVSS standard.

    • Local-accessible vulnerabilities allow an attacker to exploit it “by accessing the target system locally (e.g., keyboard, console), or remotely (e.g., SSH).”

  • If the vulnerability is accessible via the Network but is normally protected by some kind of control, then in a vulnerability chaining attack you should just assume that it is internet-facing (e.g. on the network exterior).

  • Vulnerabilities with Physical vectors are excluded because they require the attacker to touch the component in question.

• Vulnerability B is on the network exterior, facilitates direct or indirect vulnerability chaining, and has the highest likelihood of exploitation of any vulnerability meeting the preceding two criteria.

• Per the Deploy Securely Risk Assessment Model (DSRAM), “high” and “low” CVSS base vector string values are treated simply as a binary (e.g. Privileges Required can only be 1 or 0).

• Attackers will not attempt to chain multiple vulnerabilities together on the network exterior, as this increases complexity and detection risk without providing them any advantage.

• Attackers only chain software vulnerabilities with other software vulnerabilities. They do not alternate between or combine use of misconfigurations, social engineering, or other techniques. I acknowledge this is a huge assumption that is likely wrong, but there is no other way I can see to proceed in developing a model without opening a massive can of worms. I am very open to revisiting this assumption.

• “Zero trust” is a binary concept. Since zero trust is as close as you can get to the opposite of a “walled fortress” model, I assume that Privileges Required for every vulnerability on the network interior becomes 1, irrespective of whether or not the vulnerability requires it per the NVD. Note: although zero trust is definitely not a binary concept, this is the only way I could think to approximate it.

Adjusting likelihood of exploitation for vulnerability chaining

All of the above represents a lot of build up to a simple model for vulnerability chaining:

Given the assumptions, treat Vulnerability A’s Attack Vector as Network (rather than Adjacent or Local) and adjust its likelihood of exploitation accordingly. Multiply this result by the likelihood of exploitation of Vulnerability B to determine the total likelihood of a chained attack involving both A and B.

This reflects the fact that the initial exploitation represents a “foothold” for the attacker, from which he can move more easily within the target network.

A key subsequent question would be “what do I do with this information?”

How to adjust likelihood of exploitation based on vulnerability chaining

To determine how much more exploitable an issue exposed by vulnerability chaining would be, I would suggest the following:

• Collect all CVEs that match the simplified vector string (per DSRAM rules of ignoring qualitative values and using binaries instead) of Vulnerability A (we’ll call this group 1).

• Collect all CVEs that match group 1’s simplified vector string but whose Attack Vector is Network (call this group 2).

• Average the EPSS scores for both groups.

• Determine by what percentage the (annualized) EPSS score is higher for group 2 than group 1.

• Multiply the likelihood of exploitation of Vulnerability A by this percentage. This is the adjusted likelihood of exploitation given the assumptions stated above.

• Repeat this calculation on a regular basis to continually adjust this adjustment percentage.

Once you have adjusted Vulnerability A’s likelihood of exploitation, you can multiply it by Vulnerability B’s.

Example

• Presume we have Vulnerability A, CVE-2019-12264, and Vulnerability B, CVE-2017-5638 in the same network and we want to determine the likelihood of exploitation of Vulnerability A.

• Also presume that Vulnerability B is the most exploitable vulnerability on the network exterior.

  • Vulnerability A’s simplified vectors (per the DSRAM) are:

    • Attack Vector: Adjacent

    • Privileges Required: None

    • User Interaction Required: None

  • Vulnerability B’s simplified vectors (per the DSRAM) are:

    • Attack Vector: Network

    • Privileges Required: None

    • User Interaction Required: None

• As of April 7, 2023, and per the DSRAM, the annual likelihood of exploitation (adjusting the EPSS score to 365 days) of all vulnerabilities matching

  • A’s criteria (in group 1) is 0.006997

  • B’s criteria (in group 2) is 0.027917

• Vulnerabilities in group 2 are thus 3.99 times more likely to be exploited than those in group 1, which makes sense logically because, all other things being equal, Network-accessible flaws are more easily targeted than Adjacent-Accessible ones.

• Also on April 7, 2023, and per the DSRAM, the annual likelihood of exploitation of vulnerability:

  • A is 0.00249

  • B is 0.97548

• Multiplying A’s likelihood by 3.99, we arrive at 0.0099, which is the adjusted figure for a vulnerability chaining situation.

• Multiplying this adjusted figure by Vulnerability B’s likelihood of exploitation, we arrive at 0.0097, which is the total likelihood of a vulnerability chaining attack involving both A and B.

Conclusion

As with any new mental model or similar project, I’m sure that version 1.0 will leave a lot of room for improvement, and I encourage constructive engagement to help me refine my approach.

I fully acknowledge that my model is simplistic, but do believe it provides marginal value over current approaches. In future iterations of the model, I look forward to incorporating things such as the:

• Impacts of multiple lateral movements

• Effects of attackers using things other than software vulnerabilities during an attack

• Presence or absence of compensating controls

With that said, prioritizing known vulnerabilities is a massive pain for enterprises and most security practitioners agree that vulnerability chaining creates risk.

My goal here has been to answer the question “how much risk does it create.”

For those looking for a productized application of this model, I am currently working on implementing just such a thing (and a whole lot more) through my company StackAware. Please drop me a line there if you are interested in learning more.