Two Effective Strategies to Reduce Critical Vulnerabilities in Applications

Originally published by CrowdStrike.

Securing custom applications in a sea of vulnerabilities is daunting. To make the task even more challenging, the threat to applications continues to grow: 8 out of the top 10 data breaches last year were related to application attack surfaces.

This blog details two effective strategies for identifying vulnerabilities in custom software applications so they can be quickly addressed.

Isolate Vulnerabilities Loaded into Memory

When an attacker targets a custom application or API, they cannot access its underlying file system. So, if an application vulnerability exists in the server’s storage, it’s safe from an attacker. Attackers must find one of the vulnerabilities loaded into runtime memory, and it must be both exploitable and accessible to them.

A CVE sitting on a file system is typically worthless for gaining initial access to a target environment. CVEs become dangerous when the code is loaded into memory and executed. The first step, loading the code into memory, means the at-risk code enters random-access memory (RAM). After the vulnerability is loaded into RAM, it must execute, or be called by the software. At this point, a malicious payload will exploit the vulnerability and potentially allow an adversary to breach the system.

Determining which vulnerabilities are truly dangerous is challenging. Vulnerability scanners exist for every stage of software development, and most of them cannot distinguish between CVEs that exist on a file system versus those that are loaded into memory. For example, software composition analysis performs a vulnerability scan on every open source library referenced in a repository, but it cannot determine which vulnerabilities exist after the compiling, assembling and loading processes. Similarly, container scanning tools detect all potentially vulnerable files in an image, but they do not distinguish vulnerabilities that are ultimately loaded into runtime.

Application security posture management (ASPM) is the only category of application security tool that directly analyzes runtime. Vulnerabilities detected by ASPM are, therefore, actively loaded into memory and ripe for exploitation. Security teams that use this approach are empowered to resolve software vulnerabilities in production, which present the greatest risk to their business.

Determine Runtime Exploitability

Vulnerabilities do not exist in a vacuum. Most library CVEs require a specific runtime configuration for exploitation to be possible. Some, however, affect everyone. Let’s start with Log4Shell (CVE 2021-44228) as an example of a wide-reaching vulnerability.

Log4Shell is a remote code execution (RCE) vulnerability with the highest possible CVSS score of 10.0. The affected open-source library, Log4j, is the most popular Java logging framework used by millions of applications worldwide. Like all vulnerabilities, it’s only lethal if certain conditions are met in the runtime environment. For Log4j, these include:

• Library version less than 2.16.0 (excluding 2.12.2, 2.12.3 and 2.3.1)
• JndiLookup Class enabled (default behavior)

When the CVE was announced in December 2021, nearly every user of Log4j found themselves at risk of exploitation. Several options presented themselves as sufficient methods to mitigate the vulnerability:

• Upgrade Log4j version to 2.16.0
• Disable logging capabilities via Log4j
• Remove the JndiLookup Class within Log4j

Log4j remains notorious because the millions of affected users had very few options to mitigate the vulnerability — each of which is specific to the Log4j library.

Most vulnerabilities, however, require a more niche runtime configuration. Sticking with Java vulnerabilities, for example, exploitation is often dependent on:

• Web Server version (e.g., Apache Tomcat version below 10.0.20)
• Java Development Kit (e.g., JDK v9 or above)
• Application packaged as a WAR (versus the default executable JAR format)
• Importing additional dependencies

These four examples are common prerequisites for Java exploitation, but they are nowhere near an exhaustive list. The niche environments required by many library vulnerabilities in order to be exploited, as described above, should bring hope to security teams. At the time of publishing, the National Vulnerability Database (NVD) contained nearly 240,000 entries, while the number of known exploited vulnerabilities was less than 1,100, according to the Cybersecurity and Infrastructure Security Agency (CISA) Known Exploited Vulnerabilities (KEV) Catalog.

By understanding your runtime configuration and isolating exploitable vulnerabilities, you can dramatically reduce the number of critical library vulnerabilities competing for your team’s attention.