Today, I spent a lot of time working through different issues regarding Java. "Spring4Shell" was one name that has been assigned to at least one of the vulnerabilities. In this post, I am trying to clean up some of the issues around the different vulnerabilities and Java frameworks.

First of all, we are talking about two different frameworks here:

Spring Core: This is the very widely used "Spring" framework. It is open-source and very popular for enterprise applications.
Spring Cloud: As the name implies, the Spring Cloud framework helps create cloud applications. 
Spring Expression Language (SpEL): A language used to configure Spring integration components.

All of this is part of the overall Spring Framework [1]. The company VMWare supports Spring.

So what vulnerabilities are we talking about? Let's start with the "easy" one that has a CVE number and is acknowledged by the Spring project:

CVE-2022-22963 [2]

This vulnerability in Spring Cloud was made public on March 29th. It fixes a vulnerability in the routing functionality. The original announcement assigns it a CVSS score of 5.4. But the score may not be correct. The advisory only mentions that an attacker may get access to other local resources. But remote code execution exploits have been published.

The exploit takes advantage of a crafted SpEL message that is passed in the spring.cloud.function.routing-expression header. Serverless functions written in Java may be vulnerable, but that would depend on them being exposed to the header.

A typical exploit will include a header like [3]:

spring.cloud.function.routing-expression: T(java.lang.Runtime).getRuntime().exec("{cmd}")'

Unnamed Vulnerability/Spring4Shell

This is the issue that started a lot of the speculation earlier. It was first raised in some tweets on March 29th, which were later deleted, and a blog post [4]. It was first described as a deserialization vulnerability and associated with a particular patch committed to Spring [5].

For this vulnerability, our handler Bojan was able to get one of the publicly available exploits to work. But there are likely many different ways to exploit this vulnerability. The exploit requires several requests to achieve code execution. First, it reconfigured logging, limiting logging to a particular header, and logging the content of the header to a specific file. Finally, the code is sent to be written to the file, and lastly, the code is executed. There may be a number of different ways how this can be exploited.

What Should You Do?

Don't panic :). Next, keep your eye out for patches, and apply them as they become available. A patch for the second issue has been committed to git, but no official new version has been released, and this issue has not yet been acknowledged as a vulnerability in Spring. You may configure web application firewalls to block the header triggering the first issue. The second issue is a bit more tricky. But watching for unusual custom headers is likely helpful. It also requires write permissions for the server inside the document root, which is a bad idea for many reasons and should be avoided.

Lunasec published an excellent post with more details here: https://www.lunasec.io/docs/blog/spring-rce-vulnerabilities/

[1] https://spring.io/projects/spring-framework
[2] https://tanzu.vmware.com/security/cve-2022-22963
[3] https://github.com/dinosn/CVE-2022-22963
[4] https://www.cyberkendra.com/2022/03/spring4shell-details-and-exploit-code.html
[5] https://github.com/spring-projects/spring-framework/commit/7f7fb58dd0dae86d22268a4b59ac7c72a6c22529#diff-6c2618839eda075efe4491842d3673eab8fe1e342f6d9ddc2bbda8556e595864L153

---
Johannes B. Ullrich, Ph.D. , Dean of Research, SANS.edu
Twitter|