Exploitability Vs Vulnerability — Leveraging Exploitability for Vulnerability Management

Modern cloud native applications are complex and have a lot of dependencies on external libraries including open source components with many known vulnerabilities. Managing and fixing a large number of vulnerabilities in multiple components is a tedious job. Adoption of containers, Kubernetes, and CI/CD based deployment models have further exacerbated the vulnerability management problem due to their rapid development and deployment cycles. Thousands of vulnerabilities are disclosed every month and it is not possible for the developers to fix all the vulnerabilities in highly dynamic cloud environment in a short span of time. To address this problem, we need a way to prioritize the most important vulnerabilities and focus on remediating them first. In this article, we describe the approach Deepfence ThreatMapper takes to solve this problem.

Solution — differentiate between vulnerability and exploitability

Understanding the differences between vulnerability and exploitability can help us in prioritizing vulnerabilities. Vulnerability means a weakness in deployed software which can possibly be exploited by attackers. However, presence of a vulnerability does not mean it is always possible for the attackers to use it for any unauthorized activity. Exploitability means availability of an actual attack design or code (exploit) which uses the vulnerability to violate system integrity. The availability of a real exploit means an attacker has a practical way to attack vulnerable targets. While it is not possible to fix all the vulnerabilities in deployed cloud native workloads, on the brighter side it is perhaps not even necessary to fix all of them as many them may not be exploitable by a real attacker.

Many of the disclosed vulnerabilities are not easily exploitable by external attackers due to various reasons like the affected container images may not be running, or it may require local access privileges, specific system configuration settings, or user interactions.

Let us explain the concept of exploitability in more detail using two different real vulnerabilities mentioned below.

The latest Common Vulnerability Scoring System (CVSS) mentions some important features of the vulnerabilities that can affect the ease of exploitability. We describe these important characteristics below:

• Attack vector (AV): This specifies how remote (logically and physically) the attacker can be to successfully exploit the vulnerability. It will be significantly easier for the attackers to exploit a vulnerability remotely over network compared to those vulnerabilities which require local or physical access. In the vulnerability-1 example, an attacker can potentially exploit the vulnerability remotely over a network (AV:N) making it highly exploitable. In contrast, an attacker needs local access (AV:L) to exploit the disclosed vulnerability in example-2 above making it less exploitable.
• Attack complexity (AC): This specifies if an attacker needs any particular conditions, system configuration settings, etc. to successfully launch an exploit. It will be much easier for an attacker to exploit a vulnerability with low attack complexity which doesn’t require special conditions beyond the attacker’s control. In the vulnerability-1 example above, the attack complexity is low (AC:L) which makes it highly exploitable in contrast to vulnerability-2 which has high attack complexity (AC:H).
• Privileges Required (PR): This specifies the privilege level the attacker needs to successfully exploit the vulnerability. It will be much easier to exploit a vulnerability if the attacker needs no privilege as compared to vulnerabilities which require basic user level privileges or administrative privileges.
• User Interaction (UI): This specifies if the attackers can exploit the vulnerability alone or if they need an additional user to perform any extra actions to successfully exploit the vulnerability. Obviously, it will be a lot easier to exploit a vulnerability if the attacker needs no extra user interactions as compared to vulnerabilities which require a user to perform some particular before they can be successfully exploited.

In addition to CVSS metrics, the following additional characteristics can impact the exploitability of a vulnerability:

• Time since vulnerability disclosure: Vulnerabilities that have been disclosed for a long time are more likely to have well crafted exploit codes and more information to launch successful attacks against vulnerable targets compared to recently disclosed vulnerabilities.
• Time since the affected container image was built: Similar to the time since vulnerability disclosure, the longer the time since the image was last built, the easier it is for the attackers to launch successful attacks.
• Number of running instances of affected container images: The higher the number of containers that have the vulnerabilities, the higher the likelihood of successful exploits launched by attackers. Especially for attacks with high attack complexities which require very stringent preconditions, a higher number of vulnerable instances significantly increases the chances of attackers satisfying those stringent preconditions. For example, even though the vulnerability-1 is highly exploitable in practice, it may be less exploitable in a customer environment if there are no or very few instances of the corresponding images currently running.

While both the vulnerabilities in our example are serious flaws, developers can focus on fixing the first vulnerability as its features make it much more exploitable in the wild. Based on the exploitability characteristics of vulnerabilities, Deepfence helps developers and security analysts to prioritize and focus on the set of most important vulnerabilities which can be easily exploited by attackers and can cause severe damage to the system’s integrity.

Prioritize and visualize your most exploitable vulnerabilities

We use various important features of vulnerabilities to rank them based on the ease of exploitation. First, we use the CVSS scores, severity, attack vector, attack complexity, and how long the containers or VMs are running without being patched to compute a score indicating how easily the vulnerabilities can be exploited. If the containers have been running for a long time without being patched or upgraded, then the attackers may have more information about the vulnerabilities and may have better exploits increasing the likelihood of successful exploitation. We take into account to update the initial vulnerability score accordingly and then finally normalize the score between 0 and 10 (with 0 indicating no apparent vulnerability and 10 indicating highly vulnerable). We rank the vulnerabilities based on this final score and display them on the UI.

Additionally, we also assign an overall vulnerability score between 0–10 for all the VMs and images by using a formula to compute a weighted average of the individual vulnerability scores as shown in the following picture. This gives a high level summary for developers to focus on the most vulnerable VMs and container images in their cloud infrastructure.

Detecting and mitigating vulnerabilities is the first step towards protecting your system from critical threats. Our free ThreatMapper offering helps you measure and reduce your attack surface. ThreatStryker, our Enterprise offering, considers exploitability as one of the keys signals while detecting and protecting from attacks in addition to many other runtime signals.

If you’re interested in learning more about ThreatMapper or ThreatStryker, reach out. We’d love to show you how we can help you protect against vulnerabilities and increase the security of your applications across the entire CI/CD pipeline.