Introduction
In Linux systems, the sudo command allows standard users to execute programs with the security privileges of another user, typically the root administrator. System administrators often configure the /etc/sudoers file to allow specific users to run certain commands as root without requiring a password. This is usually done for convenience, such as allowing a developer to restart a web server or search for files system-wide.
The security lesson here is that sudo rules are really delegated trust. If the delegated binary is more powerful than the administrator realizes, the rule may effectively grant a shell rather than just one safe action.
However, these well-intentioned administrative shortcuts can introduce severe security vulnerabilities. If a user is allowed to run a binary that has the ability to execute other commands or spawn a shell (like find, vim, or awk), an attacker can abuse this permission to break out of the restricted command and gain a full root shell. This technique is commonly referred to as a "shell escape" or "GTFOBins" exploit.
In this lab, you will step into the shoes of a security auditor. You will enumerate your current user's sudo permissions, identify a misconfigured authorized binary, and exploit it to escalate your privileges to root.
Check Sudo Permissions (sudo -l)
In this step, you will learn how to enumerate the sudo privileges assigned to your current user account.
When assessing a Linux system for privilege escalation opportunities, one of the first checks is to see what commands the current user can run as root. The sudo command provides a built-in flag, -l (list), which displays the allowed and forbidden commands for the invoking user.
This is a high-priority check because sudo misconfigurations can provide direct, low-friction escalation with very little guesswork.
To keep a record of our findings, we will redirect the output of this command into a text file within our project directory.
Run the following command to list your sudo privileges and save the output to a file named sudo_privs.txt:
sudo -l > /home/labex/project/sudo_privs.txt
Now, let's view the contents of the file you just created to analyze the permissions:
cat /home/labex/project/sudo_privs.txt
You should see an output similar to the following:
Matching Defaults entries for labex on this host:
env_reset, mail_badpass, secure_path=/usr/local/sbin\:/usr/local/bin\:/usr/sbin\:/usr/bin\:/sbin\:/bin\:/snap/bin
User labex may run the following commands on this host:
(root) NOPASSWD: /usr/bin/find
Some environments may show extra sudo entries in addition to the find rule. For this lab, focus on the line that explicitly allows labex to run /usr/bin/find as root without providing a password (NOPASSWD). That specific configuration is what we will target in the upcoming steps.
Analyze Allowed Binaries for Shell Escapes
In this step, you will analyze the /usr/bin/find binary to understand how it can be abused to execute arbitrary commands.
The find command is a powerful utility used to search for files and directories in a directory hierarchy. However, it includes a highly flexible parameter called -exec. The -exec flag allows the user to execute a specified command on every file that find locates.
The problem is not that find is malicious. The problem is that it is expressive. Any expressive root-capable binary is a candidate for shell escape if not tightly constrained.
The critical security flaw arises when find is executed with sudo. If find is running as root, any command passed to the -exec parameter will also be executed as root.
Let's test this theory by using the -exec parameter to run the whoami command. The whoami command simply prints the effective username of the current user. We will redirect the output to a file to verify our execution context.
Execute the following command:
sudo find . -exec whoami \; -quit > /home/labex/project/whoami.txt
Let's break down this command. The sudo find . portion runs the find command as root, starting the search in the current directory (.). The -exec whoami \; segment tells find to execute the whoami command, where the \; is required to terminate the -exec statement. Finally, the -quit flag instructs find to exit immediately after processing the first match, which prevents it from running whoami multiple times for every file in the directory.
Now, check the contents of the output file:
cat /home/labex/project/whoami.txt
You should see the following output:
root
This confirms that the command passed to -exec was successfully executed with root privileges.
Execute Binary with Sudo
In this step, you will leverage the -exec vulnerability to access sensitive system files that are normally restricted to the root user.
One of the most sensitive files on a Linux system is /etc/shadow. This file contains the encrypted password hashes for all user accounts on the system. Standard users do not have read permissions for this file. If an attacker can read this file, they can attempt to crack the password hashes offline.
Since we have proven that we can execute arbitrary commands as root using sudo find, we can use this technique to read the contents of /etc/shadow.
We will use the head command within our -exec statement to read just the first line of the shadow file (which typically contains the root user's hash) and save it to our project directory.
Run the following command:
sudo find /etc/shadow -exec head -n 1 {} \; -quit > /home/labex/project/shadow_head.txt
In this command, the {} acts as a placeholder that find replaces with the name of the file it is currently processing (in this case, /etc/shadow).
Verify that you successfully extracted the sensitive information by reading the output file:
cat /home/labex/project/shadow_head.txt
You should see an output similar to this, displaying the root user's entry from the shadow file:
root:*:19711:0:99999:7:::
You have successfully bypassed file system permissions by abusing the misconfigured sudo entry.
Spawn Root Shell
In this step, you will take the final action to achieve complete system compromise by spawning a root shell.
While reading sensitive files is dangerous, the ultimate goal of privilege escalation is to obtain an interactive shell running as root. This grants the attacker unrestricted access to the entire system.
To achieve this, instead of passing a simple command like whoami or head to the -exec parameter, we can pass the path to a shell executable, such as /bin/bash.
In a real-world scenario, an attacker would run sudo find . -exec /bin/bash \; -quit to drop directly into an interactive root terminal. However, for the purpose of this automated lab environment, dropping into an interactive shell would pause the lab execution.
Instead, we will spawn a root bash shell in non-interactive mode using the -c flag. This allows us to pass a command directly to the new root shell, execute it, and save the proof of our complete system compromise. We will use the id command, which provides detailed information about the current user's identity and group memberships.
Execute the following command to spawn a root shell and record your identity:
sudo find . -exec /bin/bash -c "id > /home/labex/project/pwned.txt" \; -quit
Finally, read the pwned.txt file to verify your ultimate privilege escalation:
cat /home/labex/project/pwned.txt
The output should clearly show that the shell was running with root user and group IDs:
uid=0(root) gid=0(root) groups=0(root)
Congratulations! You have successfully exploited a misconfigured sudoers file to escalate your privileges from a standard user to root.
Summary
In this lab, you explored the security risks associated with misconfigured sudoers files in Linux environments. You started by enumerating the sudo privileges of your user account and identified that the find binary could be executed as root without a password. By understanding the functionality of the find command's -exec parameter, you were able to execute arbitrary commands with root privileges. You demonstrated the impact of this vulnerability by reading restricted system files and ultimately spawning a root shell to achieve complete system compromise. This exercise highlights the importance of adhering to the principle of least privilege and carefully auditing sudo configurations to prevent unauthorized privilege escalation.
