Patch that Vuln! Identify, Triage, and Qualify CVEs

Our official recommendation for CVEs is patch that vuln! Unfortunately, real-world business conditions are not always conducive to patching software in a timely manner. From bureaucratic boondoggles to chained dependencies, patching software has been a thorny issue for years. For instance:

Patch Availability: If the vulnerability is identified within a  commercial app, you’re held at the mercy of the vendor until an official patch is released.

Installation Time: The patch management process can be lengthy due to the need for thorough testing and the complexity of deploying updates at scale.

Legacy Code: Using a version that is no longer supported or the vendor has gone out of business.

Cost Prohibitive: True when vulnerabilities are not found early in the design or testing phases.

One of the best options to quickly address CVEs is to use virtual patching. A virtual patch is implemented at the network level or in your WAF (Web Application Firewall). This gives organizations the ability to apply protections in situations where an organization can’t simply edit the source code or quickly apply software patches.

At Fastly we focus on identifying and responding quickly to CVEs with known publicly available PoCs (proof of concepts) or PoCs developed in-house. Let’s delve deeper and explore our process.  

Step 1: Read beyond the headlines

We’ve all been victim to impulsive panic when seeing a headline like:

“New Apache CVE has IT field in chaos!”

“Millions of Installations Potentially Vulnerable to Spring Framework Flaw”

Now before we get too far into virtual patching we need to be clear that only a small subset of CVEs can be mitigated via a WAF. These CVEs range from local privilege escalation to vulnerabilities that occur in specific languages, and in general, will require a network request to be detected by a WAF.

Let’s look at two contrasting examples:

Example 1: local privilege escalation in Apache

“Serious Apache server bug gives root to baddies in shared host environments”

The words “serious”, “root”, and “shared host environments” are all major causes for concern. The mention of “Apache” is a bit of a hint that a WAF might be able to help us out here, but upon further reading into CVE-2019-0211, we soon realize not only is this a local privilege escalation issue, but also does not affect non-unix systems. Depending on the organization, those two key points of information should be enough to decide that a WAF is not going to help here, the team may have already offloaded their responsibility for this issue, or the organization does not use the affected technology.

Example 2: vulnerabilities that occur in specific languages

CVE-2022-22963 a.k.a. The Spring Cloud Function RCE vulnerability: By providing a specially crafted Spring Expression Language (SpEL), it’s possible to access local resources and achieve remote code execution. 

One intractable problem we have in application security is knowing the solution but struggling to implement the solution at scale in technically complex systems with complex human factors. When the complexities around patching quickly become too burdensome, virtual patching can prevent exploitation in the interim.

Step 2: PoC or go home

A proof of concept is the most basic requirement for developing a rule. The proof of concept will provide the necessary details to identify a unique request pattern and help the team develop a request rule to protect systems until a patch is ready.

PoC for CVE-2022-22963:

When reviewing the patch, we can see a new flag isViaHeader was added to perform validation before parsing the header content. This suggests the vulnerability is limited to an HTTP attack.

Further analysis revealed that it permits using the HTTP header spring.cloud.function.routing-expression parameter.

It was quickly outlined that this was exploited via this header and has been shared publicly in many locations due to its simplicity. The following is an example request for this particular vulnerability.

POST /functionRouter HTTP/1.1
host:127.0.0.1:8080
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/15.2 Safari/605.1.15
Connection: close
spring.cloud.function.routing-expression:T(java.lang.Runtime).getRuntime().exec("touch /tmp/pwned")
Content-Length: 1

.

This provides access to functions that should not be available by including spring.cloud.function.routing-expression as an HTTP header with a specific set of strings such as exec(), getByName(), and ProcessBuilder().

Using this information we can come up with a DIY virtual patch.

Using the matches operator we can look for requests where the value of the header contains one of the keywords we identified:

(?i).*(exec|getbyname|processbuilder).*

This should be concise enough to block attempted exploits of this CVE without impacting normal operations. In the example, we show the rule blocking immediately, but in any case, where your team is experimenting with these sorts of rules, we do recommend simply adding a signal for a period of time and moving to blocking once the team is confident in how the rule works. Learn more about Fastly’s NGWAF rules.

Keep calm and carry on

Learning to stay calm and collected when new vulnerability headlines surface is paramount to any application security team’s success. Panic is one of the last things a security person should be introducing into a complex system.

With the process and approach outlined here, security, DevOps, and software engineers responsible for addressing known vulnerabilities can better sift through the noise to determine how actionable and relevant a new CVE is to their organization.

Fastly’s Security Research team continuously monitors for new and emerging threats to help provide timely and relevant virtual patches to our customers. Keep in mind though the best solution to vulnerable software is to deploy a patch.