Month: December 2022

A vulnerability in the Apache Commons Text library called Text4Shell was discovered in October 2022. This vulnerability exists in versions 1.5 through 1.9 of the popular Java library. It allows remote code execution and other malicious actions through the exploitation of the StringSubstitutor API. The vulnerability is identified as CVE-2022-42889 and has a CVSSv3 score of 9.8 out of 10. 

The Apache Commons Text library includes a mechanism for interpolating variables, allowing users to replace certain bits of text with another according to a template. The default template for this library is ${prefix:[options]:data}, where the prefix defines the algorithm for processing data from options.

In this blog post, we use Wazuh to detect vulnerable versions of Apache Commons Text Library and monitor the endpoints for attempts to exploit this vulnerability.

Exploitation conditions​ for Text4Shell

The following conditions must be met for Text4Shell to be exploitable:

• Apache Commons Text version 1.5 through 1.9 installed on the victim endpoint.
• The application using the vulnerable library must use org.apache.commons.text.StringSubstitutor and one of the following prefixes with the default configuration (dns, script, url). 
• The application must accept and process untrusted data input.

Exploitation examples

If an attacker has the ability to modify a template, he can carry out the following types of attacks:

Detection with Wazuh

Requirements

1. A pre-built ready-to-use Wazuh OVA 4.3.10 Follow this guide to download the virtual machine.

2. An Ubuntu 22.04 endpoint with a Wazuh agent installed and enrolled to the Wazuh server. A Wazuh agent can be installed by following the Deploying Wazuh agents guide.

Ubuntu 22.04 endpoint

In order to test the Text4shell vulnerability, we used the vulnerable application in this Proof of Concept.

1. Install OpenJDK and Maven:

$ sudo apt update && sudo apt install openjdk-11-jdk
$ cd /tmp
$ sudo wget https://mirrors.estointernet.in/apache/maven/maven-3/3.6.3/binaries/apache-maven-3.6.3-bin.tar.gz
$ sudo tar -xvf apache-maven-3.6.3-bin.tar.gz
$ sudo mv apache-maven-3.6.3 /opt/

2. Set the environment parameters for Maven:

$ M2_HOME='/opt/apache-maven-3.6.3'
$ PATH="$M2_HOME/bin:$PATH"
$ export PATH

3. Download and build the vulnerable application:

$ sudo apt install git
$ sudo git clone https://github.com/securekomodo/text4shell-poc.git
$ cd text4shell-poc
$ sudo ./mvnw clean install

This creates the ./target folder in the current working directory. Within that folder is the JAR file text4shell-poc-0.0.1-SNAPSHOT.jar

4. Deploy the vulnerable application and enable logging:

$ sudo java -jar -Dserver.tomcat.basedir=tomcat -Dserver.tomcat.accesslog.enabled=true ./target/text4shell-poc-0.0.1-SNAPSHOT.jar

5. In a new terminal, forward the application logs to the Wazuh server by editing the agent /var/ossec/etc/ossec.conf configuration file and specifying the path to the log file:

<localfile>
  <log_format>syslog</log_format>
  <location>/path/to/tomcat/access_log.x-x-x.log</location>
</localfile>

This file is under tomcat/logs in the current working directory for this use case.

Detecting vulnerable versions of Apache Commons Text library with Wazuh SCA

The Wazuh SCA module performs scans to discover misconfigurations in monitored endpoints. Policy files are written in YAML and contain rules to be tested against the actual configuration of the endpoint.

Ubuntu endpoint

1. Create a directory on the endpoint to hold local SCA policies:

$ sudo mkdir /home/local_sca_policies/

The custom SCA policies in the Wazuh default ruleset folders are not kept across updates. This is why we create the /home/local_sca_policies/ directory outside the Wazuh agent installation folder.

2. Create the text4shell_policy.yml file in the local SCA policy directory on the endpoint:

$ sudo touch /home/local_sca_policies/text4shell_policy.yml

3. Change the owner and group of the policy file to wazuh:wazuh so that it can be used by the Wazuh user:

$ sudo chown wazuh:wazuh /home/local_sca_policies/text4shell_policy.yml

4. Enable the policy in the Wazuh agent configuration file /var/ossec/etc/ossec.conf by specifying the location of the policy file in the <SCA> block:

<policies>
   <policy>/home/local_sca_policies/text4shell_policy.yml</policy>
</policies>

5. Add the following content in your /home/local_sca_policies/text4shell_policy.yml policy file:

policy:
 id: "text4shell_check"
 file: "text4shell_check.yml"
 name: "Text4Shell dependency check"
 description: "This document provides prescriptive guidance for identifying Text4shell vulnerability"
 references:
   - https://nvd.nist.gov/vuln/detail/CVE-2022-42889
   - https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-42889
requirements:
 title: "Check if Java is present on the machine"
 description: "Requirements for running the SCA scan against machines with Java on them."
 condition: none
 Rules:
   - 'c:sh -c "java -version" -> r: not found'
checks:
 - id: 10000
   title: "Ensure Apache Commons Text earlier than v1.10 is not on the system"
   description: "The Apache Commons Text library is vulnerable to RCE on versions between 1.5 to 1.9."
   remediation: "Update the Apache Commons Text library to version 1.10."
   condition: none
   rules:
     - 'c:find / -regex ".*commons-text.*.jar" -type f -exec sh -c "unzip -p {} META-INF/MANIFEST.MF | grep Implementation-Version" ; -> r: 1.5| 1.6| 1.7| 1.8| 1.9'

The check 10000 searches for vulnerable versions of  Apache Commons Text library on the endpoint. This SCA check will fail if a vulnerable version is found.

6. Restart the Wazuh agent to apply the changes:

$ sudo systemctl restart wazuh-agent

Detection results

We can confirm from the SCA dashboard that the endpoint currently has a vulnerable version of the Apache Commons Text Library installed.

Detecting Apache Text4Shell exploitation attempts

In order to detect the exploitation of this vulnerability, we write a rule that can match different exploit strings encoded in web requests.

Wazuh server

1. Edit the /var/ossec/etc/rules/local_rules.xml file and add the following custom rules: 

<group name="accesslog,text4shell,">

<!-- This rule matches arbitrary controlled input for exploitation using script, dns or url prefixes -->

  <rule id="100002" level="12">
     <if_sid>31100</if_sid>
     <url type="pcre2">%24%7B(script%3A(javascript|JEXL)%3A|url%3AUTF-8%3A|dns%3A(address|canonical-name|name)%7C)</url>
     <description>Possible Text4Shell (CVE-2022-42889) exploitation attempt detected from $(srcip)</description>
     <mitre>
      <id>T1190</id>
      <id>T1203</id>
     <id>T1210</id>
   </mitre>
  </rule>

</group>

2. Restart the Wazuh manager to apply the changes:

# systemctl restart wazuh-manager

Attack Emulation

To test the detection, send the following web requests to the vulnerable application from any device that has network connectivity with the endpoint:

1. Using the script prefix:

$ curl http://<UBUNTU_IP>:8080/reflected?poc=%24%7Bscript%3Ajavascript%3Ajava.lang.Runtime.getRuntime%28%29.exec%28%27touch%20%2Ftmp%2Ffoo%27%29%7D

This request allows the supplied JavaScript code to be executed. This example creates a file named foo in the /tmp directory of the monitored endpoint.

2. Using the DNS prefix:

$ curl http://<UBUNTU_IP>:8080/reflected?poc=%24%7Bdns%3Aaddress%7Cwww.google.com%7D

This request performs a DNS query, or a reverse lookup to identify internal resources. 

3. Using the URL prefix:

$ curl http://<UBUNTU_IP>:8080/reflected?poc=%24%7Burl%3AUTF-8%3Ahttps%3A%2F%2Fnvd.nist.gov%2Fvuln%2Fdetail%2FCVE-2022-42889%7D

This lookup calls the specified URL to perform basic GET requests to internal resources.

Replace <UBUNTU_IP> with the IP address of the monitored endpoint running the vulnerable application.

Detection results

Mitigations

Apache has released a patch for this vulnerability. Upgrading the Apache Commons Text Library version to 1.10 mitigates the vulnerability. Additionally, check the usage of org.apache.commons.text.StringSubstitutor closely across your codebase and ensure untrusted user input isn’t being passed to vulnerable functions.

Conclusion

In this article, we demonstrate how to detect Text4shell vulnerability by monitoring an endpoint for vulnerable versions of Apache Commons Text Library. To achieve this, we used the Wazuh SCA module and wrote custom rules to detect exploitation attempts on the monitored endpoint.

Wazuh is open source and free to use. It also has a fast-growing community. You can deploy Wazuh on-premises or as a cloud solution using the Wazuh cloud.

References

• CVE-2022-42889
• Text4Shell: A Vulnerability in Java library Apache Commons Text (CVE-2022-42889, Act4Shell)
• Dangerous hole in Apache Commons Text – like Log4Shell all over again
• Threat Advisory: Monitoring CVE-2022-42889 “Text4Shell” Exploit Attempts

The post Detecting Apache Text4Shell (CVE-2022-42889) with Wazuh appeared first on Wazuh.

STRRAT is a Java-based remote access trojan (RAT) that provides threat actors with full remote control of infected Windows endpoints. STRRAT focuses on stealing credentials from browsers and email clients like Microsoft Edge, Google Chrome, Mozilla Firefox, Microsoft Outlook, Mozilla Thunderbird, and Foxmail. It also steals credentials by recording keystrokes of infected endpoints.

Previous versions of STRRAT relied on Java Runtime Environment (JRE) installed on infected endpoints. Recently, this trojan has acquired the ability to deploy its own JRE on infected endpoints.

STRRAT is usually delivered by phishing emails, and it allows attackers to run a plethora of commands on infected endpoints.

In this blog post, we use Wazuh to detect the malicious activities of STRRAT.

STRRAT behavior

• STRRAT poses as ransomware by adding a .crimson extension to the files on the victim endpoint, although it does not encrypt the files.
• STRRAT collects basic information like system architecture, the presence of antivirus software, and the operating system of the victim endpoint.
• STRRAT creates a <digits>lock.file file in the C:Users<USER_NAME> folder. The <digits> represents the port used by the trojan to connect to its command and control (C2) server.
• STRRAT downloads a system-hook Jar file and uses this file to record the keystrokes of the victim endpoint. This Jar file is located in the C:Users<USER_NAME>lib folder.
• STRRAT downloads sqlite-jdbc and jna-platform Jar files into the C:Users<USER_NAME>lib folder. The trojan uses these files to perform malicious activities on the victim endpoint.
• STRRAT maintains persistence by using the task scheduler to create a Windows scheduled task called Skype. This scheduled task runs the malware every 30 minutes.
• STRRAT attempts to connect to a C2 server to exfiltrate data. It creates a C:Users<USER_NAME>AppDataRoamingstrlogs folder before attempting to connect to its C2 server.

Infrastructure

To demonstrate the detection of STRRAT with Wazuh, we use the following infrastructure:

1. A pre-built ready-to-use Wazuh OVA 4.3.10. Follow this guide to download the virtual machine. 

2. A Windows 10 victim endpoint with Java and Wazuh agent 4.3.10 installed. To install the Wazuh agent, refer to the following guide.

Detection with Wazuh

STRRAT is delivered in stages and uses obfuscation to evade detection on a victim endpoint. In this blog post, we use the following techniques to detect the presence of STRRAT:

• File integrity monitoring: To detect files created, modified, and downloaded by STRRAT.
• Command monitoring: To detect a scheduled task created by STRRAT.

File integrity monitoring

Wazuh uses its File Integrity Monitoring (FIM) module to detect and trigger alerts when files are created, modified, or deleted on monitored folders.

Follow the steps below to detect the presence of STRRAT on the victim endpoint.

Victim endpoint

Perform the following steps to configure FIM on the monitored endpoint.

1. Edit the Wazuh agent C:Program Files (x86)ossec-agentossec.conf file and include the following configuration within the <syscheck> block:

<!-- This configuration monitors the malicious activities of STRRAT on the victim endpoint-->
<directories realtime="yes" recursion_level="2">C:Users</directories>

2. Launch Powershell with administrative privilege and restart the Wazuh agent for the changes to take effect:

> Restart-Service -Name wazuh

Wazuh server

Perform the following steps to configure detection rules on the Wazuh server.

1. Edit the /var/ossec/etc/rules/local_rules.xml file on the Wazuh server and include the following rules:

<group name="syscheck,strrat_detection_rule,">
<!-- STRRAT downloads a system-hook Java file for recording keystrokes -->
  <rule id="100050" level="12">
    <if_sid>554</if_sid>
    <field name="file" type="pcre2">(?i)^c:\users.+lib\system-hook.+jar$</field>
    <description>Possible STRRAT malware detected. $(file) was downloaded on the endpoint</description>
    <mitre>
      <id>T1056.001</id>
    </mitre>
  </rule>
<!-- STRRAT poses as ransomware -->
  <rule id="100051" level="8">
    <if_sid>550,554</if_sid>
    <field name="file" type="pcre2">(?i)c:\users.+(documents|desktop|downloads).+crimson</field>
    <description>Possible STRRAT malware detected. The .crimson extension has been appended to $(file)</description>
    <mitre>
      <id>T1486</id>
    </mitre>
  </rule>
<!-- STRRAT creates a lock file -->
  <rule id="100052" level="12">
    <if_sid>554</if_sid>
    <field name="file" type="pcre2">(?i)^c:\users.+\d{1,}lock.file$</field>
    <description>Possible STRRAT malware detected. $(file) was created on the endpoint</description>
  </rule>
<!-- STRRAT downloads Java files -->
  <rule id="100053" level="12">
    <if_sid>554</if_sid>
    <field name="file" type="pcre2">(?i)^c:\users.+lib\(jna-platform|sqlite).+jar$</field>
    <description>Possible STRRAT malware detected. $(file) was downloaded on the endpoint</description>
    <mitre>
      <id>T1407</id>
    </mitre>
  </rule>
</group>

Where:

• Rule id 100050 is triggered when the STRRAT malware downloads a system-hook jar file.
• Rule id 100051 is triggered when .crimson extension is appended to files in Documents, Desktop or Downloads folder.
• Rule id 100052 is triggered when STRRAT creates a <digits>lock.file file in C:Users<USER_NAME> folder.
• Rule id 100053 is triggered when STRRAT downloads a jna-platform or sqlite-jdbc jar file.

2. Restart the Wazuh manager for the changes to take effect:

# systemctl restart wazuh-manager

The alerts below are generated on the Wazuh dashboard when STRRAT is run on the victim endpoint.

Command monitoring

Wazuh has a command monitoring module to run commands and monitor the output of these commands on monitored endpoints. We use the command monitoring module to detect a Windows-scheduled task called Skype, created by STRRAT.

Victim endpoint

Perform the steps below to configure the Wazuh agent to monitor the scheduled task created by STRRAT on the victim endpoint.

1. Edit the C:Program Files (x86)ossec-agentossec.conf file and include the following configuration within the <ossec_config> block:

<localfile>
  <log_format>full_command</log_format>
  <command>schtasks /query /nh | findstr /c:"Skype"</command>
  <alias>finding_skype</alias>
  <frequency>300</frequency>
</localfile>

2. Launch Powershell with administrative privilege and restart the Wazuh agent for the changes to take effect:

> Restart-Service -Name wazuh

Wazuh server

Perform the steps below to configure the Wazuh server to detect the scheduled task created by STRRAT on the victim endpoint.

1. Edit the /var/ossec/etc/rules/local_rules.xml file on the Wazuh server and include the following rules:

<group name="syscheck,strrat_detection_rule,">
<!-- STRRAT creates a scheduled task called Skype -->
  <rule id="100054" level="0">
    <if_sid>530</if_sid>
    <match>^ossec: output: 'finding_skype'</match>
    <description>A scheduled task called Skype is created</description>
  </rule>
<!-- STRRAT maintains persistence -->
  <rule id="100055" level="12" ignore="720">
    <if_sid>100054</if_sid>
    <match type="pcre2">(?i)Skype.+running</match>
    <description>Possible STRRAT malware detected. Malware has achieved persistence</description>
    <mitre>
      <id>T1547.001</id>
    </mitre>
  </rule>
</group>

Where:

• Rule id 100054 is triggered when a scheduled task named Skype is created.
• Rule id 100055 is triggered when a scheduled task named Skype is in a running state.

2. Restart the Wazuh manager for the changes to take effect:

# systemctl restart wazuh-manager

The alert below is generated on the Wazuh dashboard when STRRAT malware is run on the victim endpoint.

Conclusion

In this blog post, we have successfully used Wazuh to detect the behavior of STRRAT malware. Specifically, we used file integrity monitoring and command monitoring techniques to detect STRRAT malware on a Windows 10 endpoint.

Wazuh is a free and open source enterprise-ready security solution for threat detection and response. Wazuh integrates seamlessly with third-party solutions and technologies. Wazuh also has an ever growing community where users are supported. To learn more about Wazuh, please check out our documentation and blog posts.

References 

1. Threat Thursday: STRRat Malware

2. New STRRAT RAT Phishing Campaign

The post STRRAT detection with Wazuh appeared first on Wazuh.