On March 29, 2022, a Chinese cybersecurity research firm leaked an attack that could impact most enterprise Java applications, globally. An investigation of the issue showed that the root cause was a vulnerability in the widely used, free, community-developed, open-source programming framework called Spring Core.
The Spring Framework is the foundation for most enterprise applications written in the Java programming language. Our recent data showed Spring Core as being used by 74% of Java applications. Specifically, Spring provides the plumbing of enterprise applications so that teams can focus on application-level business logic, without unnecessary ties to specific deployment environments.
As of Wednesday, March 30, the Contrast Security Labs team confirmed the 0-day vulnerability by use of a public poc, Spring4Shell, which could be the source of Remote Code Execution (RCE).
Spring translates the body and parameters of an HTTP request and turns them into a domain object for developers to use. This makes their lives easier.
In the process of building an object graph to give to the developer, Spring takes special care not to let attackers control any parts of the Class, ProtectionDomain, and ClassLoader of the instance being created. Unfortunately, changes to the Class object in Java 9 meant the checks Spring performed were no longer enough.
The code in question is shown here:
https://github.com/spring-projects/spring-framework/blob/b595dc1dfad9db534ca7b9e8f46bb9926b88ab5a/spring-beans/src/main/java/org/springframework/beans/CachedIntrospectionResults.java#L288
PropertyDescriptor[] pds = this.beanInfo.getPropertyDescriptors();for (PropertyDescriptor pd : pds) {if (Class.class == beanClass && (classLoader.equals(pd.getName()) || protectionDomain.equals(pd.getName()))) {// Ignore Class.getClassLoader() and getProtectionDomain() methods nobody needs to bind to thosecontinue;}
This code attempts to restrict access from overriding these object graph paths:
However, because the Class object now exposes a getModule() method, attackers can now take this slightly different path:
The introduction of Class#getModule() couldnt have been directly foreseen when they wrote this code, although we could have a spirited debate about the robustness of this style of check.
The consequences of handing users control of properties of the ClassLoader depend on the features of the ClassLoader being exploited.
The exploit and PoC being run around shows an attacker exploiting features of Tomcat 9s WebAppClassLoaderBase. The exploit works in a few stages:
Java 9 was released in July of 2017, so this vulnerability has been exploitable in production apps and APIs for five years.
The video below shows the exploit in a few quick requests. The exploit posts a payload to the index of the basic Spring boot application. The exploit takes advantage of the missing binding configuration and creates a malicious JSP on the filesystem in a web-accessible directory. From there, a request is sent with the id command to request the current ID of the user which returns as uid=0(root) gid=0(root) groups=0(root) which shows in this case the application is running as root.
There are a few requirements for an application to be vulnerable:
All of the above, plus you must be running Tomcat (unknown ranges of versions yet, but certainly including 9), because the exploit takes advantage of Tomcats ClassLoader and logging facility to write a malicious, backdoor JSP.
Its prudent to assume that exploits will be coming that take advantage of different class loaders or another environment context and that any vulnerable Spring applications that satisfy the conditions of the first section will be vulnerable.
For now, Contrast Labs recommends:
1) For all who are using Spring core and binding to non-basic types such as POJOs, set the allowed fields to specify the only bindings you wish your application to use.
2) For Contrast customers, ensure Contrast Protect is enabled on your Spring applications (especially those on JDK 9+). As you can see in the video below, when Protect is configured properly, it blocks the attack.
Spring4Shell with Protect Video:
To best protect your applications these are the settings you should enable in your Protect monitored applications in blocking mode.
(a) Command Injection in blocking mode
Example when Command Injection is in Blocking mode.
(b) For more visibility of attacks targeting your environment Enable CVE Shields for CVE-2014-0112 and CVE-2014-0114 (these specific CVE shields are for Struts issues, however, due to the similar nature of the payloads, this provides visibility into attacks through Probes)
Example when CVE shields are enabled
We have published communication to our Support Portal letting customers know we are researching implications and we will let them know exactly how they can fix this issue in their systems. Our team is currently researching the ability to exploit this vulnerability outside of a Tomcat environment.
As always, Contrast will continue to monitor the situation with Spring4Shell. The security of our customers is of utmost importance to us. If you have any questions, concerns, or would like to discuss this issue further, please dont hesitate to reach out to us at [emailprotected].
*This blog article will include updates about Spring4Shell as they become available.
David Lindner & Arshan Dabirsiaghi
By subscribing to our blog you will stay on top of all the latest appsec news and devops best practices. You will also be informed of the latest Contrast product news and exciting application security events.
On March 29, 2022, a Chinese cybersecurity research firm leaked an attack that could impact most enterprise Java applications, globally. An investigation of the issue showed that the root cause was a vulnerability in the widely used, free, community-developed, open-source programming framework called Spring Core.
The Spring Framework is the foundation for most enterprise applications written in the Java programming language. Our recent data showed Spring Core as being used by 74% of Java applications. Specifically, Spring provides the plumbing of enterprise applications so that teams can focus on application-level business logic, without unnecessary ties to specific deployment environments.
As of Wednesday, March 30, the Contrast Security Labs team confirmed the 0-day vulnerability by use of a public poc, Spring4Shell, which could be the source of Remote Code Execution (RCE).
Spring translates the body and parameters of an HTTP request and turns them into a domain object for developers to use. This makes their lives easier.
In the process of building an object graph to give to the developer, Spring takes special care not to let attackers control any parts of the Class, ProtectionDomain, and ClassLoader of the instance being created. Unfortunately, changes to the Class object in Java 9 meant the checks Spring performed were no longer enough.
The code in question is shown here:
https://github.com/spring-projects/spring-framework/blob/b595dc1dfad9db534ca7b9e8f46bb9926b88ab5a/spring-beans/src/main/java/org/springframework/beans/CachedIntrospectionResults.java#L288
PropertyDescriptor[] pds = this.beanInfo.getPropertyDescriptors();for (PropertyDescriptor pd : pds) {if (Class.class == beanClass && (classLoader.equals(pd.getName()) || protectionDomain.equals(pd.getName()))) {// Ignore Class.getClassLoader() and getProtectionDomain() methods nobody needs to bind to thosecontinue;}
This code attempts to restrict access from overriding these object graph paths:
However, because the Class object now exposes a getModule() method, attackers can now take this slightly different path:
The introduction of Class#getModule() couldnt have been directly foreseen when they wrote this code, although we could have a spirited debate about the robustness of this style of check.
The consequences of handing users control of properties of the ClassLoader depend on the features of the ClassLoader being exploited.
The exploit and PoC being run around shows an attacker exploiting features of Tomcat 9s WebAppClassLoaderBase. The exploit works in a few stages:
Java 9 was released in July of 2017, so this vulnerability has been exploitable in production apps and APIs for five years.
The video below shows the exploit in a few quick requests. The exploit posts a payload to the index of the basic Spring boot application. The exploit takes advantage of the missing binding configuration and creates a malicious JSP on the filesystem in a web-accessible directory. From there, a request is sent with the id command to request the current ID of the user which returns as uid=0(root) gid=0(root) groups=0(root) which shows in this case the application is running as root.
There are a few requirements for an application to be vulnerable:
All of the above, plus you must be running Tomcat (unknown ranges of versions yet, but certainly including 9), because the exploit takes advantage of Tomcats ClassLoader and logging facility to write a malicious, backdoor JSP.
Its prudent to assume that exploits will be coming that take advantage of different class loaders or another environment context and that any vulnerable Spring applications that satisfy the conditions of the first section will be vulnerable.
For now, Contrast Labs recommends:
1) For all who are using Spring core and binding to non-basic types such as POJOs, set the allowed fields to specify the only bindings you wish your application to use.
2) For Contrast customers, ensure Contrast Protect is enabled on your Spring applications (especially those on JDK 9+). As you can see in the video below, when Protect is configured properly, it blocks the attack.
Spring4Shell with Protect Video:
To best protect your applications these are the settings you should enable in your Protect monitored applications in blocking mode.
(a) Command Injection in blocking mode
Example when Command Injection is in Blocking mode.
(b) For more visibility of attacks targeting your environment Enable CVE Shields for CVE-2014-0112 and CVE-2014-0114 (these specific CVE shields are for Struts issues, however, due to the similar nature of the payloads, this provides visibility into attacks through Probes)
Example when CVE shields are enabled
We have published communication to our Support Portal letting customers know we are researching implications and we will let them know exactly how they can fix this issue in their systems. Our team is currently researching the ability to exploit this vulnerability outside of a Tomcat environment.
As always, Contrast will continue to monitor the situation with Spring4Shell. The security of our customers is of utmost importance to us. If you have any questions, concerns, or would like to discuss this issue further, please dont hesitate to reach out to us at [emailprotected].
*This blog article will include updates about Spring4Shell as they become available.
Read more:
New Spring4Shell Zero-Day Vulnerability Confirmed: What it is and how to be prepared - Security Boulevard
