SUID
find / -perm -u=s -type f 2>/dev/null
Enumeration
Search for SUID files:
find / -perm -u=s -type f 2>/dev/nullMethod 1: GTFOBins
Search for SUID payloads:
For example, if /bin/systemctl is a SUID binary, use the following method to achieve arbitrary file read:
Method 2: Shared Object Injection
Suppose /usr/local/bin/suid-so is a SUID binary that calls an non-existent shared object. Use strace to examine the system calls that this binary executes:
From the output, notice that a .so file is not present in the target system and this path is from a writable directory:
The idea is to generate a privesc payload with the path /home/user/.config/libcalc.so. Save the following C code as libcalc.c:
Compile this source code to a shared object:
Execute the SUID binary in order to trigger the exploit:
And we will get a root shell.
Method 3: Binary Symlinks
Binary Symlinks is a Nginx vulnerability that abuses Nginx log permissions. If the attack succeeds, it will escalate the user privilege from www-data to root. The downside is that we have to wait until 6:25am in real life for this exploit to be triggered.
Enumerate Nginx version:
If this version of Nginx is vulnerable, download the exploit script:
Run the exploit:
This exploit will be triggered at 6:25am by default.
Method 4: Environmental Variables
Case 1: SUID binary calls relative path instead of absolute path
Suppose /usr/local/bin/suid-env is a SUID binary that executes service apache2 start. Strings it:
Note that service apache2 start is called using relative path. The idea is to forge a malicious service binary in a writable directory and add that directory to the beginning of the $PATH variable. When this SUID binary executes service apache2 start, it will execute the malicious service binary instead of the legit /usr/sbin/service.
In /tmp, create a malicious C source file:
Compile it:
Add /tmp to the beginning of the $PATH variable:
Execute the SUID binary:
Now we get a root shell.
The mitigation is use absolute path in the binary, for example, /usr/sbin/service apache2 start.
Case 2: SUID binary calls absolute path but still not good enough
Suppose /usr/local/bin/suid-env2 is a SUID binary that executes /usr/sbin/service apache2 start. Strings it:
Although this SUID binary calls the absolute path correctly, we are still able to spawn a root shell from it.
Define a shell function containing privesc payload:
Export /usr/sbin/service as environmental variable. Here -f means "refer to shell functions":
Execute the SUID binary:
Now we get a root shell.
Method 5: Text Editors (Nano, Vim, etc)
Suppose /bin/nano is SUID, then we can add a root user to the victim system. The idea is to add a new user with appropriate permissions and valid password hash to the /etc/password file.
Generate a valid hash of the password "pom":
The generated password hash is poD7u2nSiBSLk. Open /etc/passwd using Nano:
Append the following entry to /etc/passwd:
Now we can switch to the pom user who has root permissions:
Method 6: Netcat Backdoor
One way to implant a backdoor to the victim machine is making /bin/nc SUID. Then we can catch a root reverse shell by executing the following command on the victim machine:
Challenge: TryHackMe - Vulnversity
Last updated
Was this helpful?