XZ Utils: A Fable on Proactive Risk Management

Uploaded on 2024-05-15 in TECHNOLOGY--Resilience, NEWS-Cybersecurity News, FREE TO VIEW

The recent disclosure from the OpenSSF and OpenJS Foundation has spotted a trend of social engineering attacks aimed at under-maintained open-source projects in the wake of the attempted XZ Utils backdooring. Indeed, the XZ Utils exploit may not be the isolated software supply chain attack we hoped it was.

This second potential attack is still being investigated, but OpenSSF and OpenJS identified a worryingly similar pattern of multiple sock puppet accounts operating on another project.

Open source is an attractive target for all manner of malicious actors - nation-state backed and otherwise, but they are not inevitable. Open source consumers should be aware of this reality, and must be alert to react to any new discoveries of possible social engineering takeovers. Companies must keep a close eye on the software components they’re using and ensure they have the capability to patch any issues quickly if needed. By giving their development teams proper support, companies can help protect their digital assets from future social engineering attacks like XZ Utils.

The Nature Of XZ

XZ Utils is a widely used component in Linux distributions and was in the process of being adopted by Fedora and Debian. Comparable to other Linux utilities like bzip or gzip, the XZ utility is used for lossless data compression across Unix-like operating systems. Its role as a common utility made it a prime target for attack. While the identity of the threat actor “Jia Tan” is unknown and suspected of being a nation-state sock puppet, it’s sobering how close they were to succeeding. If that had been the case, XZ would have dwarfed Log4j or the SolarWinds backdoor of 2021 to become one of the most devastating software supply chain attacks.

“Jia Tan” started as a seemingly innocent maintainer on the XZ project in 2021. They approached the original maintainer following a social pressure campaign that involved multiple fake sock puppet email accounts to generate outrage and pressure. Their goal was to make out that the sole maintainer of this project wasn’t acting on fixes fast enough.

By applying pressure on the maintainer, bad actors manufactured the opportunity to appear as a saviour and create a trusting relationship.

Initially, “Jia” gained the maintainer’s trust by contributing genuinely useful patches. Once a degree of trust had been established, “Jia” began to suggest and add new features. Over the next two years, the bad actor added parser code and malware in plain sight to versions 5.6.0 and 5.6.1. With the intent of creating a backdoor master key containing code to execute an encrypted message across Linux systems and bypass the entire SSH authentication process. They also began advocating for the XZ project to be adopted by major Linux distributions as a default package.

Fortunately, the attempt was uncovered before significant damage could be done.. The industry must acknowledge the presence of a highly sophisticated, well-resourced group of bad actors operating over extended durations.

Advanced Persistent Threat actors are traditionally associated with nation-state hacking operations against corporations, but now there is clear evidence that this activity extends to all parts of our digital infrastructure, including open-source projects.

Whenever these attempts are made, there are often copycats on other projects. For example, within the weeks following PyPI, there was a 7000% increase in dependency confusion copycats published to the npm registry. Similarly, with the XZ campaign, evidence has already surfaced of similar attempts against other projects. Since the genie is now out of the lamp there is no question that this type of operation will be seen again.

It’s fair to say that the open-source community is built on trust. This attack calls into question that very core notion - and actively subverts it. To prevent a similar situation from happening again, the industry is now preparing to look at suspicious activity and behaviours that have taken place over the past few years.

These bad actors put a lot of work into improving the efficiency of the XZ compression algorithm before trying to execute the attack. The evidence points to a well-resourced attacker or adversary backed by a state, having the capability to engage for several years and patiently working with the original maintainer while striking in secret.

You Can’t Fight A Smokeless Fire

Using fewer, higher-quality projects will reduce your vulnerable attack surface while employing a Software Bill of Materials (SBOM) for containers and virtual machines will give you an understanding of the software you depend on. SBOMs allow organisations to implement effective quality control measures and monitor for any bad packages that need to be resolved. Establishing supplier standards for your software and reinforcing the open-source ecosystem's support system are necessary steps to take for your security.

While the community strengthens defences upstream, the downstream must also be ready when incidents are uncovered and act swiftly by patching affected systems.

Being proactive is not a tax, it's a collective responsibility to safeguard the integrity of the software supply chain. Science suggests building the capability to be able to proactively manage patches in this way also makes development teams more productive as a result.

The recent attack on the XZ compression tool shows how important it is for companies to manage risks in their open-source software. Organisations must keep a close eye on their components, build the capability to patch any issues quickly, and help support single maintainer projects which are more susceptible to targeting. Prioritising projects with strong maintainer structures is important but implementing robust monitoring systems is a must. This proactivity rather than reactivity will help protect digital infrastructure from any future attacks.

Another important element of this attack is that it was because the XZ project is open source is precisely why the intrusion was ultimately discovered. A developer noticing the performance hit of the package uncovered the problem and exposed it to the world, who took up fixing the issue. This is precisely why using open source continues to be the best path for organisations to leverage the best innovation out there. If the project had been closed it could have remained hidden indefinitely.

As the threat attack landscape evolves, the responsibility lies with the entire open source community and the community using it to be on alert. For consumers, the attempted breach of the XZ Utils serves as a sobering reminder of the critical importance of robust risk management practices and ongoing support for project maintainers.

By collectively fortifying defences and prioritising the integrity of the software supply chain, we can mitigate the risks posed by future attacks and contribute to continued, safe, trustworthy open-source innovation.

Ilkka Turunen is Field CTO at Sonatype

Image: Oleksandr Hruts

You Might Also Read:

What’s The Problem With Open-Source Software & Cybersecurity?:

DIRECTORY OF SUPPLIERS - Open Source Security:

___________________________________________________________________________________________

If you like this website and use the comprehensive 7,000-plus service supplier Directory, you can get unrestricted access, including the exclusive in-depth Directors Report series, by signing up for a Premium Subscription.