From Log4Shell to Text4Shell…

by mrahier96

Share

From Log4Shell to Text4Shell…

by mrahier96

by mrahier96

Context of the Log4Shell Vulnerability to Text4Shell

A year ago, the infamous “Log4Shell” vulnerability on the Log4J logging library of the Apache Logging Services was disclosed. This “Remote Code Execution” (RCE) vulnerability was widely publicized, as the component was widely used and exploiting of the vulnerability was easy. Indeed, Log4Shell was more than just an RCE vulnerability. Depending on the way it was exploited, it could also be used for data exfiltration via protocols such as DNS.

As a result, some sort of “cyber-crisis” arose when companies tried to fix the problem with patches that did not work properly or only prevented one way of exploiting the problem. Some patches were published by the library developers, but a few of them remained vulnerable via various means.

This event caused a kind of “gold rush” for security researchers from different backgrounds. At this point, the objective was to find a similar vulnerability in widely used components. This led to the discovery of the “Spring4Shell” vulnerability inside the Java’s Spring framework.

Most recently a new vulnerability was discovered in another component of the Apache ecosystem, the CVE-2022-42889 or “Text4Shell”.

The vulnerability

This vulnerability was found inside the “Apache Commons Text” which is used for string manipulations.

The vulnerability affects the versions 1.5 through 1.9 of the components. The Apache security blog post and the GitHub advisory report the affected methods to be “StringSubstitutor.replace()” and “StringSubstitutor.replaceIn()” which are part of the “org.apache.commons.text.StringSubstitutor” class.

The issue is that a default interpolator used for handling legitimate strings allows some dangerous string lookups. This can lead to Remote Code Execution. The “StringLookupFactory” class interpolates by default the search keys “script”, “dns” and “url” lookups keys by default which have respectively the following behavior:

  • script: execute a script on the target inside the Java Virtual Machine.
  • dns: perform a DNS resolution based on the provided variable.
  • url: perform an http request on the provided URL.

A simple example of a string that can be used to exploit the vulnerability is the following:

${script:javascript:java.lang.Run.Runtime.getRuntime().exec(“cat /etc/passwd”);}

This string uses the « script » lookup and the JavaScript scripting language to get a reference on the Runtime object from the Java runtime and make it execute a shell command to get the content of the common Linux file “/etc/passwd”.

The solution

The Apache security team mentions in the blog post that the component has been updated to change the configuration to a more “secure by default” one. This means that by default, the mentioned lookups will not be interpolated.

Nevertheless, the Apache security team recommends as a good practice “that users treat untrusted input with care”. More specifically, it is recommended to check the user’s inputs to make sure that no dangerous inputs is provided before using the “replace” and “replaceIn” methods.

It is important to note that no exploitation of this vulnerability has been observed in the wild.

Why wasn’t this issue discovered before?

It’s a legitimate question because the vulnerability was disclosed in October 2022 and the release date for Apache Commons Text the 29th of August 2018.

It’s a legitimate question because the vulnerability was disclosed in October 2022 and the release date for Apache Commons Text the 29th of August 2018.

  • Apache Commons Text is far less used than Log4J, for example, which means it receives less attention from security researchers. For example, at the moment of the writing, GitHub reports more than 2 millions projects using Log4J against only around a thousand for Apache Commons Text.
  • The documentation for the “StringLookupFactory” class reports that the default behavior for the three mentioned lookup keys is to be ignored. Which is the opposite of the real behavior of the class.

Conclusion

As seen, the kind of vulnerability “popularized” with Log4Shell on the java language is still an issue and new discoveries are made weekly if not daily. This is why a good dependencies management is one of the firsts and most important step in securing an application whether it is web based or not.

More content about the vulnerability:

 

Author

Alexis Pain

Do you have any questions ? Would you like to know more about vulnerabilities? Contact our experts !

Top