A critical vulnerability was identified in XZ Utils, an open-source utility. This vulnerability allows attackers to execute arbitrary code with root privileges on affected Linux systems. EDRs face challenges in detecting such sophisticated attacks due to reliance on specific YARA rules and the absence of generic detection capabilities. The Virsec Security Platform leverages a default-deny, allow-on-trust principle to eliminate dwell time and provide protection from vulnerabilities like XZ Utils.
Background: On March 29th, 2024, NVD published a vulnerability, CVE-2024-3094, indicating that the open-source XZ Utils contains a backdoor that allows a threat actor to execute arbitrary code with root privileges within Linux systems. Given the criticality, NVD and GitHub assigned this vulnerability the highest score of 10.0. After the announcement, GitHub suspended the code repo for XZ Utils until further notice to minimize additional impact.
Exploitation history: CISA cautioned about this vulnerability without going as far as saying that threat actors were actively exploiting it. The European Forum of Incident Response and Security Team (FIRST) published the EPSS Score of 0.08%, indicating that the vulnerability is not being widely exploited.
Fortunately, XZ Utils is not bundled in most mainstream commercial Linux distributions like Red Hat. It is, however, bundled in a few Linux distributions such as Debian, Kali, OpenSUSE, Arch Linux, and Fedora.
How did threat actors use the XZ Utils vulnerability? The attack unfolded in an elaborately orchestrated scheme worthy of a whodunit. Over a three-year period, a threat actor going by the handles Jia Tan and Jigar Kumar ingratiated themselves into the open-source community. While Jigar Kumar disappeared early, Jia Tan eventually became the sole maintainer of the XZ Utils repository.
What Jia did was change the build process of the XZ Utils to inject a backdoor binary with an innocuous-sounding name, liblzma_la-crc64-fast.o, into the build of the main XZ Utils library called liblzma. This backdoor accepts user input, decrypts it, and converts it into code, which a threat actor can execute with root privileges on the target workload. As part of the build system manipulation, Jia also changed the RSA_public_decrypt symbol in the library liblzma to point to the code in the backdoor. As a result, when apps, such as the Secure Shell Daemon SSHD, use the impacted library and call the function RSA_public_decrypt baked into the library liblzma, the app could execute arbitrary remote code of the threat actor’s choosing with root privileges.
Supply Chain Manipulation: Sophisticated threat actors have realized that they could gain initial access to many victims in one stroke by embedding their malicious code into popular open-source libraries. Independent software vendors who don’t exercise enough caution (such as code reviews) while including such malicious open-source libraries into their own app’s code bases, unwittingly aid the threat actor in the propagation of the backdoor.
Unlike the log4j supply chain attack, the XZ Utils malware was not included in popular Linux distributions, which significantly reduced its propagation velocity.
How do EDRs cope with the XZ Util vulnerability/exploits?EDR vendors will typically use publicly available exploits to create various types of YARA rules or indicators of compromise, such as the following:
- The presence of specific log entries in potentially impacted applications
- The presence of specific files on specific directories on disk.
- The presence of specific “strings” in files on disk.
- The presence of particular web shells and their installers. These pieces of code are identified by specific strings in the code of such web shells.
- Connections to specific IP addresses
- Parent-child process relationships that are known to be malicious
Please note that the above are examples and not an exhaustive list.
Three significant shortcomings of how EDRs detect attacks emerged from the XZ Utils vulnerability saga are:
- Despite all the fanfare about leveraging AI/ML to detect attacks faster, EDRs ultimately fall back on detection using very specific YARA rules for specific attacks. These rules are not generic. The other side of this coin is that until the YARA rules for a given exploit are available, the typical EDR is blindsided.
- Given that the usual suspects of repositories for exploit code do not have any POC for this vulnerability, it has an EPSS Score of 0.08. Per the GitHub advisory, “If you’re running a publicly accessible SSHD, then you are - as a rule of thumb for those not wanting to read the rest here - likely vulnerable.” In other words, there are no YARA rules available for EDRs.
- This lack of context is why the above-referenced GitHub advisory also states, “at this stage, we got lucky, and there may well be other effects of the infected liblzma.” This helps explain why so much is being made off the German software developer Andres Freund, who is credited with discovering the backdoor simply because his machine consumed more CPU than it should have. A thorough investigation by Mr. Freund ultimately led to the discovery of the backdoor. Not everyone will be as determined as Mr. Freund. His painstaking approach is not a good strategy to protect an enterprise’s software infrastructure from insidious attacks.
How does the Virsec Security Platform (VSP) protect against XZ Utils vulnerability/exploits?
In the case of XZ Utils, the threat actor’s goal was to:
- Deliver a backdoor via an SSHD connection to the victim workload.
- Push arbitrary (potentially malicious) code through that backdoor to the victim workload.
- Execute the abovementioned arbitrary code on the victim workload.
Unlike EDRs, which operate on the “default allow, block on threats” principle, where threats are detected using YARA rules, the Virsec Security Platform (VSP) leverages the “default deny, allow on trust” principle.
When VSP is first installed, it verifies the provenance, integrity, and authorization (PIA) of all code present on the workload using the Virsec Trust Cloud. If PIA for any code cannot be established, that code is considered untrusted and will be denied execution. The direct implication of this operation for XZ Utils vulnerability is that VSP will refuse the execution of the malicious executable dropped in step (c) above. VSP will ensure zero dwell time for any malicious code.
Conclusion: The Virsec Security Platform (VSP) leverages the default-deny, allow-on-trust principle, which results in true Zero Trust and zero dwell time for malicious or unauthorized code.
Jump to: List of CVE Vulnerabilities
Don't miss our security insights, and subscribe to our blog now.
