Spring vulnerabilities - Log4j flashbacks
Post is about the latest vulnerabilities in Spring framework, without boring details, only facts and what you need to know about these vulnerabilities. (links to detailed info in the post)
Brief overview
31st march: Spring has confirmed RCE in Spring Framework. The team has just released a statement along with troubleshooting guides. Now this vulnerability can be tracked as CVE-2022-22965. Spring4Shell (CVE-2022-22965) vulnerability is related to Spring Framework "data binding" mechanism.
The vulnerability exists in Spring kernel with a JDK version higher than or equal to 9.0. Spring Framework and other frameworks - spring -beans-*.jar files or CachedIntrospectionResults.class .
Unfortunately, two other Spring CVEs were released at the same time with Spring4Shell (CVE-2022-22965), which caused a lot of confusion. These two additional vulnerabilities are not related to Spring4Shell and each of them should be handled separately from Spring4Shell:
- CVE-2022-22963 is an RCE problem of critical severity in Spring Cloud Function. This is a very serious problem, but the Spring Cloud feature is less common than the Spring Framework.
- CVE-2022-22950 is a medium-severity DoS issue in Spring Framework.
Spring4Shell vs Log4Shell
Spring4Shell vs Log4Shell
At the end of 2021, everyone remembers tons of news that Zero-day RCE (remote code execution) vulnerability, also known as Log4Shell, was discovered in Apache Log4j2. The vulnerability was discovered by Alibaba Cloud security team.
This vulnerability is NOT as dangerous as Log4Shell. All attack scenarios are more complex due to the nature of the class loader manipulation attacks that run in Java. Operating Spring4Shell requires deep knowledge of Java to get a functioning POC. Manipulations with the class loader are more difficult to understand than the Log4Shell vulnerability.
Despite all of the above, we do not believe that this problem will be as common as Log4Shell.
Why Spring4Shell so critical and dangerous?
Spring Framework is a very popular environment for developing web applications, and the Spring4Shell vulnerability is at the heart of this environment, which means that many web applications created using the Spring Framework will be affected by this problem.
The highest impact from this vulnerability is remote code execution (RCE).
In the wild cases
Exploitation attempts were made in the first days after discovery Spring4Shell. Even before the fixes were released.
According to Check Point's telemetry, 37,000 Spring4Shell attacks were detected over past time. At the same time, almost every sixth organization worldwide affected by the Spring4Shell zero-day vulnerability has already become a target of attackers. In the first place in terms of the number of victims is Europe, which accounts for 20%.
How to test and fix?
At a high level, your web application may be vulnerable under following conditions:
- Your web application is built on the Spring Framework (for example, using Spring Boot)
- Your web application runs on JDK 9 or any later version.
- Your web application uses data binding to bind request parameters to a Java object.
To test your endpoints, you can use next command:
curl -s -o /dev/null -w "%{http_code}" host:port/path?class.module.classLoader.URLs%5B0%5D=0
If the returned status code is "400" — your endpoint is most likely vulnerable.
Note: that returned status code other than "400" does not guarantee that endpoint is not vulnerable.
The best way to fix SpringShell is to update Spring Framework to version 5.2.20 or 5.3.18.
If an update is not currently possible, official Spring blog suggests changing your application's code and adding @ControllerAdvice, which blocks assignments for some internal ClassLoader fields:
@ControllerAdvice
@Order(Ordered.LOWEST_PRECEDENCE)
public class BinderControllerAdvice {
@InitBinder
public void setAllowedFields(WebDataBinder dataBinder) {
String[] denylist = new String[]{"class.*", "Class.*", "*.class.*", "*.Class.*"};
dataBinder.setDisallowedFields(denylist);
}
}
Concludes
In recent months, we have seen an increase in the number of these types of vulnerabilities in software, and these vulnerabilities are often critical. The impact of these vulnerabilities is evidenced by news about their use in the wild:
It means that if you have been using a product for a long time, then, apart from regular patch management and improving cyber security for your environment, nothing provides you safety from zero-day. Vulners understand this and that's why they exist. We understand that community needs for a single, consistent and cross-correlated database of vulnerabilities. Also, Vulners offers non-intrusive vulnerability management solutions. You can get information about available solutions through our website or contacts.