The Persistence Problem in Non-Windows Security
Non-Windows operating systems are sometimes LESS secure
Securing Linux, UNIX, and macOS operating systems presents a unique set of challenges rooted in their open and flexible design. While this architecture promotes collaboration and innovation, it also creates inherent vulnerabilities that can be exploited by a determined attacker. This whitepaper discusses these challenges, focusing on the fundamental problem of persistence and the fragility of security agents against a root-level compromise.
The Open Architecture Paradox 🤝
The operating systems in the Linux, UNIX, and macOS family are built on a foundation of open, modular design. This philosophy, originating from UNIX, encourages transparency and community-driven development. Linux, in particular, thrives on its open-source model, allowing developers and security researchers to inspect and contribute to the source code. This open nature, while beneficial for rapid bug fixes and feature development, gives attackers the same level of visibility into the system's inner workings. They can study the code to find vulnerabilities and anticipate how security tools will function, making them more effective at bypassing defenses.
The Insufficiency of User-Level Tools 🧰
Many cybersecurity agents operate at the user level. They are applications that run on the system and, as such, are subject to the same permissions and limitations as any other program. An attacker who gains administrative privileges can easily terminate, suspend, or modify these tools. For example, a malicious actor with sudo access can simply use kill -9 to stop a security agent's process. These tools are valuable for general threat detection but are fundamentally vulnerable to a targeted, privileged attack.
Kernel modules, in contrast, operate with the highest level of privilege in kernel space (Ring 0). They have direct, unimpeded access to all system functions and data. This allows them to monitor and control processes, file systems, and network traffic with a level of granularity and efficiency that user-level tools cannot. However, even these powerful modules are not immune to attack.
The Fragility of Kernel Modules 💥
By default, security kernel modules can be unloaded from a running system. A malicious actor with sudo or root access can simply use commands like rmmod to remove a security module. This action effectively disables the most powerful layer of the security agent's defense, leaving the system exposed. This is a critical flaw: the most effective tools for protecting a system can be easily deactivated by the very adversary they are designed to stop.
The Limits of Mandatory Access Controls (MACs) 🔐
To address this issue, operating systems employ Mandatory Access Control (MAC) policies, such as SELinux and AppArmor. These frameworks enforce a system-wide, kernel-level access policy that is designed to be more secure than the standard Discretionary Access Control (DAC) model. A MAC policy can, for example, prevent a root user from unloading a specific security kernel module. This seems like a robust solution, but there's a catch.
The very mechanism that provides this protection can be disabled by a user with root access. A malicious actor with elevated privileges can simply turn off the MAC policy (e.g., using sudo setenforce 0 on a system with SELinux), then proceed to unload the security module. This means there is no solid, inherent manner to prevent a malicious actor with root access from disabling security kernel modules on these systems.
Attacker Tradecraft: A Calculated Bypass 🕵️♂️
A modern attacker's tradecraft on a non-Windows system would be highly automated and methodical, designed to disable security controls in a specific order:
Disable User-Level Tools: The attacker, having gained initial access, would first use scripts to identify and terminate any user-level security processes. They might search for known process names, then use
killallorpkillto remove them from memory.Disable MAC Policies: With user-level agents neutralized, the attacker would then escalate privileges to root and disable any active MAC policy. This is often a single command, making it a quick and effective way to remove a major barrier to their next step.
Unload Kernel Modules: Finally, with the MAC policy disabled, the attacker would use
rmmodto unload the security kernel module. The system is now fully exposed, allowing the attacker to establish persistence, exfiltrate data, and execute their full attack without a major security agent to stop them.
This automated, multi-stage process highlights the central challenge: the very tools meant to protect the system can be leveraged against themselves.
The Cyber Crucible Angle: A Call for a New Approach
Cyber Crucible has successfully replicated all of its key functionalities for Windows products on non-Windows operating systems. This includes advanced behavioral analysis, memory introspection, and real-time in-memory analysis of libraries like shared objects (the non-Windows equivalent of a Windows DLL).
We recognize that most enterprise attacks begin on Windows and then use stolen credentials to migrate to other systems, especially virtualization management portals like vCenter, Veeam, or Hyper-V. While our existing identity theft prevention capabilities largely mitigate this risk, a robust non-Windows capability would be valuable for catching insider threats or attackers who already have access to these highly sensitive administrative portals.
However, a critical conversation must be had within the non-Windows security community: the persistence issue. The fact that a security tool can simply be turned off by an attacker who gains root access is a glaring hole in risk management. Our Microsoft product is designed to be ultra-resilient and is often the last security tool running on a compromised system. We cannot, in good faith, deploy a non-Windows tool with the same expectations of resilience and dependability, knowing it can be so easily disabled.
Currently, our research and development teams are working to address this fundamental problem of persistence and build the level of resilience our customers expect. Until then, the Cyber Crucible team recommends that organizations limit access to non-Windows machines as much as possible, as no security tool can truly provide the necessary protection until this critical issue is resolved.