Navigating the Waters of Vulnerability CVE-2024-3094 A Comprehensive Guide for Linux and Application Security

A recent discovery from Microsoft of an obfuscated and malicious action for a library liblzma and xz package led to Vulnerability CVE-2024-3094, which has sent shockwaves through the security and Linux community, underscoring the critical importance of SBOM, Application security and ASPM. This blog post delves deep into the intricacies of CVE-2024-3094, offering insights and strategies to downgrade the library and determine which Linux distro is affected by such vulnerabilities, with a focus on application security and proactive measures.

Understanding CVE-2024-3094 in the Linux Ecosystem

CVE-2024-3094 isn’t just another vulnerability; it’s a glaring beacon highlighting the ever-present risks in the Linux ecosystem. Discovered within the XZ Utils compression utilities—a cornerstone in most Linux distributions—this vulnerability could potentially allow malicious actors to bypass sshd authentication, gaining unauthorized system access remotely. The implications for Linux application security cannot be overstated, making it imperative for cybersecurity professionals to grasp the mechanics and consequences of CVE-2024-3094.

The Genesis of CVE-2024-3094: A Closer Look

The vulnerability was unearthed by a vigilant PostgreSQL developer, who noticed anomalous behaviour related to liblzma, part of the xz package, on Debian sid installations. This anomaly led to the revelation that specific versions of the xz libraries were embedded with malicious code, making CVE-2024-3094 a critical concern for Linux application security.

The Role of Application Security Management (ASPM) in Mitigating Risks

Application Security Management (ASPM) plays a pivotal role in safeguarding against vulnerabilities like CVE-2024-3094. ASPM encompasses strategies and practices designed to identify, assess, and mitigate security risks throughout the application lifecycle. In the context of CVE-2024-3094, ASPM involves rigorous security auditing, timely patch management, and continuous monitoring to detect and respond to threats promptly.

Proactive Measures Against CVE-2024-3094

How to discover/ fix CVE-2024-3094

liblzma, part of the xz package, are the vulnerable point, details below on how to fix and identify the vulnerable version

• Immediate Patch Application: Ensure that any Linux distribution using the affected xz library versions is updated immediately. Prioritize patches for critical environments.
• Enhanced Monitoring: Implement advanced monitoring solutions to detect unusual activity that could indicate exploitation attempts of CVE-2024-3094.
• Security Audits: Conduct comprehensive security audits of Linux environments to identify and remediate potential vulnerabilities ASPM and Phoenix security are an effective way to audit
• Campaign to upgrade / identify  – ensure tha the base version of linux / container/ ami  are updated 
• ASPM Best Practices: Leverage ASPM tools and methodologies to strengthen application security postures, minimizing the risk of future vulnerabilities.

Debian Simple detection script: https://github.com/Security-Phoenix-demo/CVE-2024-3094-fix-exploits/blob/main/debian-xz-liblzma.sh

Simple detection script (Linux): https://github.com/Security-Phoenix-demo/CVE-2024-3094-fix-exploits/blob/main/detect_liblza-quick.sh

Other Detection scripts: https://github.com/Security-Phoenix-demo/CVE-2024-3094-fix-exploits/blob/main/find_liblzma.sh

Sample of exploit: https://github.com/Security-Phoenix-demo/CVE-2024-3094_exploit_xzbot

Note this exploit requires editing the key

The exploit repository also contain a honeynet

Run this script to identify if the version you running is vulnerable :

Simple detection script: 


vim findxv.sh

Paste Below Code and save and quit

#! /bin/bash

set -eu

# find path to liblzma used by sshd

path="$(ldd $(which sshd) | grep liblzma | grep -o '/[^ ]*')"

# does it even exist?

if [ "$path" == "" ]

then

echo probably not vulnerable

exit

fi

# check for function signature

if hexdump -ve '1/1 "%.2x"' "$path" | grep -q f30f1efa554889f54c89ce5389fb81e7000000804883ec28488954241848894c2410

then

echo probably vulnerable

else

echo probably not vulnerable

fi

chmod +x findxv.sh

./findxv.sh

Optional Cleanup: rm findxv.sh

The shell script is taken from here: here at the bottom.

(reference from https://www.latio.tech/posts/CVE-2024-3094) 

Which Linux version are affected by CVE-2024-3094?

• Red Hat (🟢 stable not vulnerable): Red Hat Update
• Debian (🟢 stable not vulnerable): Debian Update
• Suse (🟢 stable not vulnerable): Suse Update
• Kali (🟡 Impacted but exploit not confirmed): Kali Linux Update
• Arch (🟡 Impacted but exploit not confirmed): Arch Linux Update. Debateable if exploited: Arch Discussion
• Homebrew (🟡 Impacted but probably not exploitable): Homebrew Update
• FreeBSD (🟢 Not impacted): FreeBSD Update
• Amazon Linux (🟢 not impacted): Amazon Linux Update

For those looking to delve deeper into their vulnerability status or seeking a more beginner-friendly guide on the matter, check out this summary article: Understanding Your Vulnerability Status.

Also, for a community-driven perspective, don’t miss the discussions over on HackerNews: HackerNews Comments.

Comprehensive Update on Linux Distributions Affected by CVE-2024-3094

the latest update on the affected version

Additional Distributions’ Status Based on Recent Updates:

• Red Hat (🟢 stable not vulnerable): Red Hat Update
• Debian (🟢 stable not vulnerable, aside from testing/unstable versions as noted above): Debian Update
• Suse (🟢 stable not vulnerable, with fixes released for openSUSE): Suse Update
• Kali (🟡 Impacted but exploit not confirmed, with a specific advisory for updates between March 26th and March 29th): Kali Linux Update
• Arch (🟡 Impacted but exploit not confirmed, with the ongoing debate about exploitation): Arch Linux Update and Debate
• Homebrew (🟡 Impacted but probably not exploitable): Homebrew Update
• FreeBSD (🟢 Not impacted): FreeBSD Update
• Amazon Linux (🟢 Not impacted): Amazon Linux Update

For users seeking a more beginner-friendly explanation or checking their vulnerability status, refer to this summary article: Understanding Your Vulnerability Status.

Community discussions, such as those on HackerNews, offer additional insights: HackerNews Comments.

Understanding the Scope and Defense Against CVE-2024-3094

The discovery of CVE-2024-3094 has prompted in-depth analyses across the cybersecurity industry, revealing specific prerequisites for a system to be susceptible to this sophisticated attack.

Note that this vulnerability is not the first instance of malicious attackers targeting open source vulnerabilities check the related blog on previous ivanti vulnerability

Prerequisites for CVE-2024-3094 Vulnerability

• Recent Version of liblzma (5.6.0+): The attack targets recent versions of liblzma. A safer version 5.4.6 vs the compromised versions (5.6.0 and 5.6.1) from their distribution.
• Build Environment Specificity: The malware specifically targets liblzma built on Debian/RPM based x86_64 distributions. 
• OpenSSH Linking to liblzma: A crucial component of the attack involves OpenSSH configurations that link to liblzma. 

Looking Ahead: Vigilance and Community Responsibility

The insertion of malicious code into the xz project by a core contributor, among numerous other changes, indicates a long-term strategy by the attacker. This incident is expected to cast a spotlight on the xz project, potentially leading to further discoveries. Chainguard pledges to remain at the forefront of monitoring developments and safeguarding their users against emerging threats.

Deeper analysis CVE-2024-3094

https://www.openwall.com/lists/oss-security/2024/03/29/4

The CVE-2024-3094 vulnerability involves a sophisticated backdoor mechanism targeting the xz-utils, specifically versions 5.6.0 and 5.6.1. This backdoor is not present in the source code found in the Git repository but is introduced in the distributed tarballs, complicating detection and understanding.

Compromised Release Tarball

The malicious script is injected into the build process through a line in the build-to-host.m4 file, which is not found in the upstream source but only in the tarballs for versions 5.6.0 and 5.6.1. This script, executed at the end of the configure process, is heavily obfuscated and utilizes data from “test” .xz files present in the repository.

It modifies the Makefile for liblzma within the build directory to execute another obfuscated script, cleverly disguised to avoid immediate detection. This secondary script, when de-obfuscated, reveals complex commands intended to execute malicious actions on the system.

Compromised Repository

The bulk of the exploit code resides in obfuscated files within the repository, specifically bad-3-corrupt_lzma2.xz and good-large_compressed.lzma, which were added to the repository via a commit. These files, when combined with the modifications made by the initial malicious script, activate the backdoor.

Emphasizing the Role of SBOM in Tackling CVE-2024-3094

In light of vulnerabilities such as CVE-2024-3094, the importance of a Software Bill of Materials (SBOM) in Linux and application security cannot be overstated. An SBOM provides a comprehensive inventory of all components, libraries, and software packages used within an application or system. This detailed enumeration is crucial for identifying potential vulnerabilities, managing risks, and ensuring compliance with security standards.

The Need for Precise Version Declaration in Every Distribution

One of the critical lessons underscored by the CVE-2024-3094 vulnerability is the need for explicit version declaration in every software distribution. Vulnerabilities often affect specific versions of software components; hence, knowing the exact versions included in any distribution is imperative for rapid vulnerability assessment and response.

Implementing SBOM for Enhanced Security Posture

• Improved Vulnerability Management: With a detailed SBOM, organizations can quickly determine if they are affected by CVE-2024-3094 or similar vulnerabilities, facilitating swift mitigation actions such as patching or configuration changes.
• Compliance and Risk Assessment: An SBOM helps organizations comply with regulatory requirements and conduct thorough risk assessments by providing visibility into the software supply chain.
• Enhanced Transparency and Trust: By maintaining an up-to-date SBOM, developers and users alike can gain a better understanding of the software’s composition, enhancing trust and transparency within the open-source community.

Conclusion: CVE-2024-3094 as a Call to Action

The vulnerability in liblzma, part of the xz package, CVE-2024-3094 serves as a warning of the continuous battle to maintain secure Linux environments. It emphasizes the importance of application security management (ASPM) in identifying, preventing, and responding to vulnerabilities. As cybersecurity professionals, our response to such threats through diligent application security practices will define the resilience of our digital landscapes.

In the quest for a secure digital world, vigilance is our greatest ally. Let CVE-2024-3094 be a reminder that in the domain of cybersecurity, complacency is the enemy, and proactive application security is our shield.

The Path Forward with SBOM

The creation, maintenance, and sharing of SBOMs should be regarded as a best practice within the Linux and application security communities. Tools and standards like SPDX (Software Package Data Exchange) and CycloneDX are becoming increasingly popular for generating and managing SBOMs, offering a pathway to more secure software development and deployment practices.

Collaboration and Reporting: Strengthening the Linux and Application Security Community

The discovery and response to CVE-2024-3094 highlight the strength of collaboration within the cybersecurity community and the software supply chain, strengthening the collaboration between vendors and organizations. 

How Phoenix Security Can Help identify and fix liblzma, part of the xz package, CVE-2024-3094

Phoenix Security helps organizations identify and trace which systems have vulnerabilities, understanding the relation between code and cloud. One of the significant challenges in securing applications is knowing where and how library like liblzma are used.

ASPM tools can scan the application portfolio to identify instances of vulnerable Linux and which version is exploitable, mapping out where it is deployed across the organization. This information is crucial for targeted security measures and efficient patch management. Phoenix Security’s robust Application Security Posture Management (ASPM) system is adept at not just managing, but preempting the exploitation of vulnerabilities through its automated identification system. This system prioritises critical vulnerabilities, ensuring that teams can address the most pressing threats first, optimising resource allocation and remediation efforts.

liblzma and xz package campaign example: Phoenix allows to address the CVE-2024-3094 liblzma as a campaign

The Role of Application Security Posture Management (ASPM):

ASPM plays a vital role in managing and securing applications like those built liblzma. It involves continuous assessment, monitoring, and improvement of the security posture of applications. ASPM tools can:

1. Identify and Track Vulnerable Versions/ Components: Locate where liblzma is implemented within the Linux/container infrastructure.
2. Vulnerability Management: Detect known vulnerabilities in libza and prioritize them for remediation.
3. Configuration Monitoring: Ensure libza configurations adhere to best security practices.
4. Compliance: Check if the usage of libza aligns with relevant cybersecurity regulations and standards.
5. Raise Exceptions where specific versions are not affected

By leveraging Phoenix Security, you not only unravel the potential threats but also take a significant stride in vulnerability management, ensuring your application security remains up to date and focuses on the key vulnerabilities.