Spring into action (with SIEM detection rules for Spring4shell)
The Spring Framework is an open source application framework that provides infrastructure support for developing Java applications. The framework can be used by any Java application and was one of the most popular frameworks in 2018.
On March 29, 2022, a Chinese security researcher going by the username “helloexp” published a proof of concept (PoC) on Github before deleting his account, in which one could find multiple exploits for different platforms such as Django, Docker, F5, Chrome, Windows and more.
Screenshot below: helloexp’s 0day repository as it was shortly before being deleted, taken from Google’s cache
The Spring4Shell vulnerability is a zero-click Remote Code Execution (RCE) vulnerability, meaning that a vulnerable system can be exploited remotely without any user interaction whatsoever by sending a crafted HTTP request to a vulnerable system (MITRE ATT&CK T1190). The vulnerability exists in the Spring Core library on JDK9+ and there is no mitigation at the moment besides Praetorian’s suggestion, which is still a temporary solution in the best case and requires source code changes in the vulnerable applications. This exploit does not work on JDK8 and thus a downgrade was suggested by some users, but this could have functionality implications and leave a system vulnerable to different vulnerabilities.
Screenshot below: An example of a payload used to upload a webshell to a vulnerable server using this POC.
Screenshot below: An example of the /etc/passwd file being extracted using the webshell above. The command can be seen in the URL (marked in red). The contents of the file can be seen in the web browser (highlighted).
And if that weren’t enough …
There’s also CVE-2022-22963, a less severe unrelated vulnerability which causes confusion among experts when talking about the latest Spring vulnerabilities. This vulnerability affects a different Java library named Spring Cloud Function and can be mitigated by upgrading to version 3.1.7 or 3.2.3 or newer versions.
Panic, patch, repeat?
According to Spring’s early announcement, the vulnerability does not have a published CVE report as of March 31st and it impacts Spring MVC and Spring WebFlux applications running on JDK 9+. To exploit the vulnerability, there are multiple requirements that need to be met:
- Using JDK9 or higher
- Using Apache Tomcat as the Servlet container
- Packaged as WAR
- Having “spring-webmvc” or “spring-webflux” dependencies
This is according to a VMware CVE report, which was not yet published, and Spring developers acknowledge that there might be other scenarios where the vulnerability could be exploited, even if the conditions above are not met.
Can’t mitigate? Monitor and detect!
There is no way to know if any of these vulnerabilities have been exploited yet and alerting on any attempt to exploit them will create noise which eventually leads to alert fatigue, the SOC’s worst enemy.
Because the exploit means an attacker will try to run commands remotely using Java (MITRE ATT&CK T1190), one thing a SOC could monitor is suspicious processes spawned by Java. To avoid false positives it is recommended to investigate the logs at least 90 days backwards and whitelist known child-process executed by Java.exe
This is possible in multiple platforms, here’s an example of how it can be done for Windows operating systems in various SIEMs:
Splunk Detection Query
search index=[WindowsIndex] sourcetype=WinEventLog EventCode=4688 parent_process_name=*java.exe* “java.exe” | stats values(Account_Name) as AccountName count by ComputerName, parent_process, New_Process_Name
Sumo Logic Detection Query
_sourceCategory=*windows* “4688” “java.exe”
| json field=_raw “EventID” as EventID nodrop
| json field=_raw “Computer” as Computer nodrop
| json field=_raw “EventData.ParentProcessName” as ParentProcessName nodrop
| json field=_raw “EventData.NewProcessName” as NewProcessName nodrop
| where EventID = “4688” and ParentProcessName contains “java.exe”
| timeslice
| count by Computer, ParentProcessName, NewProcessName, _timeslice
Microsoft Sentinel Detection Query
SecurityEvent
| where EventID == 4688 and ParentProcessName contains “java.exe”
| project-reorder Computer, Account, ParentProcessName, NewProcessName, CommandLine
IBM QRadar Detection Query (AQL)
select QIDNAME(qid) as “Event Name”,logsourcename(logsourceid) as LogSource, “New Process Name”, “Creator Process”, sourceip, sourceport, destinationip, destinationport, username, DATEFORMAT(starTTime,’YYYY-MM-dd HH:mm:ss’) as startTime from events
where devicetype=12 and “EventID”=4688 and “Creator Process” = ‘java.exe’
Note: the field “Creator Process” and “New Process Name” might be named differently in every QRadar instance.
Note also that in some cases, some processes are run by Java and these will need to be excluded. In other cases, Java is used as part of another application and usually runs from a specific folder related to this application, in such a case the full path could be excluded.
Conclusion
Just as in previous cases, these vulnerabilities will probably keep us busy for a while. In most cases, this is due to unpatched systems and just like we’re still reading about patching and mitigations for ProxyShell and Log4Shell attacks, we might very well see the effects of Spring4Shell into 2023.
This emphasizes that simply patching vulnerabilities or implementing other mitigations is not sufficient. SOC teams should always create detection and hunting queries in order to make sure there was no breach between the time the vulnerability was disclosed and the time it was eventually patched or mitigated.