• Remnant of Log4Shell?

• PoC of CVE-2022-42889

• Detecting Text4shell using Logpoint

• Apply mitigations without delay

On Oct. 13, 2022, the Apache Software Foundation released a security advisory for a critical zero-day cyber security vulnerability in Apache Common Text from version 1.5 to 1.9. Labeled CVE-2022-42899, Text4shell has a 9.8 severity out of 10 using the CVSSv3 calculator as it leads to remote code execution when exploited. Though multiple Proof of Concepts (PoCs) are arising by the day around each issued fix, the recommended fix is to upgrade to the latest 1.10 version.

Remnant of Log4Shell?

As is the trend with all *4Shell named vulnerabilities, Text4Shell is being compared to Log4Shell, a major bug that shook the infosec community last year. Apache’s security team offered additional context on the Log4Shell vs. Text4Shell comparison in a recent blog, which reads in part:

This issue is different from Log4Shell (CVE-2021-44228) because in Log4Shell, string interpolation was possible from the log message body, which commonly contains untrusted input. In the Apache Common Text issue, the relevant method is explicitly intended and clearly documented to perform string interpolation, so it is much less likely that applications would inadvertently pass in untrusted input without proper validation.

However, Text4Shell is an issue in Apache Commons Text library, a common Java library that provides utilities to work with strings. This library has a handy feature, string substitution, that allows the user to replace certain pieces of text with another. Using an interpolator and dynamically created strings Apache Commons Text provides value lookup by default. The main issue lies within the StringSubstitutor API.

According to Apache documentation, “The class is used to substitute variables within a string by values. StringSubstitutor class takes a piece of text and substitutes all the variables within it.” The standard format for interpolation/substitution is “${prefix: name}”, where “prefix” is the lookup key that is shown in the below image and “name” are those strings whose values are processed by the lookup methods.

Available String Lookups

This is where vulnerability comes into play in versions from 1.5 up to 1.9. From Alvaro Munoz’s disclosure of this threat,

The StringSubstitutor when used with the default interpolators (StringSubstitutor.createInterpolator()) will perform string lookups that may lead to arbitrary code execution.

In particular, if untrusted data flows into the StringSubstitutor.replace() or StringSubstitutor.replaceIn() methods, an attacker will be able to use the ScriptStringLookup to trigger arbitrary code execution.

The affected interpolators are:

• script: used to evaluate expressions using the JVM script execution engine (javax.script)
• dns: used to resolve DNS records
• url: used to request information from a URL

A logic flaw in the StringSubstitutor class makes the additional lookup keys: “script,” “dns,” and “url” available by default which should not be available according to the documentation. The additional interpolation methods provide ways of accessing the network, contacting remote servers, and code execution. The mentioned capabilities are intended features but are not provided by default until and unless the additional features are configured. The user input is passed on to StringSubsitutor without validating the input. As a result, adversaries can call string lookup methods like “script” to execute OS commands.

PoC of CVE-2022-42889

In order to reproduce the attack, a vulnerable component using apache common text needs to be run. In our case, we use a docker environment which can be found here.

In the demo environment, the vulnerability can be found on the web server’s search API where the StringSubstitutor class of Commons Text is implemented. We then use the string lookup function “script” which can execute the payload utilizing the JVM script execution engine (javax.script).

The conditions required for Text4Shell are:

• The application is using Apache Commons Text, version 1.5 through 1.9 inclusive
• The application imports org.apache.commons.text.StringSubstitutorand uses one of the following default interpolators with the default configuration
  • dns
  • script
  • url

With these checks in place, the following payload can be used to exploit the vulnerability and ping a remote host:

$%7Bscript:javascript:java.lang.Runtime.getRuntime().exec(%27ping%20-c%205%20172.17.0.1%27)%7D 

We can send the crafted payload mentioned above to achieve our goal.

We can see that we can successfully ping our host from the victim machine. The point to be noted is that we are not just limited to ping. Any OS query at this point is a valid payload. Any ill-intended attacker can open a reverse shell or execute any other commands available in the host.

As demonstrated below, we have an effective shell on the host.

Detecting Text4shell using Logpoint

Log sources needed

• Firewall
• Server running Apache Common Text library
  • Sysmon for Linux
  • Auditd
  • Apache server access logs
• Apache running in Windows
  • Native event logs
  • Sysmon

As the exploitation requires the use of any of those above-mentioned additional lookup methods, we can search for those function in the URLs to detect any exploitation attempt.

(url=* OR resource=*) 
| process eval("decoded_resource=urldecode(resource)") 
| process eval("decoded_url=urldecode(url)") 
| rename decoded_resource as resource, decoded_url as url 
| search ( resource IN ["*${script:*","*${url:*","*${dns:*","*script*java.lang.Runtime.getRuntime*"] 
OR url IN ["*${script:*","*${url:*","*${dns:*","*script:*:java.lang.Runtime.getRuntime*"])

Detecting post-compromise activity
Besides detecting exploitation attempts, it is also very crucial to detect post-compromise activity. We may miss out on detecting exploitation attempts due to various reasons so we must look out for traces of suspicious activities like spawning of shell, suspicious outbound connection to a remote hosts and other suspicious activities that can indicates compromise. We initially began to hunt for suspicious activities with an hypothesis of detecting initial system information discovery activities and suspicious process creation and command execution attempts.

After getting reverse shell or access to the system, adversaries may try to perform system information discovery activity which we can detect by using following query:

For Unix systems which use auditd for logging:

norm_id=Unix "process"=audit (event_type="EXECVE" argument_0 IN ["uname", "uptime"]) 
OR (event_type="PATH" path IN ["/sys/class/dmi/id/bios_version", "/sys/class/dmi/id/product_name", "/sys/class/dmi/id/chassis_vendor", "/proc/scsi/scsi", "/proc/ide/hd0/model", "/proc/version", "/etc/*version", "/etc/*release", "/etc/issue"])     

For Windows:

label="Process" label=Create ("process"="*\systeminfo.exe" OR command="*net config*") -user IN EXCLUDED_USERS   

We can also look for some suspicious process creation in Windows systems. There may be false positives which analyst must filter out depending on their environment.

label="Process" label=Create 
"process" IN ["*\whoami.exe", "*\systeminfo.exe", "*\ipconfig.exe", "*\cmd.exe", "*\powershell.exe", "*\wget.exe", "*\curl.exe", "*\nslookup.exe"] 
-command="cmd.exe /c set" 
| chart count() by host, parent_process, "process", command 

For Linux systems running sysmon, monitor for spawning of suspicious process:

norm_id=UnixSysmon label="Process" label=Create 
(user="confluence" OR path="*/Atlassian/Confluence/bin") 
image IN ["/usr/bin/uname", "/usr/bin/whoami", "/usr/bin/hostname", "/usr/bin/ip", "/usr/bin/id", "/usr/bin/wget", "/usr/bin/curl", "/usr/bin/ss", "/usr/sbin/iptables", "/usr/bin/bash", "/usr/bin/sh"] 
| chart count() by host, image, command 

Apply mitigations without delay

We advise administrators to assess and update their Apache common text to the latest version as soon as possible. Analysts should monitor for post-exploitation traces and look for any suspicious activities relating to any tactics which we didn’t fully cover above. Alerts to detect suspicious activities are already created by the Logpoint team so we advise analysts to use these alerts and continually look out for malicious activities. Actively looking out for indicators of compromise and testing out various hypotheses can help uncover zero-day vulnerabilities. Finally, by using Logpoint SOAR, an analyst can automate the process of monitoring, detecting, and mitigating the threat.

We will update the blog as the situation evolves.