December 16, 2021
Detection of Log4Shell Vulnerability and Exploitation Using Devo
Blog
Data: Your Security Advantage
Read More
Detecting Spring4Shell 0-day Vulnerability Using Devo (updated 4/7/22)
vulnerability, Spring4Shell, 0-day, zero day, Java, Spring Core Framework, spring.io, log-based detection, Apache Tomcat
Reading Time : 4min read
Editor’s note: Updated April 7, 2022 – Devo customers can now leverage an IOC lookup table for alerting and threat hunting. See “Create Log-based Detections as Alerts” section below for details.
Updated April 6, 2022 – We have provided an example query to aid SOC teams in generating alerts for their specific WAF data sources. See “Create Log-based Detections as Alerts” below for details.
A critical zero-day vulnerability in Java’s popular Spring Core Framework is being actively targeted, according to multiple reports submitted to Bleeping Computer. Potential impact for this vulnerability is widespread, as the Spring Framework is used in 74% of Java applications, including various cloud provider services like AWS and GCP. When the dust settles, many providers will be affected. The Spring.io security advisory tags the vulnerability as CVE-2022-22965.
In this fast-developing situation, cyber innovators are racing to develop active scanners, firewall rules, and log-based detections to mitigate the Spring4Shell vulnerability. The affected vendor, Spring.io (a VMware subsidiary), issued an emergency announcement followed by a formal security advisory and patch (on 31 March). The first published proof of concept (PoC) was publicly released by Chinese researcher p1n93r on Github two days prior, but the tweets were deleted and the Github account was quickly removed.
Researchers codeplutos, meizjm3i of AntGroup FG Security Lab, and Praetorian were credited for helping speed the response by reporting the zero-day.
Industry and System Impact
Federal, government, and financial services will be among the hardest hit by patching and mitigation requirements — they have fleets of legacy bespoke apps built in Java and to varying coding standards, so identifying affected systems will be challenging.
The vulnerability also will appear across a small swath of the internet of things (IoT) and become a permanent vector for attacker Discovery scans. The Spring Framework and Apache Tomcat (the default of several servers for the Spring Framework) can be compiled to native UNIX/LINUX binaries, and are thus commonly embedded in operational, industrial and medical systems. Detecting such devices across enterprise campuses will require internal active scanning alongside rigorous central logging alerts.
Spring4Shell Exploit Weaponization
Spring4Shell exploit weaponization is rapidly evolving. Cyber vendors are racing to provide detections and network safeguards against a fast-moving timeline:
A Critical Vulnerability
The critical Spring4Shell vulnerability scores a near-maximum 9.8/10 base score according to the CVSSv3 scoring system, as it allows for unauthenticated remote code execution. Successful exploitation is not as trivial as the recent log4shell vulnerability, but may still allow a remote attacker to gain complete control of the target web server by simply posting a malformed HTTP request to an affected endpoint. However, a wide variety of configuration options, underlying servers, and coding decisions mean that vulnerable systems may require customized payloads to trigger exploit.
Unfortunately, this also means the active scanners used to detect potentially vulnerable systems will miss some kinds of vulnerable systems, so log-based detections are still necessary. It’s worth noting that the vulnerability may have existed in Java 9+ since 2017. It is plausible that some advanced persistent threats (APTs) and nation-state groups already have this exploit in their arsenals. However, researchers have not yet uncovered signs of threat actor exploit, but evidence may be discovered following scrutiny of historical event logs.
Impacted Systems
According to impacted vendor Spring.io:
The vulnerability impacts Spring MVC and Spring WebFlux applications running on JDK 9+. The specific exploit requires the application to be packaged as a WAR and deployed to Apache Tomcat. This does mean the exploit does not work for Spring Boot with embedded Tomcat. However, the nature of the vulnerability is more general, and there may be other ways to exploit it.
Vendor Mitigations
Patch, Patch, Patch
According to the vendor security advisory, patches are available and strongly recommended:
Users of affected versions should apply the following mitigation: 5.3.x users should upgrade to 5.3.18+, 5.2.x users should upgrade to 5.2.20+. No other steps are necessary. There are other mitigation steps for applications that cannot upgrade to the above versions. Those are described in the early announcement blog post.
Coding Changes of Custom Java Applications
It is best practice to limit Java class surface by using strict allowlist and denylist configurations to control fields like “class,” “module” and “classLoader.” Praetorian originally recommended the following, which was included as a manual workaround in the vendor’s pre-advisory announcement:
Praetorian recommends creating a ControllerAdvice component (which is a Spring component shared across Controllers) and adding dangerous patterns to the denylist.
Review Newly Created .jsp Files
The Australian Cyber Security Centre (ACSC) recommends reviewing file indices for the recent creation of new .jsp files. Such activity may indicate compromise.
Review Recent Logs for Exploit Attempts
The ACSC also recommends reviewing web application logs for indications of unusual requests that could indicate threat actors achieving persistence through web shells that offer jump points for command and control and lateral movement through the network.
Create New Web Application Firewall (WAF) Rules
WAF rules can help detect and block attempts to scan for the vulnerability. However, the utility and accuracy of these rules may vary widely by environment and are likely to be noisy and prone to false positives. Rapid7 researchers suggested:
String filters offer an effective deterrent, “class.”, “Class.”, “.class.”, and “.Class.”. These should be tested prior to production deployment but are effective mitigation techniques.
Create Log-based Detections as Alerts
To detect exploitation attempts in Devo, we have provided the below example leveraging Cequence Bot Defense as the data source. This can be used as a template to craft equivalent queries in different WAF product logs provided they contain POST request data. This will detect malicious requests in plaintext as well as those that have been obfuscated with base64.
from waf.cequence.botdefense
where method = “POST”
select fromutf8(from64(extractedData)) as postdata,
startswith(postdata, “class.module.classLoader.”),
startswith(extractedData, “class.module.classLoader.”)
Additionally, Devo customers now have access to an IOC lookup table containing IP addresses known to be scanning for Spring4Shell vulnerabilities. This table can be utilized in LINQ queries like so:
select ‘lu/SecOpsSpring4ShellIP'(srcIp) as spring4shell_ip
where isnotnull(spring4shell_ip)
We will continue to update this post and share our results as we develop and test our innovative response to detecting Spring4Shell vulnerabilities.
References
https://tanzu.vmware.com/security/cve-2022-22965
https://spring.io/blog/2022/03/31/spring-framework-rce-early-announcement
https://attack.mitre.org/tactics/TA0007/
https://www.recordedfuture.com/vulnerability-exploit-analysis/
https://www.rapid7.com/blog/post/2022/03/30/spring4shell-zero-day-vulnerability-in-spring-framework/
https://gist.github.com/zmallen/e7901fa77626ab7144fe487bcff2af6d
