The Next Log4Shell? Spring4Shell Hitting Waves.

Intro

A new vulnerability was found in the Spring Core module of the Spring Framework. This was discovered by a Chinese security researcher, posting a Proof-of-Concept (POC) on GitHub (Figure 1), which later was deleted.

This vulnerability is a zero-day, which currently wasn’t assigned a CVE, and was dubbed by security researchers as “Spring4Shell» or «SpringShell”, after the recent vulnerability in the Log4j Java package, discovered last December, and made waves worldwide.

To add to the chaos and misunderstanding, two, totally unrelated Spring vulnerabilities, were disclosed this week, one in Spring Framework, and the other in Spring Cloud Function.

The Next Log4Shell? – Spring4Shell

Zeroday and Spring

A «Zero-day» vulnerability is used to describe recently discovered security vulnerabilities within an application, that threat actors might use, and are yet to be patched. The term «Zero-day» is derived from the time the company, or the developer had to ‘fix’ this vulnerability – Zero days.

The Spring Framework (Spring) is an open-source application framework that provides infrastructure support for developing Java applications. According to their website:

Spring makes programming Java quicker, easier, and safer for everybody. Spring’s focus on speed, simplicity, and productivity has made it the world’s most popular Java framework.

We bolded the two phrases that mean the most here – ‘safest’, and ‘world’s most popular java framework’. This is a lethal combo when the ‘safest’ is not so ‘safe’.

While Apache Struts, for example, a different open-source web application framework, is known for it’s Remote Code Execution vulnerabilities hitting the news for a few years now, with active in-the-wild POC code (CVE-2017-5638, CVE-2019-0230), little known vulnerabilities ‘stuck’ to Spring, which as stated, is the most popular Java framework worldwide.

The Vulnerability

The discussed RCE of Spring Core was confirmed on JDK9+ and is vulnerable to remote code execution due to a bypass of CVE-2010-1622, a Spring Core vulnerability from 2010, which allows RCE over Spring Framework, caused by an error in the mechanism that validates client-provided data to update the properties of an object.

The weakness enables a «ClassLoader Manipulation» attack when functions use @RequestMapping annotation (Annotation for mapping web requests onto methods in request-handling classes with flexible method signatures), and Plain Old Java Object (also called POJO) parameters, to parse a request.

When we try and test this vulnerability on a Tomcat server, hosting a simple form, the form parameters are to be expected (for example, user name, and password), however, other parameters can be used, for example, the ‘class’ parameter, which can also be addressed, and is the main issue of this following example.

This allows a threat actor to run the following examples as payload to a controller with Requestmapping annotation, to modify Tomcat logging properties:

Running these concatenated, with the proper pattern, will result in the file ‘shellFile.jsp’ uploaded to the Tomcat path ‘/webapps/ROOT/’.

The pattern can, for example, include a reverse shell, that eventually allows a threat actor to run his remote commands on the compromised server.

After the file shellFile.jsp is uploaded successfully to the server, running the following command will list all files in the current directory:

curl http://localhost:8080/shellFile.jsp?cmd=ls

This is just one example used broadly online over several already seen POCs, using the modification of Tomcat log manipulation, and other different versions of the vulnerability will probably appear as this catches on.

Just as in the previous phases of Log4Shell, we expect this vulnerability to propagate and be used by threat actors. First, it will be used by DDoS and crypto mining activities, and later on, adopted by the threat actor’s community, as previously seen by Conti, being among the first groups to utilize Log4Shell.

While we have researched the new vulnerability, we noticed the industry has some confusion, since more Spring related vulnerabilities were discovered throughout this week.

Two vulnerabilities, that are already fixed by Spring, are:

CVE-2022-22950 – medium-severity vulnerability, with CVSS score of 5.4, which can cause a DoS, affects Spring Framework, just as the mentioned “Spring4Shell” is, hence, the confusion.

CVE-2022-2296 – medium-severity vulnerability, with CVSS score of 5.4, which can cause RCE, which adds to the confusion.

Spring released versions 3.1.7 and 3.2.3 to address this vulnerability. It affects Spring Cloud Function (and not Spring Framework)

Regarding the second vulnerability, CVE-2022-22963, its CVSS score being 5.4, for an RCE vulnerability, sounds reasonably low, and Cyberint’s Research Team feels it should be addressed with more importance.

Recommendations

As no patch is available at the moment, and the conversation around this issue rises by the hour, it seems that threat actors will look deeply into exploiting this vulnerability and scan the web for exploitable hosts. Here are some recommendations that might help mitigate or identify exploitation attempts:

• Yara rules that can detect utilizing this vulnerability exploitation were already released and might also mitigate exploitation.
• As this vulnerability gains popularity, it is predictable for IPS/IDS vendors to put their best efforts to create protection mechanisms. Although updating security packages from IPS/IDS vendors is sometimes does not come as the first priority, we highly recommend monitoring for coming security packages that support protection against this vulnerability and update it as soon as possible.
• Also, As IPS/IDS supports other SPRING based signatures and JAVA based signatures in general, signatures that identify string filters such as «class.*», «*Class.», «.class.», and «.Class.», should be considered as a temporary but effective mitigation technique.
• Mapping all services within the organizations that are front-facing SPRING-based might help mitigate and understand the weak links within the organization or product infrastructure and look for suspicious activity or strengthen security policy regarding these assets.
• We should prepare ourselves for the coming SPRING update that will patch this issue so that once it is released, the patch will be done as soon as possible.
• Once the patch is done, thorough monitoring and testing should be done within the hosts that used to be vulnerable to see any suspicious activity in case an organization was compromised before the patch.
• As mentioned, CVE-2022-22963 was already released this week and is also related to Spring. Fortunately, an update is available on versions 3.1.7+ or 3.2.3+ that prevent an RCE attack.

Are you prepared for 2022’s security challenges?
Get Your Organization’s Digital Risk Snapshot