Another Log4Shell? Not Quite-But Spring4Shell is Serious
As more details emerge on a Spring4Shell, a recently discovered remote code execution (RCE) flaw affecting Spring Framework, security researchers are urging affected users to immediately implement a patch issued by Spring.
Spring’s popularity among Java frameworks rivals that of Struts, Sonatype Field CTO Ikka Turunen said, and the vulnerability affects most known versions of the apps using the framework.
“As with historical RCE attacks, the vulnerability has begun seeing scanning activity. We highly encourage all customers to mitigate and to upgrade to the known good versions as soon as possible,” Turunen wrote in a blog post, warning that attackers likely will jump on the vulnerability. “Drawing from a recent example, the Log4shell vulnerability drew in opportunistic attackers who began quickly exploiting the weakness as soon as a proof-of-concept (PoC) surfaced.”
And, indeed, it was only a couple of days after the flaw’s discovery that SANS ISC Dean of Research Johannes B. Ullrich said in a blog post that he believed bad actors were scanning for apps afflicted with Spring4Shell after observing attempted exploits in its Apache Tomcat honeypots.
“We started seeing some exploit attempts that match the general Spring4Shell pattern early on Wednesday (around 09:20 UTC). The first exploit from one of our larger honeypots came from 38.83.79.203. It was directed at a honeypot listening on port 9001, not the ‘usual’ tomcat port 8080,” Ullrich wrote.
“The currently published exploit will change the logging configuration, writing a file to the application’s root directory. Next, the attacker will send requests that contain code to be written to this new ‘log file,’” the company said. “Finally, the attacker will access the log file with a browser to execute the code. The code in the currently published exploit does create a simple webshell.”
The flaw, which affects the spring-beans artifact, a common transitive dependency of the Spring framework, requires potential victims to be running JDK9 or later. It bypasses an older but recently reinstated CVE-2010-1622.
“This type of vulnerability relies on the software deserializing code, which is at the root of the problem,” Turunen explained.
Ullrich added, “The specific exploit requires the application to run on Tomcat as a WAR deployment.”
Still stinging from the reach and chaos of the Log4j vulnerability, the security industry sounded the alarm early on Spring4Shell, but it looks like the bug is unlikely to cause the same stir. “The level of activity appears to be much less than what we had for Log4shell,” said Ullrich. “Likely because there isn’t a simple one-size-fits-all exploit, and exploitability depends on the application, not just using a particular framework.”
Spring stressed that the flaw is “packaged as a traditional WAR and deployed in a standalone Tomcat instance,” and that “typical Spring Boot deployments using an embedded Servlet container or reactive web server are not impacted.”
While exploitation of Spring4Shell is slower than that of Log4j, the vulnerability is still rated critical and CISA advises immediate remediation. As Sonatype pointed out, the majority of recent versions downloaded (81%) are potentially vulnerable.
After the announcement last week that the Contrast Security Labs team had confirmed the zero-day vulnerability, Contrast Security CISO David Lindner said only time will tell how Spring4Shell stacks up against others like Log4j. “The Contrast Labs team has proven the exploit due to how a Spring application handles binding, and we believe it could have a larger impact than Log4j. Our team is continuing to explore this vulnerability,” he said. “We recommend Java developers specifically set the allowed fields property or properly set the disallowed fields for the known malicious attack patterns within the DataBinder class.”
