XZ Backdoor: Supply Chain Jump Scare

On March 29, 2024, Andres Freund, a software engineer at Microsoft, disclosed CVE-2024-3094. This remote code execution backdoor, which scored the maximum CVSS severity of 10, represented a serious threat to Linux systems. Current reports suggest there was no active exploitation, but several mainline Linux distributions were impacted by the malicious backdoor. 

Impacted distributions include: 

• Fedora Rawhide and Fedora Linux 40 beta: 

• openSUSE Tumbleweed and openSUSE MicroOS: 

• Debian testing, unstable, and experimental distributions: 

• Kali Linux: 

• Arch Linux: 

What was the impact? 

As of the date of publication, there have been no reports of exploitation. While the malicious code did find its way into several mainline Linux distributions, the attack was discovered before it was included in the most popular, stable Linux versions. 

Early detection is key when dealing with supply chain attacks, and without it, this threat had the potential to be serious. 

Here is what happened, how to protect yourself, and why this wake-up call is something most organizations were ready for.  

What happened? 

Open-source projects have low budgets and many volunteer contributors, not all of whom are known. Abusing this anonymity, a threat actor added test code that can interfere with SSH authentications to the latest version of XZ tools, which is included by default in most Linux systems. This stealthy change can allowed attackers to remotely execute code via a no-auth RCE on systems that compiled the affected libraries.  

At the time of writing, it’s unknown if the threat actor took over an established account or gained trust in the community by making contributions for years prior to the attack.  

Fortunately, Microsoft engineers discovered the backdoor before it rolled out to most stable Linux branches, with the exceptions of Kali Linux, Fedora, and unstable versions of Arch and Debian. For a more detailed breakdown of the timeline, check out this post by Russ Cox. 

Is this a new attack method? 

Major supply chain attacks have been taking center-stage since 2021, when the SolarWinds supply chain attack caused over $90 million in damages to affected companies.  

This event caused most companies to update their security posture to address supply chain attacks, and many reacted by protecting their GitHub environments with detection tools like Varonis offers. The threat actors involved in the XZ attack left several IOCs that could have notified security teams of the threat, both before and after exploitation. 

How can I know if I’m using the affected XZ library? 

If you’re worried about being vulnerable to these backdoors, it’s easy to check a Linux machine for the vulnerable version of XZ utils (5.6.0 or 5.6.1) by opening a terminal window and running ”xz --version” to see your version. You should also check any running cloud environments for versions of Linux impacted by this backdoor. 
 
If you find the affected library, uninstall this package or downgrade to a version lower than 5.6.0 (5.4.6 is the latest stable version which was not affected by this CVE). Prioritize internet-facing servers which may be at greater risk. After doing so, it’s best to restart the OpenSSH service of the possibly infected machine, or to reboot it completely. 

With Varonis’ data classification engine, you’re able to quickly find instances of XZ utils in GitHub repositories or in source files stored in AWS, Azure, and beyond.  

How can I check for signs of exploitation? 

While there are no confirmed cases of exploitation, most threat actors follow the same patterns when activating a backdoor. Even if your supply chain is affected, looking for the common signs of exploitation is an efficient way to spot attacks in their first stages.  

Varonis Threat Labs recommends monitoring for the following warning signs that could be expose threat actors activating this backdoor. 

• Abnormal SSH connections from the vulnerable machine. 
• The exploit of the machine could include abuse of the OpenSSH tool, look for any abnormal network connectivity that involves this util. 
• Abnormal calls for identities\ roles \ resources using the machine instance. 
• After gaining access to a specific machine, an attacker would want to learn about the cloud environment that he accessed, which could be reflected in several enumeration activities. 
• Password spraying attempts from a single source to machines \ DB instances. 
• Attempt for lateral movement to other resources that might be hacked. 
• Unusual entitlement usage by machine instance. 
• An attacker can use the existing permissions structure in the account to evaluate his permissions and gain access to sensitive resources. 
• Privileged permissions granted to an entity that is part of the attack flow. 
• May indicate for attempting to escalate permission. 
• Abnormal behavior: termination or deletion attempts of logs. 
• Defense evasion technique to avoid detection. 
• Abnormal access \ download of sensitive storage data. 
• Abnormal access \ download of sensitive DBs or DB snapshots. 
• Abnormal behavior: termination or deletion attempts of large amounts of resource. 

What can developers learn from this? 

Open-source maintainers have become an increasing target of both sophisticated and low-skilled attacks. Platforms like PyPI used by open-source developers are frequently the target of typosquatting and account-takeover attacks which can introduce malicious code dependencies into popular projects. 

There are some suspicious events developers can look out for to know if they are experiencing a supply chain attack. 

In the XZ backdoor attack, the signs of an attack taking place included pull requests coming from users external to the organization, changing contact information to intercept vulnerability reports, and suspicious edits of GitIgnore files all pointing to potentially malicious behavior.   

Another important sign that identified an elevated risk is the creation of new release versions by users who don’t normally handle releases. This dramatically increases the risk that potentially unwanted software may have been added to the code prior to pushing the updated version. 

Open-source projects can help protect against these attacks by enforcing policies like 2fa, communicating before pushing new releases, and maintaining visibility into dependencies that could be malicious to quickly identify and remove libraries impacted by supply chain attacks. If you’re a developer, you should ensure your product doesn’t depend on a vulnerable version by using this Yara rule to detect vulnerable build environments.