Balbix Guide to XZ Utils Backdoor

Executive Summary

• On March 29, 2024, developer Andres Freund reported the discovery of a backdoor in XZ Utils, affecting v5.6.0 and 5.6.1.
• XZ Utils, which provides compression tools for the .xz format, is included in a wide range of Linux distributions and projects.
• Tracked by CVE-2024-3094, this backdoor gives a specific attacker Remote Code Execution capabilities through hijacked SSHD.
• Although it has CVSS 10, the backdoor was discovered in the early stages of distribution, posing a relatively minor impact.
• To mitigate the affected systems, organizations should downgrade/upgrade to an un-compromised release.

Affected Systems

XZ Utils is a collection of open-source command-line tools for lossless data compression, including XZ and LZMA. It is an upstream package for almost all Linux distributions. Without an early discovery, the open-source software supply chain would have distributed this backdoor to virtually all Linux systems embedding XZ, making it one of the most dangerous ever built.

In this particular case, where XZ Utils are exploiting SSHD, the backdoor needs a third-party patch that triggers OpenSSH to load LIBZMA through SYSTEMD. However, the exploitation mechanism is generic, so it can be reused against any other software that links LIBZMA, without modifications to the main code. So, even if the exploit only triggers on X64 and third-party patch presence, consider any system that’s embedding XZ Utils 5.6.0 or 5.6.1 as compromised.

The following list of Linux distributions have reportedly been affected/not affected by this vulnerability:

Luckily, Andres Freund discovered it early (by accident!) just a few days after it was released in the XZ repository and before it was widely distributed.

Risk = Likelihood x Impact

From a Likelihood perspective, CVE-2024-3094 has a very high severity on affected systems (CVSS of 10), as the attacker has Remote Code Execution capabilities. The backdoor is added to the SSH daemon so the attacker can remotely trigger any vulnerable system that exposes the commonly used SSH service to execute unauthorized code without needing any valid access level to the vulnerable system.

From an Impact perspective, the early discovery stage and low deployment footprint make it a relatively small-scale problem. The number of affected systems is small, and none are production, enterprise-grade versions.

Hence, our assessment using Risk = Likelihood x Impact is that it is a medium-risk vulnerability. 

Technical Details / TTPs

Andres Freund noticed a 500ms spike in latency during SSH login attempts on his test systems, which correlated to unexpectedly high CPU usage. He was curious to understand why. While initially reported as a bypass backdoor on SSH, the malicious code grants the attacker, who has a specific private key, Remote Code Execution capabilities on the affected Linux systems.

The XZ backdoor was implanted through a long and sophisticated cyber operation in the open-source software supply chain executed over two years by a threat actor known as Jia Tan, who slowly infiltrated the XZ development community and gained trust until given maintainer responsibilities. Tan employed elaborate social engineering tactics in this cyber operation, creating fake email accounts to send the original XZ maintainer numerous feature requests, bug reports, and performance complaints. This led to his being added as another maintainer to the repository to handle the increased level of work better. Although no specific attribution has been released, such long-term and complex cyber operations and TTPs are typically associated with nation-state threat actors.

The malicious code is quite complex and purposefully built to:

(1) Avoid Detection  > Instead of implanting the public repository backdoor, Jia Tan only included it in source code tarballs, starting with version 5.6.0. This way, the malicious parts of the backdoor remained hidden but were still being used during the build processes of all dependent projects. In addition, the malicious code was encoded and processed with innocent-looking command line tools, mimicking benign and regular file processing of the specially crafted test samples that were included.

(2) Check for Preconditions to Run  >  The malicious code remains inactive unless a specific third-party patch of the SSH server has been applied previously. In normal conditions, OpenSSH doesn’t use LIBZMA, but some Linux distributions add a patch to link SSHD to SYSTEMD, which links to LIBZMA, enabling XZ Utils to control SSHD. In addition, the malicious code only activates on x64 systems using GLIBC and GCC and is packaged in RPM and DPKG.

Through subsequent stages and relatively complex obfuscations (ranging from file carving, substitution ciphers, and even an RC4 variant written in AWK), the LIBZMA build process extracts the payload from disguised “test” files. This is used to modify the LIBZMA code, resulting in a corrupted LIBZMA library that can intercept and modify the data interacting with it when used by any linked software. Further, the corrupted library works as an exploit for the patched OpenSSH (which is now calling XZ Utils through SYSTEMD), replacing the existing OpenSSH function RSA_public_decrypt with its malicious clone. At this point, the corrupted OpenSSH becomes a backdoor that listens to RCE payloads from its new master.

An important point to note is that the changes made to the LIBZMA code are designed to be generic. This means that the same corrupted LIBZMA code can work as an exploit against any other files interacting with it, and the commands/instructions are hidden in the specially crafted test files. This potentially enables the attacker to add other test files to the XZ library and trigger LIBZMA to exploit other software components.

Since the entire process is quite complex and difficult to follow, here’s an infographic summarizing the steps that explain how it all works together:

Detection and Mitigation

Detection is straightforward and based on the software Inventory / SBOM.

Mitigation is done by downgrading to an un-compromised version.

Organizations are advised to take urgent action and check Inventory / SBOM for affected Operating Systems and XZ Utils, versions 5.6.0 and 5.6.1 

Balbix Solution

This is a perfect example of a vulnerability that can be easily detected. However, most enterprise organizations use dozens of security tools, each collecting their data and showing only a fraction of the overall inventory. In some cases, data conflicts between these tools. With Balbix, security teams can transform their siloed data into a deduplicated, comprehensive, and accurate asset inventory and answer questions such as “Which assets run XZ Util v5.6.0 and 5.6.1”.

Given the severity of the XZ Utils vulnerability, reaction time is paramount.

Incident Response teams need to have the tools to ask the following kinds of questions in real-time, across the entire estate, and be confident of the completeness of the answers:

1. 1. What are all assets with XZ Utils, versions 5.6.0 and 5.6.1.
   2. List all Kali Linux systems released between March 26 and March 28.
   3. List all external facing assets with an open SSH service in the USA.
   4. Do we have any critical assets running the SSH server based on Fedora 41.

Balbix can answer these questions in real-time and reduce the risk associated with CVE-2024-3094.

Conclusion

CVE-2024-3094 has startled the Linux community, raising serious concerns about the security of Linux distributions, open-source projects, and software supply chains. While we got lucky, this situation should trigger security teams to prepare for such incidents proactively. Sign up for a demo here to learn more about how Balbix can help.