Full Report
Willems and I are currently on an internal assessment and have popped a couple hundred (thousand?) RHEL machines, which was trivial since they are all imaged. Anyhoo – long story short, we have a user which is allowed to make use of sudo for a few commands, such as reboot and service. I immediately thought it would be nice to turn this into a local root somehow. Service seemed promising and I had a looksy how it works. Whilst it does do sanitation of the library path it does not remove LD_PRELOAD. So if we could sneak LD_PRELOAD past sudo then all should be good ?
Analysis Summary
# Tool/Technique: LD\_PRELOAD Bypass via Sudo
## Overview
This summary details a technique used to achieve local root privileges on RHEL systems by leveraging the `LD_PRELOAD` environment variable in conjunction with the `sudo` command, specifically when `sudo` configuration (like `Defaults env_reset` or `Defaults setenv`) does not properly sanitize the environment variables used by invoked commands (like `service`).
## Technical Details
- Type: Technique
- Platform: Linux (RHEL is specifically mentioned)
- Capabilities: Privilege escalation from a limited user to root by injecting a shared object (`.so` file) into the address space of a command executed via `sudo`.
- First Seen: The technique is an older vulnerability, with a specific exploit example attributed to Kingcope dating back to 2008. The analyst discovered this in 2013.
## MITRE ATT&CK Mapping
- T1548 - Abuse Elevation Control Mechanism
- T1548.003 - Sudo and Sudo Cfg
- T1055 - Process Injection
- T1055.001 - Dynamic-link Library Injection (This technique achieves a similar effect to DLL injection by controlling library loading during process startup via `LD_PRELOAD`.)
## Functionality
### Core Capabilities
- **Environment Variable Leakage (LD\_PRELOAD):** Exploiting configurations where `sudo` fails to fully reset the environment, allowing the attacker-controlled `LD_PRELOAD` variable to persist.
- **Shared Object Injection:** Loading a malicious shared object (`.so`) before standard system libraries when the target command (e.g., `service`) is executed.
- **Function Hooking:** The injected library overrides standard C library functions (like `fopen` in the analyst's example) to execute custom code.
- **Privilege Escalation:** The custom code within the injected library executes commands with the privileges of the target executable (root, in this case, when called via `sudo`).
### Advanced Features
- **Self-Destruct Mechanism (Kingcope's Exploit):** Kingcope's exploit includes code within the `_init()` function of the shared object to automatically `unsetenv("LD_PRELOAD")`, grant root privileges (`setuid(0)`, `setgid(0)`), and clean up the temporary `.so` and `.c` files after execution, making the artifact less traceable.
- **Trigger Condition:** The analyst's initial custom exploit relied on filesystem triggers (e.g., successfully creating `/tmp/sandwich`) to execute `/bin/bash`.
## Indicators of Compromise
- File Hashes: N/A (Code examples provided, not deployed binaries)
- File Names: `myfopen.so` (Analyst's custom payload), `/tmp/sandwich`, `/tmp/sandwich.so`, `/tmp/sandwich.c` (Kingcope's example artifacts)
- Registry Keys: N/A
- Network Indicators: N/A (Focus is local privilege escalation)
- Behavioral Indicators:
- Execution of `sudo` commands where the environment variable `LD_PRELOAD` is explicitly passed in the command line or is present and preserved in the environment.
- Creation and execution of unusual shared objects (`.so` files) in temporary directories.
- System calls within services (like `ssh` restart) that interact unexpectedly with the filesystem or spawn shells.
## Associated Threat Actors
- The technique is often associated with penetration testers and exploit developers. The article specifically references an elegant 2008 exploit written by **Kingcope**.
## Detection Methods
- **Signature-based detection:** Specific YARA or static analysis rules looking for known privilege escalation code patterns within shared objects that execute `setuid(0)` or spawn shells.
- **Behavioral detection:** Monitoring system calls from legitimate processes started via `sudo` (like init scripts) that exhibit unusual behavior, such as attempting to write to sensitive areas or launching interactive shells (`/bin/bash`).
- **Configuration Auditing:** Regularly auditing `/etc/sudoers` for configurations that deviate from security standards, particularly the absence of `Defaults env_reset`.
## Mitigation Strategies
- **Sudo Configuration Hardening:** Ensure the `/etc/sudoers` file explicitly includes `Defaults env_reset` to strip unnecessary environment variables, including `LD_PRELOAD`, before executing commands.
- **Selective Environment Preservation:** If environment variables must be preserved, use `Defaults setenv` combined with explicit whitelisting of only necessary variables, ensuring `LD_PRELOAD` is not included.
- **Principle of Least Privilege:** Minimize the commands users are allowed to run via `sudo`. If only specific actions are needed (like service control), ensure the underlying binaries are secure and do not rely on environment modification for execution paths.
- **Secure Application Building:** Ensure that binaries executed via `sudo` do not rely on potentially manipulable library paths or default environment settings for core functionality.
## Related Tools/Techniques
- **LD\_PRELOAD Abuse:** A broad technique used for hijacking library functions.
- **Environment Variable Abuse:** General exploitation of un-sanitized environment variables (e.g., `PATH`, `LD_LIBRARY_PATH`).
- **Library Planting/Hijacking:** Similar techniques used on Windows (DLL Search Order Hijacking) or other platforms.