A summary of CVE-2022-22963 (Spring Cloud RCE)

At e2e-assure, we do a lot of work behind the scenes to protect our customers, both proactively through the likes of threat hunting, but also reactively as new vulnerabilities become known. Over the years we’ve worked tirelessly to ensure customer networks are up-to-date and that we can detect and respond to exploits.

We know from talking to many people at a range of different organisations that keeping up with new trends, vulnerabilities and threats is always a significant concern, whether you have a large in-house team of cyber security experts, are a CISO with a small team or are a non-cyber expert, taking on additional responsibility as your organisation scales.

This is the first of many blogs which aims to help keep you updated on the latest vulnerabilities and threats. In this instance, we detail our work on the Spring Cloud vulnerability reported at the end of March. The objective is to explain the vulnerabilities identified, understand the risks and response taken by e2e-assure to protect customers and provide useful guidance on additional steps organisations should take to mitigate against these threats. We will try to keep this in as simple a language as possible, however, due to the technical nature of the work done, this is not always possible.

For ease of summation and comparison, we will share the information in the same format seen below – please let us know if you’d like additional fields included to cover specific concerns or questions you have.

Details of the vulnerability

Vulnerability: CVE-2022-22963: Remote code execution in Spring Cloud Function by malicious Spring Expression.

Severity: 9.8 (Critical) Rated by U.S. NIST National Vulnerability Database.

Summary of vulnerability: Vulnerability in the routing functionality of Spring Cloud Function that allows code injection through Spring Expression Language (SpEL) by adding a special spring.cloud.function.routing-expression header to an HTTP request, leading to unauthenticated remote code execution (RCE).

Non-technical summary of e2e's fix: e2e Consultants reverse-engineered the available proof of concept (POC) exploit code on the internet to extract information used to construct detection logic to create Cumulo alerting rules and perform historic searches for exploit activity in customer environments.

Technical summary: The working exploit POC code samples analysed by e2e Consultants showed that the vulnerable function is exploited by crafting an HTTP/S POST request containing the exploit code placed in the HTTP header using the spring.cloud.function.routing-expression parameter to inject the value the vulnerable function via the web server URI path “/functionRouter”.

For example, the below string placed in the header of an HTTP/S post request to https://vulnerable.webserver.com/functionRouter will place a file called “test” in the /tmp folder of the underlying operating system.'spring.cloud.function.routing-expression:T(java.lang.Runtime).getRuntime().exec("touch /tmp/test")'

This is a fairly benign example; however this method can easily be used to execute OS commands or place web shells for persistence purposes on the vulnerable web server. The malicious request will return an HTTP 500 response from the web server, but the code will be executed.

When running queries against our customers’ Cumulos based on the detection logic we were seeing evidence of automated scans from the internet against our customers in Cumulo using exploit code based on the POC for this vulnerability within 12 hours of confirmation of the Proof of Concept exploit.

e2e and Cumulo rules: e2e-consultants created early detection rules looking for HTTP/S POST requests to the URI path “/functionRouter” returning an HTTP 500 reponse to detect successful exploit attempts using this method. Since many web-based security control event logs don’t include HTTP/S header information by default, we decided to leave the header value out of the detection rule and add the header analysis step to the SOC playbook as a manual analysis step where successful exploitation has been observed.

Due to the nature of Cumulo, all customers had the rules applied automatically, reducing the work needed by any in-house teams and minimising the time between the exploit being identified and customers being fully covered.

3rd party rules: The day after we created our custom early detection rules, Snort Talos added included an exploit detection rule for CVE-2022-22963 under sig id 1:59388 in their 2022-03-31 update https://snort.org/advisories/talos-rules-2022-03-31.

This was automatically applied to our customers’ pcap IDS sensors. We also ran Cumulo alerting rules and reviewed historical searches that queried Azure Log Analytics (KQL), covering Barracuda Web Application Firewalls (WAFs) and Azure Web App logs.

In addition to the Cumulo rules being automatic, we also included other SIEM tools’ threat intelligence. This adds value to customers as it removes the need for them to manually take the threat intelligence and rules from Github and place them into Sentinel, as an example.1

Technology covered: The alerting rules based on our detection logic were pushed out to Cumulo to detect the exploit where web request and response events were being captured and analysed, including the following sources: Zeek/Bro Network Security Monitoring, Appliance and cloud based WAFs, Web Servers, Load Balancers and Reverse Proxies

Constraints: A lack of request header values in web based log sources prevented us from including detection logic targeting malicious code included in HTTP/S header content. Header analysis was performed by our SOC where possible based on steps in our investigation playbooks.

Time to implement: CVE-2022-22963 exploit detection rules were in place on Customer Cumulo within 2 working hours of confirmation of the POC as legitimate and working, for a total of 8 hours – all completed and with customer Cumulo platforms updated before they returned to work the following morning.

Preventative Recommendations: Run important internet-facing web applications behind a Web Application Firewall (WAF) or application load-balancer/proxy with WAF functionality, ideally with an active ruleset based on OWASP Web Application Security Risks. In addition, ensure you include third party application libraries, frameworks and plugins running on your web and application servers into your vulnerability management program and patch accordingly.

Detective Recommendations: Ensure you are providing your SOC with enough information to analyse and detect anomalies in requests and responses to your web and application servers. Ensure that fields such as request headers are included in events to ensure visibility of attacks that abuse this functionality (log4j etc.). Where network-based detection does not have adequate visibility (e.g. TLS encryption), ensure your SOC has access to host-based web logs from web servers or intermediate services such as reverse proxies or load balancers.

Summary

Whilst this is the first blog post summarising our work on a recent vulnerability, this is part and parcel of what our customers have always received from e2e, to improve their cyber security and protect them from new threats and vulnerabilities.

A lot of this work took place in the evening, meaning that the working hours from POC being tested and a fix and ruleset change was only 2 hours. It’s this speed of response and commitment to working out of hours to ensure our customers enjoy the best a SOC can offer that our customers love and that has helped us to grow over the years.

As this is our first update, we’d welcome your feedback on changes to the format and information provided, please email info@e2e-assure.com with any suggestions.
If you’d like to find out more about our SOC Platform, Cumulo, that we mention in this article, you can visit our webpage or discuss the platform or anything cyber security with our experts via https://www.e2e-assure.com/contact.