Intro
A widespread Java library under the Apache Commons project was found to allow remote code execution for publicly exposed web servers that implement one of the vulnerable methods based on user-controlled input.
This is reported to affect Apache Commons Text in versions 1.15 ~ 1.9.
Apache Commons Daily Use
Apache Commons Text is a general purpose text manipulation Java library. It is a well-known feature for developers of any language.
Just for clarity, ordinary use of the library by a Java developer can look something like this:
The above code will output “My current username is SomeUsername” (where “SomeUsername” is the result of the environment variable USERNAME in the host machine).
This is a quick introduction to string interpolation, which is implemented in a variety of languages and libraries. What it teaches us so far is that replace takes a string input and resolves certain predefined parts of the string into their desired value. The ${} scopes where the interpolation occurs, the keyword env determines the type of operation StringSubstitutor should do, and the right-side value is the value to be resolved programmatically.
By taking a closer look, it’s also easy to notice that replace supports other keywords besides env:
Source: commons-text GitHub repository
Each of the above expects a slightly different value and resolves it in its corresponding way.
For example, the dns keyword can be used to perform a DNS lookup of a domain name and put the result inside our string (to output the IP address of cyesec.com as a string):
The Threat
The major attack vector starts if you have an internet-facing web server that uses Java and a vulnerable version of Apache Commons Text. On top of that, the web server has to pass user-controlled input into one of the risky functions in a non-secure way.
The most fearful keyword at the time of writing this article is the script keyword.
For example:
For the script keyword to affect your server, it needs to work with a relatively older version of Java, because newer builds are reportedly not shipped with the built-in JavaScript engine that is needed for the script to execute. At the time of writing this article, the most recent JDK version that was found reported as vulnerable is JDK 11.
Other keywords like dns could also be abused, because if the attacker had managed to control the value inserted into the string, the interpolated value might be later used in your web application in another procedure – although rare, this could trigger chain reactions that lead to other vulnerabilities.
Moreover, the state of the vulnerability is still new, and it’s common for other techniques to pop up soon.
The New Log4Shell?
In short – no, although the risk exists.
There are obvious similarities – another Java library doing risky interpolations. However, as of now, this vulnerability is less likely to be abused than Log4Shell. Here’s why:
- Log4j (the vulnerable library behind Log4Shell) is a logging framework. It’s more common for unsanitized user input to find its way into a logging function rather than to a library like Apache Commons Text, which is explicitly used to perform string interpolations. Developers usually know better than to insert user input into direct interpolations, and more commonly remember to sanitize user input that must go inside such procedures.
- As explained above, several conditions must be met for the vulnerability to be exploited, other than the insecure passing of user-controlled input.
However, this doesn’t mean the risk should be taken lightly.
Am I Affected?
There are preliminary checks that you can do to prioritize your mitigation for this vulnerability.
- Identify services that use the Apache Commons Text library “commons-text” in versions 1.5 ~ 1.9, more so on Web Servers that have a JDK (Java Development Kit) lower than version 11 installed.
- Search within your source code with the use of
StringSubstitutor.createInterpolator(), followed by the reported vulnerable methods.replace(),.replaceIn()and.lookup() - Search for
StringLookupFactoryclass files within compiled .jar files located on your servers.
It’s expected that more accurate techniques to detect the vulnerable instances will be published soon; however, for quick checks you can use these scripts:
On Windows-based servers:
On Linux-based servers:
Mitigations
- Update Apache Commons Text to version 1.10.0 which have script, dns and url turned off by default.
- Once you have identified and prioritized the public servers that make use of the vulnerable library and updated the library version, initiate a focused secure code review, with the goal of determining if user-controlled input is unsafely passed to the vulnerable interpolation methods (like
.replace(),.replaceIn()and.lookup()). - Even after mitigation, it’s recommended to perform a forensic sweep on servers that might have been infected in the period between the bug disclosure to the time the server was mitigated.
- Be alert to the latest discussions – it’s common for variations of the vulnerability to pop up soon, and in unexpected ways.
