As mentioned in the previous Check Point blog regarding Check Point CloudGuard AppSec’s preemptive protection against Spring4Shell cyber-attacks, several vulnerabilities have been identified affecting the popular Java Spring Framework and related software components. So, we got you covered for Day0, but how should your Day1 to DayN look like?
Check Point continues to monitor this and sees exploit attempts against the following vulnerabilities:
While customers that are using AppSec to protect their web applications and services are preemptively protected, and customers using Check Point CloudGuard Workload Security are inherently protected, it is not just a best practice to ensure that vulnerabilities are dealt with to the smallest detail. It is recommended that organizations using Java Spring should immediately review their software and update to the latest versions by following the official Spring project guidance.
Customers using Check Point CloudGuard Workload Security for container environments are also (and inherently) protected against this vulnerability. Read more to learn how.
What we know
A zero-day vulnerability found in the popular Java Web application development framework Spring likely puts a wide variety of Web apps at risk of remote attack, security researchers disclosed on March 30. The vulnerability — aka Spring4Shell or SpringShell by some security research firms — has caused much confusion over the past 24 hours as researchers struggled to determine if the issue was new or related to older vulnerabilities. Independent security research firms confirmed that the exploit attacks a new vulnerability, which could be exploited remotely if a Spring application is deployed to an Apache Tomcat server using a common configuration.
The impact is relatively broad especially at this stage, and as such, those who run non-vulnerable configurations will likely be recommended to patch as soon as possible. If that wasn’t enough, many security researchers agree that proof-of-concept code targeting older, already patched vulnerabilities is still an area of uncertainty. The vulnerability targeted by the exploit is different from two previous vulnerabilities disclosed in the Spring framework this week — the Spring Cloud vulnerability (CVE-2022-22963) and the Spring Expression DoS vulnerability (CVE-2022-22950). Spring, which is now owned and managed by VMware, is currently working on an update, and at this point, threat actors are not yet communicating about the vulnerability.
- Current Status
Spring Framework 5.3.18 and 5.2.20, which contain the fixes, have been released. - Spring Boot 2.6.6 and 2.5.12 that depend on Spring Framework 5.3.18 have been released.
- CVE-2022-22965 has been published.
- Apache Tomcat has released versions 10.0.20, 9.0.62, and 8.5.78 which close the attack vector on Tomcat’s side, see Spring Framework RCE, Mitigation Alternative.
Am I Impacted?
These are the requirements for the specific scenario from the report:
- JDK 9 or higher
- Apache Tomcat as the Servlet container.
- Packaged as a traditional WAR (in contrast to a Spring Boot executable jar).
- Spring-webmvc or spring-webflux dependency.
- Spring Framework versions 5.3.0 to 5.3.17, 5.2.0 to 5.2.19, and older versions.
How does Check Point CloudGuard Workload Security help?
Check Point CloudGuard Workload Security helps across the entire container lifecycle within a single- and multi-cloud deployment – from container image creation through deployment to production and while running in-production. Removing all the variables through a systematic approach from the build process to the runtime will mitigate much uncertainty in a lifecycle that, air gapped or not, is a challenge.
Using Check Point CloudGuard’s ShiftLeft tooling during the build process to discover vulnerabilities such as secrets, keys, CVEs, the issues are found quickly and reported back into a unified platform. As builds are published, we will continually inspect and prevent critical actions of non-compliant activity within this process.
Cloud native workloads demand cloud native security that understands the dynamic nature of the CI/CD process. Check Point CloudGuard automates security from the development stage through runtime, with active threat prevention and continuous code scanning. Customers can reduce DevOps cycles by early security scanning using Check Point CloudGuard’s ShiftLeft tool which scans source code, infrastructure-as-a-code, container images and serverless functions.
With Check Point CloudGuard Workload Security runtime protection, you can detect and block this attack. To see if you were impacted, you can view the logs in your Events tab for logs which are labeled as a Malicious Behavior Signature Event.
You can also detect vulnerable images using the Image Assurance tool to verify that your container environment is actively protected and secured,
Check Point CloudGuard Build Protection and Spring4Shell
During the buildtime while images and dependencies are being orchestrated, developers can scan that process and be notified of exploits of the above CVEs to protect customers using the Spring Framework. Check Point CloudGuard ShiftLeft allows developers to quickly assess vulnerabilities, misconfigurations, leaked credentials, and CVEs. Shiftleft provides seamless integration providing Image Scan, Code Scan, and IaC Scan capabilities.
To learn more, please read the ShiftLeft documentation.
Check Point CloudGuard Workload has integrated the signature requirements on March 31st to identify this vulnerability and prevent it during buildtime.
In addition, findings during the build process can be ingested back into the platform automatically to allow for later reporting or analysis.
Check Point CloudGuard Workload Security Runtime Protection and Spring4Shell
Check Point CloudGuard Workload Security also provides active runtime protection against exploits of the above CVEs to protect customers using the Spring Framework. As events are generated and brought to your attention, you can quickly choose to deny new or existing workloads based on those findings.
In addition you can block all malicious signatures on the cluster using this setting:
Check Point CloudGuard Workload has integrated the signature requirements to identify this vulnerability and block during runtime. You can also use our GSL Editor to create specific rules easily and quickly.
In summary
At first glance, Spring Framework vulnerability does not seem to be nearly as critical as the issues found in Log4j, with attackers needing to know the address, including the application’s endpoint, to exploit the vulnerability. In addition, applications not exposed to the Internet are safe, unlike some cases with Log4j because the exploit could affect systems that were not directly connected to the Internet.
Even so, one cannot hope that this first glance will stay and not develop to a more critical issue, which is usually the nature of such critical issues with such prevalent frameworks that are part of our software supply chain. Customers should ensure that their entire cloud workload lifecycle is protected through a platform that provides them coverage from image building thru production deployment to runtime, and must deploy a machine-learning based Web Application and API Protection solution that requires no signature tuning for such and similar attacks.
Unsurprisingly, the Check Point’s CloudGuard platform delivers a one-stop-shop for all of your cloud security needs, covering the above use cases and much more.
What’s next?
If you currently have container deployments running in Spring and are interested in enhancing your security, sign up today for a free trial.