Text4Shell: New Vulnerability Alert in Apache Commons
A critical vulnerability with a CVSS score of 9.8 was recently discovered in Apache Commons Text, identified as CVE-2022-42889 and more commonly known as "Text4Shell".
This vulnerability had caused alarm across the industry, arguably being referred to as “the new Log4Shell”. While both are open to Remote Command Execution (RCE) exploitation, key differences distinguish the two vulnerabilities — such as a set of implementation conditions that must exist in Apache Commons for Text4Shell to work.
The Prisma Cloud security research team is actively monitoring the exploitation of Text4Shell vulnerabilities in the wild. At the time of this writing, no malicious binary samples have been identified. Should any malware samples be identified, researchers will work with Unit 42 to ensure that detection and protection courses of actions are in place across the Palo Alto Networks product lines, including within Prisma Cloud.
Technical Details
In this blog post we cover details about the vulnerability, its level of impact, and steps to mitigate it including recommendations for Prisma Cloud customers.
Apache Commons Text Overview
Originally released by the Apache Foundation in 2017, Apache Commons Text is an open-source Java library that handles and manipulates strings beyond the capacity offered in the core Java library.
One of the main functions of the Apache Commons Text library is the evaluation and substitution of placeholders by their respective values, similar to what Bash does when executing a command like "echo ${HOME}", replacing the HOME variable with the corresponding value.
Vulnerability Details
CVE-2022-42889, a.k.a Text4Shell, is taking advantage of the StringSubstitutor class when used with default interpolators. The StringSubstitutor class is responsible for substituting all variables within a given text. An application can be exposed to a variety of security risks when StringSubstitutor is used with default interpolators.
Let's take a look at the following line:
StringSubstitutor.createInterpolator() will create a new instance of default interpolator containing configured default lookups using interpolatorStringLookup (which is using StringLookupFactory’s addDefaultStringLookups function for that purpose, as shown in figure 5).
This allows the interpolator to perform string lookups when "${prefix}" variable is specified within a passed text where "prefix" is one of lookup keys defined in StringLookupFactory class. The issue is that, prior to the fix, vulnerable implementations contained "script", "url" and "dns" string lookups specified in default.properties and added these as default string lookups in StringLookupFactory class:
Using default interpolators might lead to an unsafe script evaluation if a malicious text is passed to StringSubstitutor.replace() or StringSubstitutor.replaceIn() methods. Looking at scriptStringLookup documentation, we can understand that "script" string lookup will allow us to execute code. All you need to do is specify the ${script} variable in a text and provide "ScriptEngineName:Script" key value after the colon.
Passing text inside the replace() method will convert javascript:1+1 to 2.
It then might be possible to execute arbitrary code on a vulnerable machine once a malicious actor has gained control of the value being passed to replace() or replaceIn() methods:
In figure 7, you can see the payload string assigned to mal_str. Later this string is interpolated by the default interpolator replace() function, which will trigger scriptStringLookup due to a script key present in a payload string and execute the payload. So, if a vulnerable application will interpolate user-controlled input in a similar way — for example, a search query submitted by a user — then it’s exposed to arbitrary code execution and a malicious actor can pass the following string to achieve the execution:
Comparison with Log4Shell
Because Text4Shell uses string lookups and the attack vector while also involving a Java library, Text4Shell has been compared to Log4Shell (which explains the “4Shell” suffix). But risk is where the two vulnerabilities diverge.
The likelihood of being affected by Text4Shell, as opposed to Log4Shell, is lower because of the implementation conditions that must be present for exploitation to succeed.
Text4Shell Fix
Apache has released a fix, disabling dangerous string lookups by default. If you haven’t updated to version 1.10.0, you should do so immediately.
Prisma Cloud customers can apply controls to address this vulnerability across multiple stages in the application lifecycle from code stage to the runtime environment.
Web Application and API Security: Blocking Text4Shell Exploits
Prisma Cloud Enterprise Edition and Compute Edition (version 21.08 and later) offer Web Application and API Security (WAAS) virtual patches to block exploits.
To mitigate the issue we recommend using the WAAS custom rules for Log4Shell, Spring4Shell and Client-Side Template Injection.
Container Security: Vulnerability Management and Runtime Protection for Containers
If you’re using Prisma Cloud, you can detect affected images and hosts under the Vulnerabilities tab. The platform detects commons-text packages and alerts on entities running with a vulnerable version. In addition, our users can search for CVE-2022-42889 in Vulnerability Explorer section and discover more details about the vulnerability and assets affected by it. Please see Figure 10 for an example.
Prisma Cloud users can also prevent images containing vulnerabilities from being deployed while allowing specific trusted sources. The platform automatically builds runtime models of your images using machine learning and lets you create runtime policies that prevent anomalous behavior.
Software Composition Analysis: Detecting and Remediating in Code
Prisma Cloud Enterprise Edition offers Software Composition Analysis (SCA) that can detect, block and remediate instances of CVE-2022-42889 found in code. Our built-in integrations can notify developers of vulnerable packages as changes are made to those repositories in their IDE, as a CLI run, in PR comments and in CI/CD runs. Administrators can choose to block pull requests/merge requests that contain the vulnerability.
Periodic scans will identify the vulnerability in code repositories and provide an automatic PR fix to remediate the issue.
Summary
Security teams need to take action to discover all vulnerable instances and patch this vulnerability as soon as possible.
Prisma Cloud customers can apply controls to address this vulnerability across multiple stages in the application lifecycle from code stage to the runtime environment. For example, Prisma Cloud can identify Text4Shell early in your development lifecycle, in container images and code repositories. In cases where you cannot immediately patch, Prisma Cloud provides compensating controls via Web Application and API Security and runtime protection to actively block Text4Shell exploits.