LEVELING UP

Practical Linux Privilege Escalation: Hunting SUID Binaries and Capabilities

Advertisement

You’ve gained an initial foothold on a Linux machine through a web vulnerability or compromised low-privilege credentials. Your shell is running as www-data or an unprivileged user like nobody. The initial access phase is over—now your target is full root control.

While kernel exploits are flashy, they are risky, unstable, and often crash production systems. Red teams and attackers usually start with a much cleaner path: local misconfigurations. Among the most reliable avenues for Linux privilege escalation are misconfigured SUID binaries and Linux Capabilities.

In this post, we’ll break down how these mechanisms work, how to hunt for vulnerabilities, and how to turn misconfigurations into root shells.

Understanding the SUID Bit (And How It Fails)

In standard Linux file permissions, a binary executes with the permissions of the user who runs it. If user alice runs /usr/bin/python3, the process executes under alice’s UID.

However, some applications need temporary elevated privileges to perform system tasks. For example, the passwd command must write to /etc/shadow, a file owned strictly by root. To solve this, Linux uses the SUID (Set Owner User ID up on execution) permission bit.

When a binary has the SUID bit set, it runs with the permissions of the file’s owner (typically root), regardless of who executes it.

Permission string with SUID: [code block] Notice the s in the owner’s execution spot (rws). This indicates SUID is enabled.

The security risk arises when developers or sysadmins set the SUID bit on binaries that allow arbitrary file reading, writing, or command execution (such as find, vim, or custom bash wrappers). If a user can control what a SUID binary processes, they control root-level execution.

Hunting Down Dangerous SUID Binaries

When landing on a target system, your first step should be enumerating all SUID files owned by root. You can do this with standard Unix tools without uploading extra binaries.

Run the following find command:

[code block]

Let’s break down this command:

  • /: Starts searching from the root directory.
  • -perm -4000: Filters specifically for files with the SUID bit set.
  • -type f: Searches only for regular files (ignoring directories or sockets).
  • -user root: Filters for files owned by root.
  • 2>/dev/null: Redirects standard error (permission denied messages) to oblivion so your output remains clean.

Analyzing the Output

Standard systems will return expected binaries like /usr/bin/sudo, /usr/bin/passwd, /usr/bin/mount, and /usr/bin/newgrp. These are standard operating system components.

Look for anomalies:

  1. Non-standard system utilities (e.g., find, cp, python, bash, nmap).
  2. Custom scripts or compiled C binaries inside /opt, /tmp, /var/tmp, or custom home directories.
  3. Outdated versions of legitimate utilities.

The GTFOBins Methodology

If you discover a non-standard SUID binary, you don’t need to reinvent the wheel. The security community maintains GTFOBins, a curated library of Unix binaries that can be abused to bypass local security restrictions.

Suppose your enumeration returned /usr/bin/find with the SUID bit set:

[code block]

Because find includes an -exec flag to run shell commands on search results, executing it while it carries the SUID bit will execute commands as root.

To escalate privileges, run:

[code block]

Note: The -p flag in /bin/sh tells the shell not to reset effective user privileges back to the invoking user.

Similarly, if env has SUID permissions:

[code block]

Both commands immediately grant an interactive shell with real and effective UID set to 0 (root).

Beyond SUID: Modern Privilege Escalation via Linux Capabilities

As systems evolved, security engineers realized SUID was a blunt instrument. Granting full root permissions to an entire binary just to let it open a low-numbered network port (like port 80) violates the Principle of Least Privilege.

Linux kernel 2.2 introduced Linux Capabilities to break down root privileges into distinct, granular permissions. Instead of making a binary full root via SUID, admins can assign only the exact capability the binary needs.

Common capabilities include:

  • CAP_NET_BIND_SERVICE: Allows binding to sockets under port 1024.
  • CAP_NET_RAW: Allows raw network packets (used by ping and packet sniffers).
  • CAP_DAC_READ_SEARCH: Bypasses file read permission checks and directory read/execute checks.
  • CAP_SETUID: Allows changing the process User ID (UID).
  • CAP_SYS_ADMIN: The ultimate capability—provides extensive system administration operations (essentially root light).

If capabilities are improperly configured on an executable, it introduces privilege escalation vectors similar to SUID, but often overlooked by automated auditing scripts.

Enumerating and Exploiting Capabilities

To search for binaries with assigned capabilities across the filesystem, use getcap:

[code block]

  • -r: Recursively scan directories.
  • 2>/dev/null: Suppress permission errors.

Scenario 1: Abusing CAP_SETUID on Python

Suppose getcap returns the following:

[code block]

Here, the +ep flags mean the capability is Effective and Permitted.

Because Python possesses CAP_SETUID, we can write a single-line command instructing Python to change its effective UID to 0 (root) and spawn a shell:

[code block]

Since os.setuid(0) succeeds due to CAP_SETUID, os.system launches a root shell.

If a binary or language interpreter like tar or python has cap_dac_read_search, file permission checks are bypassed entirely.

For instance, to read /etc/shadow using a compromised Python binary with this capability:

[code block]

With the contents of /etc/shadow in hand, you can extract password hashes and crack them offline using John the Ripper or Hashcat.

Remediation and Securing Your System

If you are managing servers or securing systems, finding and eliminating unsafe SUID and capability misconfigurations is straightforward:

  1. Audit SUIDs regularly: Remove unnecessary SUID bits on binaries using chmod: [code block]
  2. Use Partition Mount Options: Mount writeable partitions where users upload files (like /tmp, /var/tmp, /dev/shm) with the nosuid flag in /etc/fstab: [code block]
  3. Audit Capabilities: Check binary capabilities regularly using getcap and remove unneeded privileges using setcap: [code block]

Summary

Privilege escalation is often about finding the deliberate shortcuts left behind by administrative convenience. The next time you land a shell on a Linux box, bypass complex exploits and check file permissions first. Run your find for SUID binaries and getcap for capabilities. The path to root is frequently sitting right in front of you.

Photo by Florian Olivo on Unsplash.