FullHunt developed an open-source tool for discovering Spring4Shell RCE at scale.
Detecting Java Spring RCE at scale
The Spring4Shell RCE is a CVE-2022-22965 critical vulnerability that has been exploited by threat actors this weekend. At FullHunt, we developed, spring4shell-scan: a fully automated, reliable, and accurate scanner for finding Java Spring RCE (Spring4Shell). It was mainly available for our customers during the past days. We’re glad to be open-sourcing it now!
FullHunt vs. Spring4Shell
As soon as the Spring4Shell vulnerability was announced, we started investigating the exploitability of these vulnerabilities. The FullHunt platform already supports the discovery and automatic classification of Spring apps. This was a life-saver feature to be able to map all Spring apps within hundreds of thousands of assets while the vulnerability has been released.
We focused on researching the detection of Spring4Shell CVE-2022-22965 vulnerability and the Spring Cloud RCE CVE-2022-22963.
How to detect Spring4Shell and Spring Cloud RCE?
The Spring4Shell is essentially a Java Deserialization vulnerability that can be highly noisy and sensitive during its detection and exploitation. The current way that we observed to be used by threat actors makes use of the initially published Proof of Concept that was shared online. The initial Proof of Concept takes an unsafe approach where a JSP web-shell is uploaded when knowing the correct path (while being set to a default path). This is inaccurate, can be easily detected, can definitely be easy to evade.
The approach that FullHunt has taken works by sending a corrupted raw object that triggers an exception when deserialized. Once an exception is detected, a check is sent to validate that the payload has effectively triggered an exception - so that if an API endpoint for instance is already returning 4XX or 5XX errors, it wouldn’t cause a False Positive. Additionally, within spring4shell-scan, payloads are tested in different HTTP methods, as we have higher accuracy in testing in different HTTP methods.
This approach also applies to Spring Cloud CVE-2022-22963, where a malicious SpEL query can lead to remote code execution. We have found that sending corrupted SpEL queries can be a valid method for discovering the Spring Cloud CVE-2022-22963.
WAF rules? We bypassed them during our tests
The main approach that several companies have used to protect against the new Spring4Shell (CVE-2022-22965) and CVE-2022-22963 are through WAF rules provided by vendors. We have developed payloads that have been tested against several WAF vendors, and it was confirmed to be bypassing the majority of WAF rules during our tests. It’s advised to contact your WAF vendor to make sure that the new techniques developed by FullHunt are blocked.
We mainly recommend that companies update their Spring setup and dependencies as the approach for remediating these sets of vulnerabilities. Virtual patching through WAF should be only taken as a temporary approach.
As many companies are facing challenges discovering its Spring deployments. We have been helping companies map its Spring deployments, scan them for all of the released Spring vulnerabilities, and run continuous security scanning.
Demo
spring4shell-scan Project: github.com/fullhunt/spring4shell-scan
Are you an enterprise that is looking for help with scanning for Spring4Shell, discovering all the externally public assets, network services, applications, services, and endpoints? Please request a FullHunt Enterprise trial and we will be happy to solve your challenges.
Discover unknown assets today and protect your organization
Best regards,
Mazin Ahmed
The FullHunt Team