One important aspect of ethical hacking is privilege escalation, which is often abbreviated as PrivEsc or LPE (and sometimes called Local Privilege Escalation). PrivEsc is when one user illegitimately becomes another. An attacker might try to become another user on a system or the superuser.

The escalation techniques I have learned while studying offensive security have been a real eye opener. I'd go as far to say that anyone working in the defensive security space should be trained in the various ways attackers attempt to break in. It is not always as simple as elevating permissions from a low-level user to the root user (which is referred to as vertical privilege escalation); often PrivEsc means you must first perform horizontal privilege escalation, moving from one non-root user to another. Low-level users often have subtly different privileges or different access to files or scripts that might be more hackable. Attackers move from user to user, looking for the account that offers the best opportunity for escalation.

The Wikipedia page on privilege escalation [1] sums up PrivEsc nicely: "Privilege escalation is the act of exploiting a bug, a design flaw, or a configuration oversight in an operating system or software application [...snip...]. The result is that an application with more privileges than intended by the application developer or system administrator can perform unauthorized actions."

This article will look at some of the more common routes to PrivEsc on a Linux machine. The aim is to become the root user in order to gain full control of the machine.

Cloud Matters

I'll use an AWS EC2 instance to run these tests. If you're not attacking other customers and disrupting their services, AWS permits certain types of penetration testing. As per their website [2] : "AWS customers are welcome to carry out security assessments or penetration tests of their AWS infrastructure without prior approval for the services listed in the next section under Permitted Services." Looking down through the Permitted Services, EC2 instances is the first item listed. I'm mentioning this because you might need to check with the platform that you intend to practice security on. In my case, I'm relatively confident the security assessment label applies for my testing.

So Much to Do, So Little Time

If you have studied privilege escalation even briefly, you have probably discovered that there are multiple, often extremely creative routes you can employ to become the coveted root user.

PrivEsc is often enabled by perfectly innocent, intentional functionality within an application. That functionality might include applications that permit filesystem access or even shell access from within an application itself. Or, even more innocently, when the application exits, it might not cleanly drop privileges for one reason or another.

It is no exaggeration to say that there are hundreds of ways of exploiting sudo privileges. The sudo tool [3] lets users elevate their access to run specific, granular commands without ever needing to become the root user (or other user) directly.

The first application that I'll look at is one that most people are familiar with. The package manager Advanced Packaging Tool (APT) predominantly uses the /usr/bin/apt-get binary to update package lists and upgrade applications.

I have a low-level user called chris that I'll add to the sudoers configuration file in a moment and allow chris to run apt-get without using a password. You should be aware that you commonly need to use full file paths with sudo, so I'll keep referring to /usr/bin/apt-get. I'll follow protocol (to help prevent mangling the sudoers file and accidentally locking out system users) and run this command:

$ visudo /etc/sudoers

Then I'll add this line, and save then exit the file cleanly:

chris ALL=EXEC:NOPASSWD: /usr/bin/apt-get

Now I'll check that the configuration worked by running apt-get without sudo first, as shown in Figure 1.

Figure 1: No sudo means no package updates and "Permission denied" errors.

According to the sudo manual (man sudo), changing EXEC to NOEXEC in the sudo configuration will help prevent most shell escapes. And, in the manual for the sudoers file (man sudoers), there's a section called "Preventing shell escapes" that makes for interesting reading.

Now that I've added a rule to the sudoers file, in Figure 2, I'm running the same command with sudo to see if it works. Great, no errors.

Figure 2: Running the command with sudo means that the command executes successfully.

Now for the clever bit. I'm going to run a slightly tricky looking command to offer an example of how some applications might unexpectedly permit the user to run a shell, whether intentionally or not.

Have a look at the following command:

$ sudo /usr/bin/apt-get update -o APT::Update::Pre-Invoke::=/bin/sh

I'm asking APT to invoke a command before running the update option – simple but effective. Figure 3 shows the impact of such a command, when a user has sudo access to run it.

Figure 3: Devastating results from a simple "pre-run" option.

In Figure 3, for perfect clarity, I run the whoami and id commands, showing that I'm the chris user. Then, having run the apt-get command, I run the same commands again.

This time the results are devastating to the security of a system. I've found the Holy Grail by exploiting an option in the venerable APT application. The last few lines of Figure 3 show that I am now the root user and have complete control of the AWS instance, even though I logged in as the chris user.

The next step would be simply typing the word bash to turn the sparse Bourne (sh) shell into a Bash shell. Have a look at Figure 4. I now have a very familiar-looking, colorful superuser prompt.

Figure 4: Happiness is a superuser shell.

Ready Player Two

Next I'll look at a command that some users make use of continually on Linux. The less command helps users read text files and search for patterns in text files, among other things.

On this occasion, it's worth mentioning that less often serves as the default pager on Linux machines. What that means is that applications such as the excellent APT can also be prone to issues that affect associated tools (less in this case) that are able to read files, such as an installed package's changelog. I feel a little guilty picking on APT again because this pager issue will affect many applications, but I'll look at less used directly by APT and then less on its own.

Starting with the sudoers file from the previous example, the APT command is as follows:

$ sudo /usr/bin/apt-get changelog iproute2 # Display the changelog file for "iproute2"

Figure 5 shows the output when I run that command. If you've used less, it should look very familiar.

Figure 5: The package manager is firing up less to read a changelog file.

In Figure 5, you see a changelog file's contents and a highlighted prompt at the bottom. Users can type directly into that screen without entering anything else. In Figure 6, you see what happens when I simply type !/bin/sh.

Figure 6: Look! I see the root user again.

Figure 6 shows that I've gone from viewing an innocent iproute2 changelog to gaining root user access with just a few keystrokes.

To escalate privileges with the less utility directly, I need to alter the sudoers file, firstly checking the full path of the binary:

$ whereis less

Now I can adjust the /etc/sudoers file:

chris ALL=EXEC:NOPASSWD: /usr/bin/less

What can I do now? Try this command:

$ sudo less /etc/resolv.conf

In Figure 7, I am opening the DNS configuration file resolv.conf via sudo. Can I achieve PrivEsc via the same approach but with !/bin/bash instead of !/bin/sh for a more complete prompt?

Figure 7: The resolv.conf file.

Figure 8 shows the results of typing !/bin/bash. In glorious Technicolor, I now have root user access, courtesy of the less command.

Figure 8: I've done it again. The superuser is shown.