Vulnerability chaining: part 1, a logical model

Laying the groundwork for a statistical one.

Hackers are wily people.

They do all sorts of things to penetrate networks and steal and corrupt data. One of the many tricks up their sleeve is vulnerability chaining. Chris Hughes has outlined the concept and Nikki Robinson has documented some good examples.

But in this and subsequent post I’m going deep to build a workable logical model for understanding and evaluating vulnerability chaining. My eventual goal is to create a statistical one that will allow for quantitative assessment for the risk created by chained vulnerabilities.

The Forum of Incident Response and Security Teams (FIRST) previously suggested a way to model these situations which essentially consists of smushing together Common Vulnerability Scoring System (CVSS) ratings, but I am going to propose an alternative method here.

To establish a good base for this model, I’ll start with a definition.

Defining vulnerability chaining

Vulnerability chaining is the use by a simulated or actual malicious actor of two or more software vulnerabilities to impact the confidentiality, integrity, or availability of data in a way its owner did not intend. The impact requires the sequential use - in the same attack attempt - of software vulnerabilities in the victim’s network or supply chain to achieve the actor’s desired effect.

For the purposes of this article, I am going to focus narrowly on software vulnerabilities rather than including misconfigurations as well. It’s certainly conceivable that an attacker could make initial entry to a network using a misconfiguration and then move to exploit a software vulnerability (or vice versa). And many attacks often start with social engineering (using no software flaws) and then move to vulnerability exploitation (or vice versa).

But these are too complex to incorporate into my model for now. Potentially more to follow in the future.

Building on this definition, I separate vulnerability chaining attacks into two mutually exclusive and completely exhaustive categories: direct and indirect.

Direct chaining

A direct vulnerability chain involves an attacker “breaking out” of the security context of the asset in which the first vulnerability was located. This act provides the attacker the immediate ability to exploit a second vulnerability.

This can happen if the first vulnerability allows for one or both of the following:

• Remote code execution (RCE, CWE-94). If this happens, then an attacker can execute code within the security context of the compromised asset, moving laterally through the network.

• A changed “Scope,” defined by the CVSS as when “a security boundary mechanism separating components is circumvented due to a vulnerability and this causes a security impact outside of the security scope of the vulnerable component.” RCE is not necessary for an actor to continue the attack here, as exploitation of the first vulnerability itself allows for subsequent access to assets that would not otherwise be available.

In a direct vulnerability chain, the attacker is able to exploit a second (or third, etc.) vulnerability merely because he was able to exploit the first one.

An example of direct vulnerability chaining would be exploiting CVE-2017-5638 in an internet-facing web application, subsequent to which attackers could exploit CVE-2012-2122 to siphon sensitive data from a MySQL database.

Indirect chaining

An indirect vulnerability chaining attack is one in which a malicious actor takes information stolen from exploiting one vulnerability to assist in exploiting another.

In this case, the vulnerability needs to reveal something that allows an attacker to exploit another software vulnerability. If he steals a plain text password through the first exploitation and just logs into the target system, it wouldn’t count as chaining (of any type) by my definition. That’s because there was only one vulnerability exploitation.

An example that would count, however, would be exploiting the Heartbleed (CVE-2014-0160) vulnerability to steal a hashed password and then using a separate pass-the-hash vulnerability to remotely take over a target device.

Conclusion

By establishing two mutually exclusive and completely exhaustive categories of vulnerability chaining attacks, my goal is to lay the groundwork for a mathematical model describing these types of attacks. I welcome reader feedback on what I have written so far, as I am building this model as I go and encourage constructive criticism along the way.