While the initial reporting and concern around Text4Shell (CVE-2022-42889) may have been overblown, the vulnerability is still drawing significant interest from defenders as attackers continue to blindly attempt to infect hosts that may be vulnerable. Thankfully unlike Log4j, the Apache Commons Text library does not have that same common large-scale default usages and configurations that allowed Log4Shell to become such a significant problem.
This blessing is also a curse for Purple Teams, however, because it makes defending against and validating your security controls much more difficult because it requires advanced knowledge of your unique implementations. Leveraging open-source scanners and publicly available detection signatures may be giving off a false sense of security because your web application may not be using the library in the same manner used in those tools.
The Apache Commons Text library is a set of useful methods that make it easier to work with strings beyond what is available in the standard Java core. Text4Shell is exploited by abusing a vulnerable interpolator that provides string substitution functionality where placeholder values can be replaced with dynamically generated values. There are three vulnerable interpolators that can allow for the execution of code or the access of remote resources.
When and where those interpolators get used is up to each individual application developer as there isn’t a universal standard field that could be monitored or tested to see if you are vulnerable. Some implementations might use those libraries to parse search queries, other implementations might deal with form inputs or API requests involving only a handful of specific fields.
In order to properly protect yourself against Text4Shell, the only true solution is to have an accurate software inventory and patch the vulnerable systems. If that isn’t possible, then a deeper understanding of how the library is used in your code and all the possible avenues that it could receive malicious input. Your detection and prevention signatures will need to be written with consideration to your specific implementation.
In order to validate those security controls, you need to be able to leverage capabilities that can custom-fit your particular application. Today we are going to show how customers can customize one of our existing scenarios to properly test this vulnerability against their own web applications. This applies to not just Text4Shell but whatever the next major library vulnerability might be.
To get started, our first step is to create a new assessment and add the factory scenario Web Request Communication to the assessment.
This scenario is our basic building block for making HTTP requests to a web server. All of the parameters of the request can be customized including the HTTP method, the URI path and query values, HTTP headers, and any additional POST data.
Validation of any security controls has many options and can be configured to be determined based on if the request receives a return response, a specific HTTP status code, or by searching for specific content in the response data. Some Web Application Firewalls might just drop the packets while others might return error codes or security banners.
In our lab environment we have deployed two servers running vulnerable proof-of-concept web applications. One of the servers has Suricata running in-line to prevent malicious activity while the other does not.
For this example will configure the scenario to trigger a Suricata rule released by ProofPoint in their Emerging Threats open ruleset that detects when the dns interpolator is triggered by passing a malicious crafted string in the URI field.
alert http $EXTERNAL_NET any -> [$HOME_NET,$HTTP_SERVERS] any (msg:"ET EXPLOIT Possible Apache Text4shell RCE Attempt DNS Prefix (CVE-2022-42889) (Inbound)"; flow:established,to_server; http.uri; content:"|3d 24 7b|dns|3a|address|7c|"; fast_pattern; content:"|7d|"; distance:0; reference:cve,2022-42889; reference:url,sysdig.com/blog/cve-2022-42889-text4shell; classtype:attempted-admin; sid:2039466; rev:2; metadata:affected_product Apache_HTTP_server, attack_target Web_Server, created_at 2022_10_19, cve CVE_2022_42889, deployment Perimeter, deployment SSLDecrypt, former_category EXPLOIT, confidence Medium, signature_severity Major, updated_at 2022_10_24;)
This rule is looking for inbound traffic to our webserver that contains “=${dns:address|” in one of the query values passed along in the URI. The actor’s hope is that the Apache Commons Text library will be used to process that value and trigger the vulnerable dns interpolator.
Our vulnerable web applications utilize a path named message that will reference the data from a query variable named text that will be processed by the Apache library and displayed back to the user.
To trigger the vulnerability and the Suricata signature we will try to force the vulnerable system to perform a DNS lookup of AttackIQ’s infrastructure. We need to pass “${dns:address|attackiq.com}” into the text field. Additionally, the value will need to be URL encoded resulting in a final URL of:
http://<server name>/message?text=%24%7Bdns%3Aaddress%7Cattackiq%2Ecom%7D
The scenario can be configured with the following settings to match the URL:
- Domain:
<server name> - Path:
/message - Method:
GET - Querystring:
text=%24%7Bdns%3Aaddress%7Cattackiq%2Ecom%7D
In our demo environment we have Suricata running in-line and dropping any packets that match that signature. For validation that our security controls are working, we are going to choose the settings that say the Attack is Prevented if the resource is unavailable or if the requests timeout.
The final settings are:
In this assessment I’ve created a duplicate of that scenario but changed the Domain field to point to the unprotected server. This will allow us to see that when we execute the assessment there are two different Prevention results. The green Prevented is from a test against our web server that used Suricata to drop malicious packets while the red Not Prevented was against a server that was vulnerable and didn’t have any security controls.
The activity details for that scenario show that the request was unsuccessful because the timeout period was reached.
While the unprotected web application shows a successful connection and retrieval of the webpage.
When testing against your own web applications, it is vital that you understand how your application leverages the Apache Common Text library. The applies to not just the test you will create in the AttackIQ platform but the configuration of security controls protecting your environment. There is not a one-size fits all test or security control you can put in place that will protect you from this vulnerability.
Relying on vendor and open-source signatures will not fully protect your environment. For example, the Emerging Threat rules referenced at the beginning only look at the URI values for the generically known patterns. As mentioned before, if your application utilizes a web form, that data is delivered in an HTTP POST body and wouldn’t be picked up by those specific Suricata rules. You would need to create your own specific signatures and then configure this scenario use the same fields to match your implementation.
By having a thorough understanding of your attack surface, customers can successfully leverage AttackIQ’s customizable scenarios to build bespoke security validation tests that are specific to your environment. This applies to not just Text4Shell but any future similar vulnerability that exploits libraries that don’t have default usages and configurations.
