Understanding privilege escalation
Shape Shifter
Even a small configuration error or oversight can create an opening for privilege escalation. These real-world escalation techniques will help you understand what to watch for.
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.
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.
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.
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.
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.
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 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 8 shows the results of typing !/bin/bash
. In glorious Technicolor, I now have root user access, courtesy of the less
command.
Buy this article as PDF
(incl. VAT)
Buy Linux Magazine
Subscribe to our Linux Newsletters
Find Linux and Open Source Jobs
Subscribe to our ADMIN Newsletters
Support Our Work
Linux Magazine content is made possible with support from readers like you. Please consider contributing when you’ve found an article to be beneficial.
News
-
ESET Discovers New Linux Malware
WolfsBane is an all-in-one malware that has hit the Linux operating system and includes a dropper, a launcher, and a backdoor.
-
New Linux Kernel Patch Allows Forcing a CPU Mitigation
Even when CPU mitigations can consume precious CPU cycles, it might not be a bad idea to allow users to enable them, even if your machine isn't vulnerable.
-
Red Hat Enterprise Linux 9.5 Released
Notify your friends, loved ones, and colleagues that the latest version of RHEL is available with plenty of enhancements.
-
Linux Sees Massive Performance Increase from a Single Line of Code
With one line of code, Intel was able to increase the performance of the Linux kernel by 4,000 percent.
-
Fedora KDE Approved as an Official Spin
If you prefer the Plasma desktop environment and the Fedora distribution, you're in luck because there's now an official spin that is listed on the same level as the Fedora Workstation edition.
-
New Steam Client Ups the Ante for Linux
The latest release from Steam has some pretty cool tricks up its sleeve.
-
Gnome OS Transitioning Toward a General-Purpose Distro
If you're looking for the perfectly vanilla take on the Gnome desktop, Gnome OS might be for you.
-
Fedora 41 Released with New Features
If you're a Fedora fan or just looking for a Linux distribution to help you migrate from Windows, Fedora 41 might be just the ticket.
-
AlmaLinux OS Kitten 10 Gives Power Users a Sneak Preview
If you're looking to kick the tires of AlmaLinux's upstream version, the developers have a purrfect solution.
-
Gnome 47.1 Released with a Few Fixes
The latest release of the Gnome desktop is all about fixing a few nagging issues and not about bringing new features into the mix.