Detecting and Mitigating CVE-2022-22963: Spring Cloud RCE Vulnerability

Today, researchers found a new HIGH vulnerability on the famous Spring Cloud Function leading to remote code execution (RCE). The vulnerability CVE-2022-22963 would permit attackers to execute arbitrary code on the machine and compromise the entire host.

After CVE 2022-22963, the new CVE 2022-22965 has been published. The new critical vulnerability affects Spring Framework and also allows remote code execution.
This article has been updated on 2022-04-02.

The Spring Cloud Function versions impacted are the following:

• 3.1.6
• 3.2.2
• Older, unsupported versions

Using routing functionality, it is possible for a user to provide a specially crafted Spring Expression Language (SpEL) as a routing-expression to access local resources and execute commands in the host.

Since Spring Cloud Function can be used in Cloud serverless functions, like AWS Lambda or Google Cloud Functions, those functions might be impacted as well.

This is the second very high vulnerability discovered in the last few months after the Log4jshell remote code execution vulnerability was found in the Log4j Java library.

In this article, you’ll understand the CVE-2022-22963, and how to exploit and mitigate the vulnerability using Sysdig.

What is Spring Cloud Function

Spring is an open source lightweight Java platform application development framework used by millions of developers using Spring Framework to create high-performing, easily testable code.

In particular, for this vulnerability, we are going to see the Spring Cloud Function framework. The Spring Cloud Function framework allows developers to write cloud-agnostic functions using Spring features. These functions can be stand-alone classes and one can easily deploy them on any cloud platform to build a serverless framework.

The major advantage of Spring Cloud Function is that it provides all the features of Spring Boot-like autoconfiguration and dependency injection.

Let’s now see where the issue is around the vulnerability CVE-2022-22963.

The CVE-2022-22963 issue

The issue with CVE-2022-22963 is that it permits using HTTP request header spring.cloud.function.routing-expression parameter and SpEL expression to be injected and executed through StandardEvaluationContext.

As we can see from the patch, a new flag isViaHeader was added to perform the validation before parsing the header content. This suggests that the vulnerability is limited to an HTTP attack path.

We also notice how it worked before where the value was used prior to any validation.

The impact of CVE-2022-22963

According to the CVSS system, it scores 9.8 as HIGH severity.

The high impacts on confidentiality, integrity, and availability, as well as the ease of exploitation, make this really critical for all users adopting this solution.

Exploiting the vulnerability is possible to achieve the total compromise of the host or container executing arbitrary commands.

Since Spring Cloud Function might be used in Cloud serverless functions, those functions might be vulnerable in the same way, leading the attackers inside your cloud account.

How to exploit CVE-2022-22963

Exploiting the vulnerability is quite easy to accomplish. In our GitHub, you can find the images to run and try the exploitation. Here is the reported curl command to exploit the vulnerability.

curl -i -s -k -X $'POST' -H $'Host: 192.168.1.2:8080' -H $'spring.cloud.function.routing-expression:T(java.lang.Runtime).getRuntime().exec(\"touch /tmp/test")' --data-binary $'exploit_poc' $'http://192.168.1.2:8080/functionRouter'

With this curl, it’s trivial to create a file on the operating system but it could be used to open a reverse shell on the vulnerable host or container.

How to detect and mitigate CVE-2022-22963

If you’re impacted by CVE-2022-22963, you should update the application to the newest versions 3.1.7 & 3.2.3.

Even though you might have already upgraded your library or applied one of the other mitigations on containers affected by the vulnerability, you need to detect any exploitation attempts and post-breach activities in your environment.

You can detect this vulnerability at three different phases of the application lifecycle:

• Build process: With an image scanner.
• Deployment process: Thanks to an image scanner on the admission controller.
• Runtime detection phase using a runtime detection engine: Detect malicious behaviors in already deployed hosts or pods.

Let’s now dig deeper into each of them.

1. Build: Image Scanner

Using an image scanner, a software composition analysis (SCA) tool, you can analyze the contents and the build process of a container image in order to detect security issues, vulnerabilities, or bad practices.

In the report results, you can search if the specific CVE has been detected in any images already deployed in your environment.

We can see that CVE-2022-22963 affects one specific image which uses a vulnerable version.

At the time of the writing of this article, multiple vulnerability-tracking databases were not yet updated to reflect the severity of this vulnerability. As a stopgap solution, pictured below, you can also blacklist vulnerable versions of affected packages. Pictured is a “warn” policy, which will not stop the execution of a vulnerable image.

2. Deploy: Image scanner on admission controller

Implementing image scanning on the admission controller, it is possible to admit only the workload images that are compliant with the scanning policy to run in the cluster.

This component is able to reject images based on names, tags, namespaces, CVE severity level, and so on, using different criteria.

Creating and assigning a policy for this specific CVE-2022-22963, the admission controller will evaluate new deployment images, blocking deployment if this security issue is detected.

Again, in the event of an incomplete vulnerability feed, you can block images containing specific package names and versions.

3. Runtime Response: Event Detection

Using a Runtime detection engine tool like Falco, you can detect attacks that occur in runtime when your containers are already in production.

Here is a reverse shell rule example. To avoid false positives, you can add exceptions in the condition to better adapt to your environment.

- rule: Reverse shell
  desc: Detect reverse shell established remote connection
  condition: evt.type=dup and container and fd.num in (0, 1, 2) and fd.type in ("ipv4", "ipv6")
  output: >
    Reverse shell connection (user=%user.name %container.info process=%proc.name parent=%proc.pname cmdline=%proc.cmdline terminal=%proc.tty container_id=%container.id image=%container.image.repository fd.name=%fd.name fd.num=%fd.num fd.type=%fd.type fd.sip=%fd.sip)
  priority: WARNING
  tags: [container, shell, mitre_execution]
  append: false

Conclusion

Spring Cloud Function vulnerability is another in a series of major Java vulnerabilities. Much like Log4j, it only requires an attacker to be able to send the malicious string to the Java app’s HTTP service. CVE-2022-22963 has a very low bar for exploitation, so we should expect to see attackers heavily scanning the internet. Once found, they will likely install crypto miners, botnets agents or their remote access toolkits.

The best defense for this type of vulnerability is to patch it as soon as possible. Having a clear understanding of the packages being used in your environment is a must in today’s world. Using modern tools, such as SCA, can help accomplish this goal and prioritize systems appropriately.