Full Report
Security Enhanced Linux (SELinux) is an added layer of security to the OS kernel. Using it, access controls can be put on applications, processes and file on a system. Just because you have root doesn't mean you've won with SELinux. The author of this post had a reverse shell on the box but had some serious restrictions in place that prevented exploitation. SELinux tools like getenforce were removed as well. The SELinux is just a list of rules for the processes other actions that can occur. What if we could load a kernel module? The call init_module was restricted but finit_module was not! They are the same exact call except one takes in a file and the other takes in a file descriptor. Calling finit_module allows the author to get into the kernel and disable SELinux. They had to write a custom loader for this though, which is interesting. Overall, an interesting bypass for SELinux.
Analysis Summary
# Tool/Technique: SELinux Bypass via `finit_module` System Call
## Overview
This technique details a method discovered for bypassing Security Enhanced Linux (SELinux) restrictions, typically enforced through filesystem or process-level access controls, by exploiting a difference between two system calls responsible for loading kernel modules: `init_module` and `finit_module`. While `init_module` was restricted by SELinux policy, the less common `finit_module` was not audited in the specific environment, allowing the attacker to gain kernel execution space and subsequently disable SELinux enforcement.
## Technical Details
- Type: Technique
- Platform: Linux (Targeting systems with SELinux enforced, specifically observed on an ARM-based device)
- Capabilities: Evading SELinux restrictions, achieving kernel execution space, and disabling SELinux policy enforcement.
- First Seen: The technique was documented and publicized on May 26, 2023.
## MITRE ATT&CK Mapping
- TA0004 - Privilege Escalation
- T1548.002 - Abuse Elevation Control Mechanism: Bypass User Account Control/System Settings (Leveraging the difference between kernel module loading interfaces to bypass defined policy)
- T1055 - Process Injection (Implied, as loading a module injects attacker code into kernel space)
- TA0005 - Defense Evasion
- T1027 - Obfuscated Files or Information (Using metadata/system call differences to bypass restrictions)
## Functionality
### Core Capabilities
- **Kernel Module Loading:** The primary goal is to load a custom kernel module into the running system.
- **Bypassing `init_module` Restrictions:** Successfully avoids SELinux AVC denial typically applied to the standard `init_module` mechanism (often invoked by tools like `insmod`) via filesystem/context rules.
- **Leveraging `finit_module`:** Utilizes the `finit_module(int fd, ...)` system call, which loads a module from a file descriptor, instead of `init_module(void* module_image, ...)`, which loads from a memory address (or uses a different set of policy checks in this context).
### Advanced Features
- **Custom Loader Development:** Required the development of a custom loader program (written in user-space, likely compiled on the target or cross-compiled) capable of invoking `finit_module` correctly, as standard tools might have been unavailable or restricted.
- **SELinux Disablement:** After gaining kernel execution via the loaded module, the author executed code *within the kernel* to disable SELinux enforcement, significantly reducing restrictions on subsequent post-exploitation activities. (The context implies the custom module contained the logic to disable SELinux.)
- **Tool Removal Evasion:** Exploited the omission of standard SELinux management tools (`getenforce`, `setenforce`, etc.) on the target system by achieving kernel execution as an alternate path to policy manipulation.
## Indicators of Compromise
- File Hashes: N/A (Custom POC artifacts, not part of established malware)
- File Names: `/tmp/dummy.ko` (Example kernel object file used in the PoC)
- Registry Keys: N/A (Linux-based system)
- Network Indicators: N/A (Focus is local privilege escalation and kernel manipulation)
- Behavioral Indicators:
* Unsuccessful attempts or audit logs showing AVC denials for `insmod` or direct writes to `/sys/fs/selinux/enforce`.
* Successful execution of an attempt to load a kernel module via the `finit_module` system call from a user-space process.
* Addition of a new, unknown kernel module to the running system.
* System logs (`dmesg`/audit logs) indicating a change in SELinux enforcement state (e.g., transition from enforcing to permissive, or explicit SELinux service disabling functions called from kernel space).
## Associated Threat Actors
- Not associated with a named threat actor; this appears to be independent research by Sean Pesce targeting an undisclosed Linux-based device.
## Detection Methods
- Signature-based detection: Signatures for the specific custom kernel module binary (`.ko`) if it were distributed.
- Behavioral detection: Monitoring for the execution of the `finit_module` system call by non-standard processes, especially after the process gains initial user-space access (like the reverse shell).
- YARA rules if available: Not provided in the context.
- **Audit Log Analysis:** Closely monitor Linux Audit logs for `module_load` attempts using `finit_module` context, or monitoring for attempts to disable security features from kernel context.
## Mitigation Strategies
- **Kernel Hardening:** Ensure kernel configurations are built to restrict module loading even via system calls like `finit_module`. Verify SELinux policies are correctly configured to restrict access to the target system call if possible, or ensure the initial compromised context (`scontext`) is highly restricted.
- **Restrict Write Capabilities:** Limit write/execute capabilities in temporary locations like `/tmp/`.
- **Module Signing and Verification:** Implement module signature enforcement if supported by the kernel configuration to prevent unauthorized modules from loading, regardless of the loading mechanism used.
- **Principle of Least Privilege:** Ensure the process that initially gains access does not run with capabilities that allow invoking module loading APIs, even if standard tools like `insmod` are missing.
- **SELinux Strict Mode:** Running systems in strict enforcing mode with comprehensive logging for any attempted policy violations.
## Related Tools/Techniques
- `insmod`: The standard command-line utility that often utilizes `init_module`.
- Default SELinux Evasion Techniques: Bypassing controls by leveraging alternative system interfaces or deprecated functions.
- Standard Linux Privilege Escalation Techniques: Any method used to gain initial root access on the target system prior to this bypass.