Backdoor in XZ Utils That Almost Happened

Read Time:6 Minute, 45 Second

Last week, the internet dodged a major nation-state attack that would have had catastrophic cybersecurity repercussions worldwide. It’s a catastrophe that didn’t happen, so it won’t get much attention—but it should. There’s an important moral to the story of the attack and its discovery: The security of the global internet depends on countless obscure pieces of software written and maintained by even more obscure unpaid, distractible, and sometimes vulnerable volunteers. It’s an untenable situation, and one that is being exploited by malicious actors. Yet precious little is being done to remedy it.

Programmers dislike doing extra work. If they can find already-written code that does what they want, they’re going to use it rather than recreate the functionality. These code repositories, called libraries, are hosted on sites like GitHub. There are libraries for everything: displaying objects in 3D, spell-checking, performing complex mathematics, managing an e-commerce shopping cart, moving files around the internet—everything. Libraries are essential to modern programming; they’re the building blocks of complex software. The modularity they provide makes software projects tractable. Everything you use contains dozens of these libraries: some commercial, some open source and freely available. They are essential to the functionality of the finished software. And to its security.

You’ve likely never heard of an open-source library called XZ Utils, but it’s on hundreds of millions of computers. It’s probably on yours. It’s certainly in whatever corporate or organizational network you use. It’s a freely available library that does data compression. It’s important, in the same way that hundreds of other similar obscure libraries are important.

Many open-source libraries, like XZ Utils, are maintained by volunteers. In the case of XZ Utils, it’s one person, named Lasse Collin. He has been in charge of XZ Utils since he wrote it in 2009. And, at least in 2022, he’s had some “longterm mental health issues.” (To be clear, he is not to blame in this story. This is a systems problem.)

Beginning in at least 2021, Collin was personally targeted. We don’t know by whom, but we have account names: Jia Tan, Jigar Kumar, Dennis Ens. They’re not real names. They pressured Collin to transfer control over XZ Utils. In early 2023, they succeeded. Tan spent the year slowly incorporating a backdoor into XZ Utils: disabling systems that might discover his actions, laying the groundwork, and finally adding the complete backdoor earlier this year. On March 25, Hans Jansen—another fake name—tried to push the various Unix systems to upgrade to the new version of XZ Utils.

And everyone was poised to do so. It’s a routine update. In the span of a few weeks, it would have been part of both Debian and Red Hat Linux, which run on the vast majority of servers on the internet. But on March 29, another unpaid volunteer, Andres Freund—a real person who works for Microsoft but who was doing this in his spare time—noticed something weird about how much processing the new version of XZ Utils was doing. It’s the sort of thing that could be easily overlooked, and even more easily ignored. But for whatever reason, Freund tracked down the weirdness and discovered the backdoor.

It’s a masterful piece of work. It affects the SSH remote login protocol, basically by adding a hidden piece of functionality that requires a specific key to enable. Someone with that key can use the backdoored SSH to upload and execute an arbitrary piece of code on the target machine. SSH runs as root, so that code could have done anything. Let your imagination run wild.

This isn’t something a hacker just whips up. This backdoor is the result of a years-long engineering effort. The ways the code evades detection in source form, how it lies dormant and undetectable until activated, and its immense power and flexibility give credence to the widely held assumption that a major nation-state is behind this.

If it hadn’t been discovered, it probably would have eventually ended up on every computer and server on the internet. Though it’s unclear whether the backdoor would have affected Windows and Mac, it would have worked on Linux. Remember in 2020, when Russia planted a backdoor into SolarWinds that affected 14,000 networks? That seemed like a lot, but this would have been orders of magnitude more damaging. And again, the catastrophe was averted only because a volunteer stumbled on it. And it was possible in the first place only because the first unpaid volunteer, someone who turns out to be a national security single point of failure, was personally targeted and exploited by a foreign actor.

This is no way to run critical national infrastructure. And yet, here we are. This was an attack on our software supply chain. This attack subverted software dependencies. The SolarWinds attack targeted the update process. Other attacks target system design, development, and deployment. Such attacks are becoming increasingly common and effective, and also are increasingly the weapon of choice of nation-states.

It’s impossible to count how many of these single points of failure are in our computer systems. And there’s no way to know how many of the unpaid and unappreciated maintainers of critical software libraries are vulnerable to pressure. (Again, don’t blame them. Blame the industry that is happy to exploit their unpaid labor.) Or how many more have accidentally created exploitable vulnerabilities. How many other coercion attempts are ongoing? A dozen? A hundred? It seems impossible that the XZ Utils operation was a unique instance.

Solutions are hard. Banning open source won’t work; it’s precisely because XZ Utils is open source that an engineer discovered the problem in time. Banning software libraries won’t work, either; modern software can’t function without them. For years security engineers have been pushing something called a “software bill of materials”: an ingredients list of sorts so that when one of these packages is compromised, network owners at least know if they’re vulnerable. The industry hates this idea and has been fighting it for years, but perhaps the tide is turning.

The fundamental problem is that tech companies dislike spending extra money even more than programmers dislike doing extra work. If there’s free software out there, they are going to use it—and they’re not going to do much in-house security testing. Easier software development equals lower costs equals more profits. The market economy rewards this sort of insecurity.

We need some sustainable ways to fund open-source projects that become de facto critical infrastructure. Public shaming can help here. The Open Source Security Foundation (OSSF), founded in 2022 after another critical vulnerability in an open-source library—Log4j—was discovered, addresses this problem. The big tech companies pledged $30 million in funding after the critical Log4j supply chain vulnerability, but they never delivered. And they are still happy to make use of all this free labor and free resources, as a recent Microsoft anecdote indicates. The companies benefiting from these freely available libraries need to actually step up, and the government can force them to.

There’s a lot of tech that could be applied to this problem, if corporations were willing to spend the money. Liabilities will help. The Cybersecurity and Infrastructure Security Agency’s (CISA’s) “secure by design” initiative will help, and CISA is finally partnering with OSSF on this problem. Certainly the security of these libraries needs to be part of any broad government cybersecurity initiative.

We got extraordinarily lucky this time, but maybe we can learn from the catastrophe that didn’t happen. Like the power grid, communications network, and transportation systems, the software supply chain is critical infrastructure, part of national security, and vulnerable to foreign attack. The U.S. government needs to recognize this as a national security problem and start treating it as such.

This essay originally appeared in Lawfare.

Read More

[KIS-2024-03] Invision Community <= 4.7.16 (toolbar.php) Remote Code Execution Vulnerability

Read Time:12 Second

Posted by Egidio Romano on Apr 10

——————————————————————————
Invision Community <= 4.7.16 (toolbar.php) Remote Code Execution Vulnerability
——————————————————————————

[-] Software Link:

https://invisioncommunity.com

[-] Affected Versions:

Version 4.7.16 and prior versions.

[-] Vulnerability Description:

The vulnerability is located in the…

Read More

[KIS-2024-02] Invision Community <= 4.7.15 (store.php) SQL Injection Vulnerability

Read Time:15 Second

Posted by Egidio Romano on Apr 10

——————————————————————–
Invision Community <= 4.7.15 (store.php) SQL Injection Vulnerability
——————————————————————–

[-] Software Link:

https://invisioncommunity.com

[-] Affected Versions:

All versions from 4.4.0 to 4.7.15.

[-] Vulnerability Description:

The vulnerability is located in the
/applications/nexus/modules/front/store/store.php script….

Read More

Multiple Issues in concretecmsv9.2.7

Read Time:24 Second

Posted by Andrey Stoykov on Apr 10

# Exploit Title: Multiple Web Flaws in concretecmsv9.2.7
# Date: 4/2024
# Exploit Author: Andrey Stoykov
# Version: 9.2.7
# Tested on: Ubuntu 22.04
# Blog: http://msecureltd.blogspot.com

Verbose Error Message – Stack Trace:

1. Directly browse to edit profile page
2. Error should come up with verbose stack trace

Verbose Error Message – SQL Error:

1. Page Settings > Design > Save Changes
2. Intercept HTTP POST request and place single…

Read More

OXAS-ADV-2024-0001: OX App Suite Security Advisory

Read Time:23 Second

Posted by Martin Heiland via Fulldisclosure on Apr 10

Dear subscribers,

We’re sharing our latest advisory with you and like to thank everyone who contributed in finding and solving those
vulnerabilities. Feel free to join our bug bounty programs for OX App Suite, Dovecot and PowerDNS at YesWeHack.

This advisory has also been published at
https://documentation.open-xchange.com/appsuite/security/advisories/html/2024/oxas-adv-2024-0001.html.

Yours sincerely,
Martin Heiland, Open-Xchange GmbH…

Read More

Trojan.Win32.Razy.abc / Insecure Permissions (In memory IPC)

Read Time:17 Second

Posted by malvuln on Apr 10

Discovery / credits: Malvuln (John Page aka hyp3rlinx) (c) 2024
Original source:
https://malvuln.com/advisory/0eb4a9089d3f7cf431d6547db3b9484d.txt
Contact: malvuln13 () gmail com
Media: twitter.com/malvuln

Threat: Trojan.Win32.Razy.abc
Vulnerability: Insecure Permissions (In memory IPC)
Family: Razy
Type: PE32
MD5: 0eb4a9089d3f7cf431d6547db3b9484d
SHA256: 3d82fee314e7febb8307ccf8a7396b6dd53c7d979a74aa56f3c4a6d0702fd098
Vuln ID: MVID-2024-0678…

Read More

CVE-2023-27195: Broken Access Control – Registration Code in TM4Web v22.2.0

Read Time:24 Second

Posted by Clément Cruchet on Apr 10

CVE ID: CVE-2023-27195

Description:
An access control issue in Trimble TM4Web v22.2.0 allows
unauthenticated attackers to access a specific crafted URL path to
retrieve the last registration access code and use this access code to
register a valid account. If the access code was used to create an
Administrator account, attackers are also able to register new
Administrator accounts with full rights and privileges.

Vulnerability Type: Broken…

Read More

python-django3-3.2.25-1.el9

Read Time:14 Second

FEDORA-EPEL-2024-76d6941f10

Packages in this update:

python-django3-3.2.25-1.el9

Update description:

Security fixes for

CVE-2024-27351 Potential regular expression DOS in django.utils.text.Truncator.words()
CVE-2023-41164 Potential DOS vulnerability in django.utils.encoding.uri_to_iri()

Read More