Abusing Setuid Binaries and Capabilities
As we anticipated earlier in this Topic,
when not properly secured,
setuid binaries can lead to attacks that elevate privileges.
Before attempting the actual exploitation technique,
let’s review the purpose behind a setuid binary using a brief example.
When a user or a system-automated script launches a process,
it inherits the UID/GID of its initiating script:
this is known as the real UID/GID.
As previously discussed,
user passwords are stored as hashes within /etc/shadow,
which is owned and writable only by root
(uid 0).
How, then, can non-privileged users access this file to change their own password?
To circumvent this issue,
the effective UID/GID was introduced,
which represents the actual value being checked
when performing sensitive operations.
To better demonstrate this concept,
let’s analyze the passwd program,
which is responsible for changing the password for the user executing it.
On the Debian lab machine,
we’ll the execute the passwd command
without typing anything afterwards,
so that the process remains active in memory.
Leaving the program in standby,
let’s open another shell as joe to further inspect the process.
To find the process ID of the passwd program,
we can list all processes and filter the output based on the target name:
Interestingly, passwd is running as the root user:
this is needed for it to access and modify /etc/shadow.
We can also inspect the real UID and effective UID
assigned for the process by inspecting the proc pseudo-filesystem,
which allows us to interact with kernel information.
Using the passwd’s PID (5489) from the previous output,
let’s inspect the content at /proc/5489/status,
which provides a summary of the process attributes.
Filtering by the “Uid” keyword
returns four parameters that correspond to the real, effective,
saved set,
and filesystem UIDs.
In this case,
the Real UID value is 1000,
which is expected as it belongs to joe.
However, the other three values, including the effective UID,
equal the root’s ID 0:
let’s consider why.
Under normal circumstances,
all four values would belong to the same user who launched the executable.
For instance, this bash process for joe has all Uid values as 1000.
The passwd binary behaves differently
because the binary program has a special flag named Set- User-ID,
or SUID in short.
Let’s inspect it.
The SUID flag is depicted with the s flag in the output.
This flag can be configured using the chmod command,
and it sets the effective UID of the runni
to the executable owner’s user ID
in this case root’s.
Using this technique
results in a legitimate and constrained privilege escalation
and because of this (as we’ll learn shortly),
the SUID binary
must be bug-free to avoid any misuse of the application.
As a practical example,
once we’ve completed manual or automated enumeration,
we’ll have discovered that the find utility
is misconfigured and has the SUID flag set.
We can quickly abuse this vulnerability
by running the find program to search any well-known file,
like our own Desktop folder.
Once the file is found,
we can instruct find to perform any action through the -exec parameter.
In this case, we want to execute a bash shell
along with the Set Builtin -p parameter
that is preventing the effective user from being reset.
After running the command,
we’ve obtained a root shell
and we’ll observe that although the UID still belongs to joe,
the effective user ID is from root.
Another set of features subject to privilege escalation techniques
are Linux capabilities.
Capabilities are extra attributes that can be applied to processes,
binaries, and services
to assign specific privileges normally reserved for administrative operations,
such as traffic capturing or adding kernel modules.
Similarly to setuid binaries, if misconfigured,
these capabilities could allow an attacker to elevate their privileges to root.
To demonstrate these risks,
let’s try to manually enumerate our target system
for binaries with capabilities.
We are going to run getcap with the -r parameter
to perform a recursive search
starting from the root folder /,
filtering out any errors from the terminal output.
The two perl binaries stand out
as they have setuid capabilities enabled,
along with the +ep flag
specifying that these capabilities are effective and permitted.
In order to exploit this capability misconfiguration,
we could check the GTFOBins website.
This site provides an organized list of UNIX binaries
and how they can be misused to elevate our privileges.
Searching for “Perl” on the website,
we’ll find precise instructions for which command to use to exploit capabilities.
We’ll use the whole command,
which executes a shell along with a few POSIX directives enabling setuid.
We managed to gain a root shell via yet another misconfiguration vector.