Years ago I worked for a company that experienced a rash of office thefts. Wallets, laptops, phones, and other personal items were lifted from people’s cubicles on a daily basis. Things started to get ugly as co-workers grew suspicious of one another, and productivity took a noticeable hit. All manner of strategies were implemented to thwart the thieves, chief among them was the introduction of a double-badging process intended to fortify building entry. It mostly just created a human traffic jam at the front door.
Ultimately, the culprit was caught. Turns out it was a ring of employees who worked for the security company that was policing our facility and conducting the security simulations. Go figure, eh?
Over time, it became a funny anecdote, but like most exercises in absurdity, we discover that fallible systems continue to fail unless met with radical change. We also learn that there’s not enough radical thinking required to effect truly necessary improvements because, well, humans don’t like change.
The perfect example of this is the Zero Trust approach to enterprise security. There are industries built on loose interpretations of Zero Trust. They think they’re safe and secure until they discover that their blind acceptance uncovers the exact thing that makes them vulnerable.
If you paid attention to the XZ Utils backdoor vulnerability that was discovered last week, you can see exactly how this was manifested. When all was said and done, the damage was perpetrated by someone (or someone+N) who had gained the trust of the maintainer of the open source project. Two years of slowly contributing both legitimate, and as we now know, malicious code to XZ Utils, this developer nearly brought Linux to its knees.
👀 Prefer video content? Watch me break down this topic below.
Targeting SSH Through A Compression Library Backdoor
Last week, Red Hat issued a warning regarding a potential presence of a malicious backdoor in the widely utilized data compression software library XZ, which may affect instances of Fedora Linux 40 and the Fedora Rawhide developer distribution. CISA, or Cybersecurity & Infrastructure Security Agency, confirmed and issued an alert for the same CVE.
The compression software, referred to as XZ Utils (which includes the library liblzma), introduced the harmful code in versions 5.6.0 and 5.6.1, as disclosed by a developer who had been performing some routine micro-benchmarking. It’s clear that one of the components under threat is indirect, but intended: OpenSSH. While OpenSSH itself doesn't directly utilize liblzma, many Linux distributions apply patches to OpenSSH to enable support for systemd notifications through libsystemd, which in turn relies on the compression library. This interconnection creates a pathway for the backdoor to exploit.
Under specific conditions, a malicious actor could exploit this vulnerability to remotely access compromised systems running the OpenSSH server, bypassing typical authentication protocols. This heightened risk underscores the importance of promptly addressing vulnerabilities within software ecosystems to mitigate potential security breaches.
While there are no documented instances of these versions being integrated into any major Linux distribution's production releases, both Red Hat and Debian acknowledged that recently released beta versions utilized at least one of the compromised versions—specifically, in Fedora Rawhide and Debian's testing, unstable, and experimental distributions. Additionally, a stable release of Arch Linux is affected, although this distribution is not commonly employed in production systems.
When Zero Trust Trusts Too Much
The developer who discovered the issue, Andres Freund, observed a slight 600ms delay in ssh processes and then discovered that these processes were consuming an unexpected amount of CPU despite their expected immediate failure.
The human element played a crucial role in uncovering and addressing the attack. Despite seemingly routine micro-benchmarking, Freund's keen observation of unusual, but slightly longer, run times for SSH sessions and related failures within sshd alerted him to a potential anomaly. His persistence in investigating these seemingly minor issues led to the discovery of a supply-chain attack embedded within the XZ package.
So, major kudos to Mr. Freund. His insight and expertise helped to uncover an issue that could conceivably have brought down Linux – yeah, all of Linux.
While I applaud Mr. Freund’s efforts, the real story here is that the developer, Jia Tan, who introduced the backdoor had been working as an additional maintainer of XZ for two years. He was a trusted team member and had even faked his bona fides by participating in fixing the valgrind issue…which, it turns out, his own backdoor created.
So, think about this. One of the most important Linux projects on the planet was entrusted to only a few individuals…one of whom, it turns out, could not be trusted. Whatever the project team was using to authorize access was, and I say this at the risk of massive understatement, clearly not applying Zero Trust the right way. Yet, a trusted participant…a mainstay of the program…an individual seemingly worthy of validation…was, ultimately, the one who could not be trusted.
From a practical perspective, Zero Trust applied for user access is clearly not enough. Unless you are evaluating each command, query, or configuration change in real-time against dynamic policies that adapt to the context of the user, the sensitivity of the action, and the prevailing threat landscape, then your implementation of Zero Trust is ineffective and irrelevant.
StrongDM’s Zero Trust PAM Can Mitigate XZ Utils’ Back Door Attack Vectors
How does this all happen? Well, it starts with an erroneous presumption that traditional PAM actually operates on a Zero Trust model. Legacy PAM focuses on controlling and securing access to critical systems and data. Note the word access, because managing access is only one part of what’s needed:
How bad could this have been? Well, if left unnoticed, this could have been propagated to release versions of Linux distros that your enterprise is dependent on to run your business. I’m talking internet-scale bad. Once distributed that widely, and under the right conditions, we could have been in a literal world of hurt.
The line of demarcation between what doesn’t work and what is required for modern enterprises is this: the focus needs to be on actions, not access. That’s what we’ve architected into StrongDM’s Zero Trust PAM platform. If you look at what was required, but not available, above, then next take a look at how StrongDM solves for these issues. Keep in mind that we’re not solving for these as use cases or one-offs. This is our approach. This is, from our perspective, the only true way to secure enterprise systems. Let’s break these down:
- Elimination of SSH jump hosts: StrongDM eliminates the need for jump hosts with our reverse proxy architecture that establishes secure tunnels directly from the user's device to the target resource. It uses a Policy Engine that continually authorizes the user session with contextual signals. It allows security teams to have full visibility of user sessions. Eliminating SSH jump hosts means that no publicly available, and vulnerable SSH servers could be exploited.
- Zero credential exposure: StrongDM employs a zero-trust security model, meaning it assumes that no entity within or outside the network can be trusted by default. To prevent credential snooping, StrongDM employs several techniques:
- Credential injection at the target: StrongDM never exposes credentials to users that need access to a resource. These credentials are only used between the destination end of the tunnel and the resource, reducing the risk of credential exposure and unauthorized access.
- Prevention of lateral movement via credentials: One of the first valuable pieces of data that an attacker would look for are credentials, so that they can move laterally from host to host in a breached environment. Because credentials are never exposed, the value to an attacker is significantly lowered, and they’ll move on. Additionally, since SSH is not exposed directly to the internet when StrongDM is used, the attack vector is completely removed.
- Cloud-native and Certificate-based authentication: Instead of relying on traditional username/password authentication, StrongDM can use cloud-native IAM tokens and TLS certificates for back-end authentication for certain resource types. When certificates are used, you can use our trusted CA, or a handful of enterprise-trusted third-party CAs .
- End-to-end encryption: All communication between the user's device, the StrongDM platform, and the target resource is encrypted using industry-standard encryption algorithms, ensuring that credentials and sensitive data remain secure in transit.
It’s About Actions, Not Access
Modern stacks have grown to a complexity where it is difficult, if not impossible, to manually manage privileged access across your entire organization. The combination of different technologies, different roles, different levels of permissions, and constantly evolving threats are driving a critical need to streamline how infrastructure access is managed. These are the core challenges that StrongDM addresses.
Strong enforcement mechanisms ensure that access policies are consistently applied and enforced across the entire infrastructure, regardless of the user's location or device type. This ensures uniform compliance with security policies and helps prevent unauthorized access attempts.
Ultimately, StrongDM’s Zero Trust PAM enables greater precision and contextual awareness for enterprise security teams by providing a comprehensive framework for all actions. By implementing micro-authorizations, leveraging contextual awareness, and enforcing strong security policies, organizations can enhance their security posture and better protect their critical assets against evolving cyber threats.
Want to see StrongDM in action? Book a demo.
Get the Zero Trust eBook PDF
