To quote Yogi Berra, the immortal New York Yankees catcher, Major League Baseball Hall of Famer and provider of malapropisms, “It’s déjà vu all over again.”
Just when we all thought it was safe to dive back into application development after the pain and churn caused by the Log4j vulnerability and the Log4Shell attacks, here comes yet another beast of a vulnerability to take a chunk out of security and devour valuable resources.
As you likely have already heard, on March 29, 2022, a China-based researcher posted screenshots of a Remote Code Execution (RCE) vulnerability in the Spring Core Java library. The vulnerability has since been assigned CVE-2022-22965, and has been awarded a CVSS severity score of “Critical.” The vulnerability, reported by VMware, had been published to GitHub but was quickly removed. Unfortunately, the damage had been done and the vulnerability was quickly posted in other repositories.
As with many serious vulnerabilities that reach widespread media attention, CVE-2022-22965 has been given a common name as well: Spring4Shell, or in some cases, SpringShell. Regardless, a vulnerability of this severity by any name is definitely dangerous, as Spring libraries are used in a majority of applications as a time-saver for Java programmers.
According to a blog posted by Spring as an early announcement of the RCE on March 31, 2022, the vulnerability impacts Spring MVC and Spring WebFlux applications when running on Java Development Kit (JDK) 9+. It also may require that the application be running on an Apache Tomcat as a WAR. The vulnerability affects Spring Framework versions 5.3.0 to 5.3.17, 5.2.0 to 5.2.19, and older versions. Perhaps more troubling, Spring goes on to warn that “the nature of the vulnerability is more general, and there may be other ways to exploit it that have not been reported yet.”
Also, according to Spring, applications running as Java Archive (JAR) deployments—which is the default—are not vulnerable to CVE-2022-22965; however, the vendor acknowledges that they may be affected by other exploitation techniques.
The Spring4Shell vulnerability also comes on the heels of another. In Spring Cloud Function software, versions 3.1.6 and 3.2.2 as well as in older, unsupported versions, specially crafted routing expressions in Spring Expression Language (SpEL) can be created to access local resources and possibly enable an RCE attack. Originally classified with a “Medium” CVSS severity score, CVE-2022-22963 has since been reclassified as a “Critical” vulnerability. Fixes are available by upgrading to Spring Cloud Function versions 3.1.7 or 3.2.3.
Separate from CVE-2022-22965 and CVE-2022-22963, another vulnerability in Spring, CVE-2022-22950, was reported on March 28, 2022. It’s a denial-of-service (DoS) vulnerability in Spring Framework versions 5.3.0 – 5.3.16 and older, unsupported versions. Spring has released fixes in Spring Framework 5.3.17+.
As of today, Spring4Shell scanners have already been created and deployed, with reports of the vulnerability being actively exploited.
Spring has released versions that fix the CVE-2022-22965 vulnerability, including Spring Framework 5.3.18 and 5.2.20; and Spring Boot 2.5.12 that depends on Spring Framework 5.3.18. (Spring Boot 2.6.6, which also depends on Spring Framework 5.3.18, should be released soon, according to Spring.)
While Spring has done well in releasing fixes to address these gnarly vulnerabilities, the onus once again is on organizations to update and apply the fixes as quickly as possible. The challenge, like with Log4j / Log4Shell issues, is the ubiquity of the libraries and the fact that they may be used in applications of which organizations may not be aware. If they aren’t aware that an application is using an affected set of libraries, how can an organization protect itself and its users from being affected by the exploit?
That’s where F5 comes in.
While there are similarities and differences in the characteristics between the Spring framework vulnerabilities and the Log4j vulnerabilities and Log4Shell exploits, both can be detected and blocked by deploying web application firewalls (WAFs) and similar security solutions.
As an F5 customer, you already have some of the most potent protections in place to defend against attacks based on Spring4Shell and related vulnerabilities. However, F5 urges you and your development teams to upgrade any affected Spring libraries immediately, and if no longer needed, remove any vulnerable Spring libraries from your applications.
Here is how F5 is supporting you and securing your applications, organization, and users through our comprehensive, dynamic security product and services portfolio.
If you’re under attack or are worried that your organization and its apps are vulnerable and exposed, please reach out to our F5 Support team and request an escalation to the F5 SIRT. Available 24/7/365, this team will guide you through patching F5 systems and software, help you with configurations, and assist in deploying F5 iRules to limit any exposure or to mitigate attacks.
F5 has released—and will continue to address and release—signature sets available for BIG-IP Advanced WAF and BIG-IP ASM deployments to block any known attack vectors exposed by Spring4Shell vulnerabilities. Signatures are also being continually updated with protections against any attempts at bypass. Be sure that you have and are working with the most up to date Attack Signature Update (ASU) package.
For customers that have not deployed Advanced WAF or ASM, an iRule may be applied against application to detect, log, and drop any offending traffic that may be targeting specific CVEs.
F5 ensures consistent application security regardless of the F5 platform customers use and deploy. Therefore, customers of NGINX App Protect WAF will receive the same updated signatures simultaneously with BIG-IP Advanced WAF customers. Please ensure that you update your NGINX App Protect WAF signatures. For more information on how to do this, please refer to this guidance. Also, make sure that the “Server Side Code Injection” attack type is enabled in your WAF policy.
The recently released F5 Distributed Cloud Web Application and API Protection (WAAP) protects apps and APIs deployed across clouds and edge sites with F5’s industry-leading, SaaS-based web application firewall (WAF) and bot protection, advanced API security, and L3-L7 DDoS defense. F5’s one WAF approach ensures consistent application security no matter the F5 offering deployed by customers. Therefore, as signatures to address the Spring4Shell vulnerabilities have already been created and made available for BIG-IP Advanced WAF and NGINX App Protect WAF, they have simultaneously been made available for Distributed Cloud WAAP, too. No additional action needs to be taken, because as a Distributed Cloud WAAP customer, you’re already protected.
Like BIG-IP Advanced WAF, NGINX App Protect, and Distributed Cloud WAAP, F5 Distributed Cloud WAF has already received the necessary signatures to protect against exposure related to Spring4Shell vulnerabilities. They’re included in the default WAF policy, so no additional actions are required.
Implementation of the necessary mitigations have already been undertaken by the F5 Silverline team, ensuring customers that their applications are secure from Spring4Shell and related vulnerabilities. Continuously monitoring for threats and ready to apply any necessary mitigations, in concert with F5’s threat research team and you—our customers—F5 Silverline SOC extends your AppSec team, working for you 24/7/365. If you have any questions concerning F5 Silverline, please reach out to the team at firstname.lastname@example.org.
Threat Stack, recently acquired by F5, delivers inspection, detection, and reporting capabilities. The Threat Stack service includes detection rules that determine if a Spring4Shell compromise is a concern and can launch services as root or running from a shell and escalate attempts. For more information, please contact your F5 Sales Representative or visit https://www.threatstack.com.
An attempt to exploit a vulnerability like Spring4Shell typically starts off with automated reconnaissance. F5 Distributed Cloud Bot Defense is your first line of defense. It can stop automated scans, increasing the difficulty factor for attackers trying to find out if your organization has any Spring4Shell-vulnerable web apps. F5 Distributed Cloud Services keep up with the constantly evolving tactics of attackers operating botnets, allowing for real-time adaptation against bot-driven automated attacks.
As Spring libraries are used in a vast majority of Java-based applications, it’s going to be a challenge for organizations like yours to determine the full scope of the vulnerabilities and potential exploits it spawns. It may also take time for you to update all your affected applications, that is if you’re able to find them all. This can leave your apps and organizations vulnerable and exploitable. F5 SSL Orchestrator makes encrypted traffic visible, stopping encrypted threats. It decrypts traffic traversing your network, even server traffic, and automatically routes the traffic to security chains that you can define based on the solutions in your security stack. SSL Orchestrator not only addresses encrypted threats, but can stop encrypted malicious traffic, too, like traffic bound for a command-and-control (C2) server. SSL Orchestrator can not only mitigate CVE-2022-22965, but also protects against future vulnerabilities and exploits.
F5 will help keep you updated and in the loop on the latest regarding Spring4Shell (CVE-2022-22965) and related vulnerabilities, and how F5 is defending against and mitigating any further exploits spawned.
As new information arises, we will update this blog. For further context, you can access the following resources:
K11510688: Spring Framework (Spring4Shell) and Spring Cloud vulnerabilities CVE-2022-22965, CVE-2022-22950, and CVE-2022-22963
K24912123: Mitigate the Spring Framework (Spring4Shell) and Spring Cloud vulnerabilities with the BIG-IP system