Spring4Shell, Spring Cloud Function RCE and Spring Cloud Gateway Code Injection. Hello everyone! This episode will be about last week’s high-profile vulnerabilities in Spring. Let’s figure out what happened.

Alternative video link (for Russia): https://vk.com/video-149273431_456239078

Of course, it’s amazing how fragmented the software development world has become. Now there are so many technologies, programming languages, libraries and frameworks! It becomes very difficult to keep them all in sight. Especially if it’s not the stack you use every day. Entropy keeps growing every year. Programmers are relying more and more on off-the-shelf libraries and frameworks, even where it may not be fully justified. And vulnerabilities in these off-the-shelf components lead to huge problems. So it was in the case of a very critical Log4Shell vulnerability, so it may be in the case of Spring vulnerabilities.

Spring is a set of products that are used for Java development. They are developed and maintained by VMware. The main one is Spring Framework. But there are a lot of them, at least 21 on the website. And because Spring belongs to VMware, you can find a description of the vulnerabilities on the VMware Tanzu website. VMware Tanzu is a suite of products that helps users run and manage multiple Kubernetes (K8S) clusters across public and private “clouds”. Spring is apparently also part of this suite and therefore Spring vulnerabilities are published there. Let’s look at the 3 most serious vulnerabilities published in the last month.

CVE-2022-22965: “Spring4Shell”, Spring Framework remote code execution (RCE) via Data Binding on JDK 9+

Spring Core Framework is widely used in Java applications. It allows software developers to develop Java applications with enterprise-level components effortlessly.

Spring4Shell vulnerability allows remote attackers to plant a web shell when running Spring Framework apps on top of JRE 9. It is caused by unsafe deserialization of given arguments that a simple HTTP POST request can trigger and allow full remote access. In fact it is a patch bypass of the old CVE-2010-1622 vulnerability that was introduced 12 years ago.

The exploitation of this vulnerability relies on an endpoint with DataBinder enabled, which decodes data from the request body automatically. 

The specific exploit requires the application to run on Tomcat as a WAR deployment. If the application is deployed as a Spring Boot executable jar, that is the default, it is not vulnerable to the exploit. However, the nature of the vulnerability is more general, and there may be other ways to exploit it.

These are the prerequisites for the exploit:

• JDK 9 or higher
• Apache Tomcat as the Servlet container
• Packaged as WAR
• spring-webmvc or spring-webflux dependency
• Spring Framework 5.3.0 to 5.3.17, 5.2.0 to 5.2.19. Older, unsupported versions are also affected

There are signs of exploitation in the wild for this vulnerability. There are more than 30 repositories with PoC and examples of vulnerable applications on github.

In short, look for Spring Framework applications on your Tomcats and then update them to version 5.3.18 and 5.2.20.

Qualys recommendations for Linux:

• Find java 9+ with locate
• Find “spring-webmvc-*.jar“, “spring-webflux*.jar” or “spring-boot*.jar” in ls -l /proc/*/fd

As an option, you can try to update the Tomcats first. it is easier. While CVE-2022-22965 resides in the Spring Framework, the Apache Tomcat team released new versions of Tomcat to ”close the attack vector on Tomcat’s side.”

The remaining two vulnerabilities are in rarer components that are not part of the Spring Core Framework.

CVE-2022-22963: Remote code execution in Spring Cloud Function by malicious Spring Expression

Spring Cloud Function is a serverless framework for implementing business logic via functions.

In Spring Cloud Function versions 3.1.6, 3.2.2 and older unsupported versions, when using routing functionality it is possible for a user to provide a specially crafted SpEL as a routing-expression that may result in remote code execution and access to local resources. Users of affected versions should upgrade to 3.1.7, 3.2.3. No other steps are necessary.

There are also PoCs for this vulnerability.

And finally, I would like to finish with a vulnerability that came out a month ago. And went quite unnoticed.

CVE-2022-22947: Spring Cloud Gateway Code Injection Vulnerability

Spring Cloud Gateway aims to provide a simple, yet effective way to route to APIs and provide cross cutting concerns to them such as: security, monitoring/metrics, and resiliency.

Applications using Spring Cloud Gateway are vulnerable to a code injection attack when the Gateway Actuator endpoint is enabled, exposed and unsecured. A remote attacker could make a maliciously crafted request that could allow arbitrary remote execution on the remote host.

Users of affected versions should apply the following remediation. 3.1.x users should upgrade to 3.1.1+. 3.0.x users should upgrade to 3.0.7+. If the Gateway actuator endpoint is not needed it should be disabled via management.endpoint.gateway.enabled: false.

There are also PoCs for this vulnerability not only in Github, but also in public packs.