Undoubtedly one of the most notorious software supply chain attacks the software world has seen, the XZ attack sent shockwaves throughout the open-source community, marking a significant shift in the landscape of cybersecurity threats. The unfolding of this attack is no less than awing or perhaps daunting, showing the attacker’s sophistication, patience, and cunning.
In 2021, an individual operating under the name of “Jia Tan” has emerged into the open-source community as a committed, efficient, and harmless contributor. Over the span of more than two years Jin Tan has been making contributions to the XZ compression library, earning the trust of the community to the extent that they were given both commit access and maintainership. The XZ compression library holds a sub-component named liblzma, which is a dependency of the critical OpenSSH sshd tool that runs on wide-spread linux-based OSs such as Debian, Ubuntu, and Fedora.
Within libizma, the attacker has embedded a backdoor. This backdoor enables the attacker to detect covert commands from the attacker at the beginning of an SSH session, enabling them to execute any command on the compromised system remotely without the need to authenticate. To many, this would be seen as the ultimate hack and unquestionably a profound example of the danger that lies in transitive dependencies.
This article will discuss different security measures commonly used in application security, shed light on their traits, and how they allow an attack such as the XZ attack to go unnoticed. By understanding the mechanics of the XZ attack, we can enhance our vigilance and response to such attacks. Looking into the fundamentals of the set of tools we have at hand, we can better prepare ourselves to confront future threats. From identifying the threats to implementing the counter-measures to defend our application from them, consequently reinforcing the security posture of our infrastructure.
The Danger Within – Malicious Maintainer Code Injection
Malicious code injection is a cyber-attack where a piece of code is ill-intently implanted into a program or system and enables the attacker to execute unauthorized commands that can compromise the availability, integrity or confidentiality of the system, its data or its users. A code injection conducted successfully can lead to significant security breaches, including unauthorized access to sensitive data, system disruption, or compromising an entire network.
An uncommon yet potent vector of malicious code injection is the “Become a Maintainer” (AV-800) attack vector, also known as “Malicious Maintainer”. This type of attack occurs when a trusted authentic maintainer of a software package exploits their privileged position in order to intentionally inject harmful code into the package. A close relative of this would be the “Compromise User” (AV-600) attack vector, in which an external malicious actor impersonates a valid account and gains unauthorized access to the package codebase, again, in order to inject malicious code.
But despite their similarity, the “Malicious Maintainer” attack vector is different and potentially way more potent, for they are able to go a longer mile to leverage their position through their authenticity and due to the trust placed in them, making detection highly elusive and challenging. It enables them to introduce vulnerabilities, masking them as legitimate updates and patches.
In this type of attack, using social engineering could not only empower the impact of their planned attacks, but also cover their tracks as they go along with paving the way towards execution. To the general OSS community, even though actually compromised, updates of packages that are distributed via the maintenance team and upstream source seem legitimate, harmless and even more so – more safe than their predecessors. Making these attacks perfect for running free in the wild.
The XZ attack is a prime example of “Malicious Maintainer”. It seems the XZ attacker Jin Tan executed a meticulous plan and impressively orchestrated his mischief endeavors for years, gaining the trust of the XZ library contributors, working his way up the maintainer hierarchy, doing the work to be able to evade peer-review, which ultimately enabled them to embed the malicious alterations within the XZ compression library and the libizma component, gaining access to exploit masses of linux-based operating system users.
The Big Miss
As organizations we deploy a myriad of application security tools. Some of the most predominant ones are ASPM, Static SCA, and Dynamic SCA. Each tool plays a critical role in our cybersecurity ecosystem. Each designed to pre-emptively identify and mitigate vulnerabilities and protect us from potential attacks, save our system data and users from exploit. However, looking further in, we find that the efforts of each would be futile against an attack in the likes of the XZ attack. The core engines of these tools and how they operate are unfortunately inherently useless in the case of a malicious maintainer attack.
ASPM, the overlord of application security, provides a comprehensive macro-level view of the security posture across all applications within an organization. It aggregates security-related data from various sources and tools in our organization, providing the security officers a unified view of their application security and enabling them to assess threats risks and lead remediation and mitigation plans.
The sources ASPMs tap into include static and dynamic software composition analysis tools, SAST, DAST and more. Due to the fact that ASPM tools rely on a many other tools, it is difficult to state their own direct capability to detect attacks, however, if for instance we look into tools specially designed to detect anomalous developer behavior and detect malicious intent, despite it sounding like the perfect solution for this type of attack – it would also fail detecting the XZ attack. Not only the attacker used a very sophisticated technique of embedding the backdoor that could not be observed in his source code commits and contributor behavior, but they’re also a malicious maintainer that kept a straight face for years, not creating any pattern to be recognized – up until the actual execution of the attack. Hence, ASPM would not be our sure path to protection.
Software composition analysis tools (SCAs) are ubiquitous, and many organizations rely on them for protection against 3rd party attacks. Which is exactly what the XZ tools package is. However, despite their many strengths, these tools possess inherent limitations, particularly when facing a threat as nuanced as the XZ attack. This can be attributed to the fact that these tools lean solely on the existence of already known vulnerabilities. If these 3rd party dependencies have no CVEs – then SCAs are useless. Static or dynamic, manifest or runtime, the XZ attack would come out of nowhere to these tools. Consequently, a static SCA tool scanning our manifest files for a known CVE would do no good in this case.
For the dynamic SCA this would be even more so true. Setting aside the lack of known CVE, due to the fact that these test the running of the application in real-time, it would mean the malicious execution would have to manifest itself within the dynamic test. The nature of the XZ backdoor is such that it is niche and does not run in any configuration. It is designed to take place only as a part of sshd binary that runs on amd64 systems running glibc, that are using either Debian or Red Hat based distributions. This execution is highly specific, forcing the dynamic test configuration to be so as well and to the exact same extent. That is far from likely or probable. Therefore, SCAs, static or dynamic, would fail to spot the XZ attack. Jin Tan – wins.
How Myrror Detects The XZ Attack
In this intricate web of software complexities described above one might believe that the stars need to align in order to detect an attack like XZ and prevent its destructive impacts. While that may be true for many, there is an elegant solution to the challenge at hand.
Myrror Security, composed of a set of complementary tools, not only provides a holistic view of potential security threats, but also enables the identification of highly sophisticated attacks – even one as clever and elusive as the XZ attack.
As opposed to the former, Myrror does not solely rely on the widely known and published CVEs. It also does not act as a runtime tool, delivering us the benefit of detection at an earlier stage of development and allowing us to avoid configuring extensive and exhaustive dynamic tests. Lastly, it does not rely on monitoring contributor behavior over time in order to spot anomalies that identify them as malicious perpetrators.
On top of its other capabilities of static SCA and reachability analysis avoiding and remediating the known, an attack such as the XZ attack is where Myrror shines. Through comprehensive binary analysis followed by an AI-based malicious code detection mechanism, Myrror delivers where others fail, and can catch such an attack not in real-time as it happens – but even way before it reaches production.
When Myrror protects your application, it utilizes its proprietary binary to source analysis engine, taking all your application’s dependency binaries and verifying them against the actual upstream source code. If any tampering has been done and the two show a difference – Myrror will know and sound the alarms. This is of course great for tampering done in transit – but not only.
In the XZ case, the backdoor was embedded within the build processes of the upstream package. In this way, the attacker has created a (supposedly) trusted upstream source code that would actually become malicious once it is compiled. When Myrror is on premise, it is exactly this mismatch between the trusted published source code and our application dependency binaries that would raise a flag and be marked suspicious. From this point, Myrror’s system would reverse engineer this difference, and consequently use its AI-based malicious code detection algorithms to spot any piece of code that might present a threat – thus exposing the clever attack.
Therefore no matter if tampered in transit or upstream by the most devoted and trusted maintainer, if it is malicious – Myrror will identify.
This robust methodology ensures that organizations can not just react to known threats but proactively identify and mitigate emerging ones.
As per the aforementioned, Myrror is up for the challenge, and not only for this one alone. With the methodology described above Myrror can handle a variety of attacks, including Typo-squatting, Dependency Confusion, Distribution Server Attacks and more.
