LAST UPDATED April 8, 2022
As we reported yesterday, ThreatX deployed to production a ruleset to protect against Spring4Shell exploits. Since then, the ThreatX SOC has been monitoring for hits against the rule. We have seen some matches, though volume has been relatively low.
In terms of Spring4Shell more generally, early this morning BST, Spring publicly acknowledged the vulnerability. Details are available in a Spring blog: https://spring.io/blog/2022/03/31/spring-framework-rce-early-announcement.
At this point, there is still no CVE for Spring4Shell; once available, we will have greater clarity regarding the relative prioritization of this vulnerability.
A few key takeaways from the Spring blog follow. It is important to know that, unlike the Log4J vulnerability, which impacted anyone with that Apache logging library deployed, Spring4Shell will impact organizations under the following scenarios:
- JDK9 or higher in use
- Running on Apache Tomcat as the servlet container
- Packaged as WAR
In addition, Spring released a full remediation path for those impacted. In the meantime, ThreatX customers can rely on our platform as a threat mitigation capability while steps are taken to enable remediation (e.g., change management and regression testing).
As always, we encourage customers to reach out to the ThreatX SOC with any questions or support required to address Spring4Shell at support@threatx.com.
Originally posted 5:50 pm ET on March 30, 2022
ThreatX Response to Spring4Shell
On March 29, 2022, Spring disclosed a zero-day vulnerability – Spring4Shell. A widely used Java framework, Spring is found within many web applications. If exploited, this vulnerability could enable unauthenticated remote code execution (RCE) by attackers. This is considered a priority vulnerability that should be addressed immediately in Java applications that leverage Spring Core.
Bottom line: Spring Core is vulnerable to RCE.
Upon disclosure, the ThreatX SOC developed and deployed to production a ruleset to protect against Spring4Shell exploits. All ThreatX client sensors are leveraging these precise rules to protect our customers while preventing false positives.
ThreatX has additional rules deployed to specific customers that are particularly at risk of a Spring4Shell exploit. If you feel you are at risk, reach out to the ThreatX SOC to obtain this specific ruleset.
The ThreatX SOC will continue testing against known payloads and monitoring the progression of the Spring4Shell exploit.
We encourage customers to reach out to the ThreatX SOC with any questions or support required to address Spring4Shell at support@threatx.com.
