{"id":6361,"date":"2024-04-08T14:34:18","date_gmt":"2024-04-08T21:34:18","guid":{"rendered":"https:\/\/objectsecurity.com\/?p=6361"},"modified":"2024-11-15T15:06:15","modified_gmt":"2024-11-15T23:06:15","slug":"xz-utils-backdoor","status":"publish","type":"post","link":"https:\/\/objectsecurity.com\/xz-utils-backdoor\/","title":{"rendered":"Detecting the xz-utils Backdoor with Automation"},"content":{"rendered":"

In this ObjectSecurity blog post, we discuss how automated binary vulnerability analysis helps detect advanced attacks such as the recently discovered “xz-utils<\/code> backdoor”<\/em>, which was committed on March 25, 2024 to a ubiquitous library in the Linux ecosystem, via the xz-utils<\/code> GitHub repository that has since been removed from the site by Github and Microsoft. This malware was disguised as a binary file meant to act as input for an automated test<\/em> that runs along with new public build versions of the xz-utils<\/code> library. Had this exploit not been detected by Andres Freund, a developer at Microsoft, countless Linux\/Unix systems would have become vulnerable to what is suspected to be a nation state attack.
\n<\/strong><\/span><\/p>\n

On March 25th<\/sup>, 2024, this intentional backdoor was committed to a ubiquitous library in the Linux ecosystem, via the xz-utils<\/code> GitHub repository that has since been removed from the site by Github and Microsoft. This malware was disguised as a binary file meant to act as input for an automated test<\/em> that runs along with new public build versions of the xz-utils<\/code> library.<\/p>\n

Only after a multi-stage parsing process is completed, does the backdoor become injected into release versions of xz-utils<\/code><\/em>. The payload injected at the end of this process results in a malicious shared object (.SO) file in versions 5.6.0 and 5.6.1 of the liblzma<\/code> dependency of xz-utils<\/code>.<\/p>\n

xz-utils<\/code> defines a shared library called liblzma<\/code> that is meant to provide compression and decompression capabilities to numerous downstream dependents. One of these dependents is the SSH daemon, sshd. This daemon is the core program of any SSH server. Thus, had this attack succeeded, it would have effectively made Linux servers and computers open for unauthorized access. Thankfully, this exploit was detected by Andres Freund, a developer at Microsoft. You can read his original OSS post <\/a>here<\/u>. Due to the complexity of the exploit, it is suspected that a nation state is behind this attack.<\/p>\n

CISA has also catalogued this backdoor as <\/a><\/span>CVE-2024-3094<\/u>.<\/p>\n

This is the first attack of its kind: <\/strong>This is because the malware itself is not truly present in the source code alone. Only when we examine the binary are we capable of detecting this backdoor<\/u>.<\/p>\n<\/div>

Finding the Abused system()<\/em><\/code> Call<\/h2>\n<\/div><\/div><\/div>

The infected libzma.so.5.6.X<\/code> instead allows for remote code execution (RCE) prior to authentication by extracting a command from the authenticating client’s SSH certificate and passing it to system()<\/code>, in the place where RSA_public_decrypt<\/code> would execute normally.<\/p>\n

If we perform a backtrace in GDB, we can see the path obfuscation taken before reaching system()<\/code> (see screenshot).<\/p>\n

The analysis of the call shows a recursive structure at address 0x132C8<\/code> in the liblzma binary file. The process likely depends on interactions with other binaries, such as standard libraries, and this is likely a dead end for many more novice reverse engineers. What stands out, though, is the obfuscated control flow.<\/p>\n<\/div><\/div><\/div>

<\/span><\/div><\/div><\/div><\/div><\/div>

We now demonstrate the automated findings of ObjectSecurity’s BinLens\u2122<\/a> (formerly ObjectSecurity OT.AI Platform)\u00a0below, where this control flow is further analyzed and characterized as a particularly malevolent finding.<\/p>\n

ROP Exploitation<\/h2>\n

The results of our analysis showed the liblzma binary to behave as a Return-Oriented Programming (ROP) attack. The output showed, consistently, an overly complex control flow and the presence of a vast amount of ROP weaknesses. This type of attack leverages existing code snippets within a program, known as \u201cgadgets,\u201d to execute arbitrary operations. Each gadget typically ends with a return instruction and is meticulously chosen to perform a step towards executing an attacker\u2019s payload without the need to inject new code, thus evading typical security measures that scan for code injections.<\/p>\n

Understanding Return-Oriented Programming (ROP)<\/h3>\n

At its core, ROP is a sophisticated exploitation technique that abuses the way software handles subroutine returns. It manipulates the stack, which is a crucial data structure used to store return addresses and local variables for functions. In a typical ROP attack, an adversary carefully crafts a stack that includes a sequence of return addresses, each pointing to a chosen gadget. By manipulating the program\u2019s execution flow, these gadgets are executed in sequence to perform arbitrary actions.<\/p>\n

The technique hinges on finding and using sequences of machine instructions that are already present in the running program\u2019s memory, the \u201cgadgets\u201d. These gadgets are pieced together to construct a payload that achieves the attacker\u2019s objectives, such as compromising a system or stealing data.<\/p>\n

Correlating Weird Control Flow with Increased ROP Attack Potential<\/h3>\n

The complexity of control flow in an application can significantly impact its vulnerability to ROP attacks. When control flow is irregular or convoluted, it often indicates numerous branches and potential execution paths. This environment can be ripe for ROP for several reasons:<\/p>\n

    \n
  1. Increased Gadget Availability<\/strong>: Complex control flows imply a higher diversity of code snippets and function epilogues. This variety provides a richer set of gadgets for attackers to exploit, enabling them to find the necessary components to string together their desired malicious functionality. A prominent feature of the liblzma<\/code> backdoor is its complex control flow and increased number of ROP gadgets.<\/em><\/li>\n
  2. Obfuscation and Detection Evasion<\/strong>: Irregular control flows can make it more challenging for static analysis tools to accurately map out potential execution paths and detect anomalous sequences that might signify an exploit. This obfuscation naturally aids attackers in hiding their exploit chains within the legitimate complexity of the software. The xz-utils<\/code> attack employs a sophisticated linker manipulation that can evade detection.<\/em><\/li>\n
  3. Compromised Flow Integrity<\/strong>: The very nature of ROP exploits involves diverting the intended control flow of a program. A binary that inherently contains complex or non-linear execution paths may be more susceptible to further manipulations without these anomalies being readily apparent to monitoring tools or even during manual review. Once triggered, the liblzma<\/code> attack highjacks the control flow to access the SSH daemon for backdoor access.<\/em><\/li>\n<\/ol>\n

    Unveiling the Veil: The Critical Role of Linker Operations in Cybersecurity<\/h3>\n

    The Procedure Linkage Table (PLT) and the Global Offset Table (GOT) are fundamental components in the dynamic linking process that enables programs to utilize shared libraries for common functionality. This system is both programmable and dynamic, which conserves memory and supports modular programming. However, this flexibility also introduces significant risks. When manipulated, the PLT and GOT can alter the intended control flow of an application, potentially turning into conduits for ROP attacks.<\/p>\n

    When malware, like that found in the xz-utils<\/code> case, consistently interacts with the PLT and GOT at specific addresses, it reveals a methodical approach to hijack these mechanisms. This consistency is a critical signal, a pattern that, once recognized, can be monitored and mitigated against.<\/p>\n

    Correlation Between ROP Gadgets and Linker Addresses<\/h3>\n

    ObjectSecurity’s BinLens\u2122<\/a> (formerly ObjectSecurity OT.AI Platform) demonstrates consistent interactions at a common address, spanning multiple key sections that our platform utilizes to measure linker manipulations in PLT and GOT. This uniformity in address usage across four critical linker sections is an assessment of our platform’s monitoring capabilities. These findings also associated to a function, __cxa_finalize<\/code>, that correlates to the presence of multiple ROP gadgets in this region:<\/p>\n<\/p>\n

    Analyzing section 1<\/code><\/span>
    \n__cxa_finalize at 17824 interacts with cat 1 linker ops<\/code><\/span>
    \nAnalyzing section 2<\/code><\/span>
    \n__cxa_finalize at 17824 interacts with cat 2 linker ops <\/code><\/span>
    \nAnalyzing section 3<\/code><\/span>
    \n__cxa_finalize at 17824 interacts with cat 3 linker ops<\/code><\/span>
    \nAnalyzing section 4<\/code><\/span>
    \n__cxa_finalize at 17824 interacts with cat 4 linker ops<\/code><\/span><\/p>\n

    <\/div>\n

    \n

    We report that this dual identification is shown as the basis of a detection mechanism for this class of attacks that leverage complex execution flows and ROP gadgets. With this level of insight, red, purple, and blue teams are equipped to preemptively address and neutralize sophisticated attack vectors, securing their systems against the most cunning of cyber adversaries.<\/p>\n<\/div><\/div><\/div><\/div><\/div>

    Validation of Findings<\/h2>\n

    We wanted to know with the unpatched and patched liblzma<\/code> samples whether the detection of ROP gadgets alone is sufficient in making the determination that this backdoor exists within our analyses. The logistic regression model<\/em> is chosen as an ideal method for this analysis because it allows for the integration of multiple factors and provides a probabilistic framework for assessing the impact of these factors on the likelihood of our platform\u2019s final determinations.<\/p>\n

    We modeled our findings across three populations:<\/p>\n