Linux Access Rights for Beginners: Base Before Attack
Before you break, you need to understand how the protection is arranged. In Linux, each file and directory has three rights groups: the owner (user), the group (group), the rest (others). Each group receives a combination of three permissions: reading (r = 4), recording (w = 2), execution (x = 1). More details in our linux guide for the pentester.
When in the conclusion ls -la You see a line like -rwxr-xr-x, read from left to right: the owner can all (rwx = 7), group - read and perform (r-x = 5), the rest - too (r-x = 5). In the numerical format — 755. Team chmod 755 file sets these linux file permissions.
But standard rwx for understanding privesc vectors is not enough. There is a fourth, senior level in the chmod numerical record of access rights — it is responsible for special bits: SUID (4), SGID (2) and sticky bit (1). Recording chmod 4755 file means: SUID included (4), owner of rwx (7), group r-x (5), other r-x (5). It is these special bits that turn the usual binary into the attack vector when the configuration curve.
File /etc/passwd read by all (rights 644), and /etc/shadow with password hashes, only root. This difference is the foundation of Linux security, and every privesc vector essentially bypasses this foundation in one way or another.
SUID bit Linux – when the program gets other people’s rights
SUID (Set User ID) is a mechanism in which the program is launched not with the rights of the person who caused it, but with the rights of the owner of the file. Analogy: you — the usual employee — gave the director’s key card, but it only works while you are inside one particular cabinet. Included – the authority of the director. Out is a regular employee again.
A classic legitimate example — /usr/bin/passwd. The program should change the file /etc/shadow, which reads only root. Without SUID, the average user would not be able to change their own password. With SUID, the program is run on root name, makes a change and ends. It's safe because passwd does one specific operation.
The problem appears when the admin puts SUID on a binary capable of performing arbitrary commands. find, vim, python, bash – each of them, in the presence of a SUID-bit, becomes a straight road to root shell. In MITRE ATT&CK terminology, the abuse of SUID/SGID is classified as Technique Setuid and Setgid (T1548.001, Privilege Escalation). The attacker finds misconfigured binaries exploitation and uses the full-time capabilities of the program to increase privileges.
What does SUID look like in the system and a trap with the title S
You can install SUID in two ways: symbolic chmod u+s file or numerical chmod 4755 file. In the numerical record, the fourth in the senior category is SUID. After installation in the output ls -la position x the owner is replaced by s:
-rwsr-xr-x – SUID is installed, execution is allowed (line s). Binarnick will start on behalf of the owner.
-rwSr-xr-x – SUID is installed, but performance is NOT allowed (capital S). The file cannot be started, operation via SUID is excluded.
Difference between s and S The trap I fell for twice. Capital S means that someone has put SUID without a execution right—usually a configuration error, not an attack vector. Don't waste time on these files when exploration.
SGID Access Rights – SUID Group Analog
SGID (Set Group ID) works similarly to SUID, but for the owner group. When SGID is installed on the executable file, the process is triggered with the rights of the file owner group, not with the group of the launch user.
Installation: chmod g+s file or chmod 2755 file. In the conclusion ls -la position x in triplet group is replaced by s: -rwxr-sr-x. Vulnerable SGID binarys give the attacker not root, but a membership in the target group — and if that group has access to sensitive files (e.g., a group shadow can read /etc/shadow), it is a full vector of escalation.
SGID on directories is a very different behavior
On the SGID directories behaves fundamentally differently: all new files created within the SGID-directory inherit a group of directories, and not the main group of the creator. It is used for command directories where multiple users need group sharing.
For escalating the privileges of CTF SGID on directories is less interesting as a direct vector. But in real pentests, the SGID directory contains a config with passwords, available only to a certain group – and obtaining membership in this group through SGID-binary opens access to credenshels. A chain of two steps instead of one.
Sticky bit Linux – protection of general directories
Sticky bit is the least “attacking” of three special bits, but you need to understand it for the full picture of pwn linux permissions. Installed on directories: chmod +t dir or chmod 1777 dir.
Effect: In the directory with sticky bit, the user can only delete their files, even if the directory has rights 777 (full access for all). Canonical example — /tmp. Without sticky bit, any user could delete other people's files from /tmp, breaking a bunch of system processes.
In the conclusion ls -ld /tmp sticky bit is marked with a letter t in position x for others: drwxrwxrwt. Capital T – sticky bit is, but there is no screen for others (similar to the capital S for SUID).
For escalation of privileges sticky bit itself is not a vector. But here’s what’s critical to practice: if the file system is mounted with an option nosuid, then SUID/SGID bits on files inside it the kernel simply ignores. This is standard practice for /tmp, /dev/shm, /run. Beginners regularly stumble on this: copy the binary in /tmp, put SUID through chmod u+s — and nothing works because the section is mounted with nosuid. Check: grep nosuid /proc/mounts.
Search for Linux SUID files – exploration before operation
Intelligence is the foundation of any privileged access. According to MITRE ATT&CK, file and directory detection is File and Directory Discovery (T1083, Discovery). In practice, it all comes down to several teams.
Manual search SUID via find
Basic team – learn by heart:
find / -perm -4000 -type f 2>/dev/null
find / -perm -2000 -type f 2>/dev/null
find / -perm -u=s -o -perm -g=s -type f 2>/dev/null
Let's look at the parts: / Search from the root. -perm -4000 – files with SUID installed (4 in the senior category). -type f – only ordinary files, not directories and not symbols. 2>/dev/null – redirecting “Permission neza” errors into a void so as not to clog the output.
On typical Ubuntu 22.04 the conclusion will show a dozen-two standard binary: /usr/bin/passwd, /usr/bin/su, /usr/bin/sudo, /usr/bin/mount, /usr/bin/umount. All are legitimate and expected. The binary is of interest, which should not be on this list: find, vim, python3, bash, cp, nano, docker.
CTF reception: to cut off standard binary and find only added later, use find / -xdev -perm -4000 -newer /bin/bash 2>/dev/null. Flag -newer show files modified later /bin/bash – that is, added after installation of the system. Flag -xdev does not allow you to switch to other file systems.
Automation: LinPEAS and privilege scanners
Manual search is a base, but on the CTF time is expensive. LinPEAS (Linux Privilege Escalation Awesome Script) automatically checks dozens of privilege vectors, including SUID/SGID. Download the script, do it chmod +x linpeas.sh && ./linpeas.sh. LinPEAS highlights potentially vulnerable SUID binary red and yellow, giving instant prioritization.
There is also a specialized tool – suid3num. It categorizes the found SUID files into standard (expected for distribution) and non-standard (potentially vulnerable), plus automatically checks them on the basis of GTFOBins. The tool groups binary in the category "default", "not default" and "custom" - greatly accelerates the analysis.
But no automatic scanner covers – custom binary. CTFs often come across compiled programs without names from GTFOBins. Here only manual analysis helps: strings binary_name show string constants, ltrace ./binary_name – challenges of library functions. If in the conclusion strings See a challenge like system("tar") or system("ls") without an absolute path is an almost guaranteed vector through PATH hijacking.
GTFOBins examples — a catalog of vulnerable SUIDs of binary
GTFOBins (gtfobins.github.io) is a directory of standard Unix utilities that can be used to bypass security restrictions. For each binary, the operating techniques are specified in different contexts: SUID, sudo, capabilities, reading/writing files.
The algorithm of working with GTFOBins on CTF is five steps:
Found a non-standard SUID binary through find.
Opening GTFOBins, looking for a binary by name.
Go to the SUID section on its page.
Copy the command, adapt the way for a particular machine.
Get root shell.
Binary, which are most commonly found in labs and CTFs:
find One of the most popular. If at find It is worth SUID, enough to perform find . -exec /bin/sh -p \; -quit. Parameter -exec launches an arbitrary team, -p saves effective UID, -quit completes the find after the first match. The result is root-hell.
bash – if on /bin/bash is worth SUID (in reality it is crazy, but in CTF happens), the team bash -p launches the shell with the owner's rights. Flag -p disables the reset of privileges that bash makes by default – without it, SUID on bash is useless.
python3 – with SUID allows you to perform python3 -c 'import os; os.execl("/bin/sh", "sh", "-p")'. The interpreter is started from root, generates shells with preserved privileges.
vim/nano – text editors with SUID make it possible to edit any file from root. Through vim can open /etc/passwd or /etc/sudoers and add a user with UID 0 or a NOPASSWD record for sudo.
cp – there are three methods of operation of SUID: copying the substituted /etc/passwd, cloning SUID-bit on another binary and modification /etc/sudoers. Every worker when the copying utility has a misconfigured SUID.
The full list of binary with SUID-operation techniques on GTFOBins contains dozens of positions: from aa-exec and arp to awk, gdb and docker. You don’t need to remember everything – you need to remember where to look.
CTF Escalation of privileges – step-by-step scenarios
The theory without practice is dead. Three scenarios covering the main SUID-exploitation patterns.
Scenario 1: straight SUID on standard binary
Situation: received user-hell, intelligence through find / -perm -4000 -type f 2>/dev/null shows in the list /usr/bin/find with rights -rwsr-xr-x 1 root root.
What it means: find executed on behalf of root (SUID-bit installed, owner – root). U find has a parameter -exec, performing an arbitrary command for each file found.
Operation: find . -exec /bin/sh -p \; -quit. Check: id in the opened shell will show uid=0(root). Time from detection to root - 10 seconds.
On GTFOBins page find in the SUID section contains the same command — vector confirmation.
Scenario 2: PATH hijacking through custom binary
Situation: a non-standard binary was found during exploration /opt/backup with rights -rwsr-xr-x 1 root root. Team strings /opt/backup shows the challenge system("tar czf /tmp/backup.tar.gz /home").
What's the hole: the binary causes tar without an absolute path (not /usr/bin/tar, but simply tar). The system is looking for tar by the PATH environment variable, going the directories from left to right. Put your fake tar the directory that in PATH is standing earlier /usr/bin – and the binary will perform our substitution with root rights.
echo '#!/bin/sh' > /tmp/tar
echo '/bin/sh -p' >> /tmp/tar
chmod +x /tmp/tar
export PATH=/tmp:$PATH
/opt/backup
Result: instead of tar Our script is called, which opens the shell with root privileges. In terms of MITRE ATT&CK, it is the intersection of the Setuid and Setgid (T1548.001) techniques and the manipulation of the execution environment.
A similar focus works with anyone system() without the absolute path. On one CTF SUID-binary welcome called the file greetings along the relative path – the attacker replaced him with a symbol on the /bin/sh and got root.
Scenario 3: SUID on text editor
Situation: intelligence shows /usr/bin/vim.tiny with SUID root.
Logic: vim with root rights can edit any file in the system. The two main vectors:
Through /etc/sudoers: open vim.tiny /etc/sudoers, add a line username ALL=(ALL) NOPASSWD: ALL, save through :wq!. After that sudo su gives root without a password.
Through /etc/passwd: generate password hash through openssl passwd -6 -salt xyz yourpassword, then in vim add to /etc/passwd line with UID 0 — a new user with root rights. Option: replace the hash root in /etc/shadow through find with -exec sed, if find has SUID.
Both options require an understanding of the system file format. Each field in /etc/passwd divided by colon – the third field (UID) determines the level of privilege. UID 0 – root.
Linux privesc checklist for CTF and Labs
A systematic approach saves time. The order of action after receiving a user-hell, built in the probability of triggering in the CTF:
id and whoami. Check out the groups: membership docker, lxd or disk – independent escalation vectors not related to SUID.
sudo -l – what commands can be executed via sudo without a password? Often the fastest vector, faster than SUID.
find / -perm -4000 -type f 2>/dev/null and separately -perm -2000. Compare with the default set, allocate non-standard.
cat /etc/crontab and ls -la /etc/cron.d/. Look for scripts running root but available on the record to the current user.
getcap -r / 2>/dev/null. Linux capabilities is a more granular alternative to SUID (capabilities linux security). Binarnick with cap_setuid+ep equivalent to SUID root in terms of privesc.
find /etc -writable -type f 2>/dev/null. If /etc/passwd available on recording – root without exploits and without SUID.
uname -a. Old nuclei have public exploits of escalating privilege.
LinPEAS combines points 1-7 and adds dozens of additional checks. Launch if manual intelligence did not give results in 5-10 minutes.
Each point is a potential vector. There is usually one or two in the CTF. There may be several parallel chains on the real pentest.
Frequent Beginner Mistakes When Working with SUID
I will take the failures on which I lost time myself and see how others lose.
SUID confusion with sudo. SUID - bit on the file, the program is launched from the file owner automatically at any start. Sudo is a separate mechanism that checks /etc/sudoers and explicitly allowing specific users to execute specific commands from root. Two independent mechanisms. SUID does not require a password or checks sudoers. Sudo does not require SUID on the target binary. MITRE ATT&CK shares them: SUID – T1548.001, sudo – T1548.003 (Sudo and Sudo Caching).
Do not check the owner of the binary. SUID-bit is not equal to "root". If the binary belongs to the user www-data and has SUID – the launch will give the rights www-data, not root. Always see the third column in ls -la: -rwsr-xr-x 1 root root - here root root means the owner of the root and the root group. Without this check, you spend time on binary, which will give useless privileges.
Copy the binary and lose SUID. When copying through cp SUID bit is reset – the protective mechanism of the nucleus. If you need to transfer SUID binary, use cp --preserve=mode or work with the original on the spot. Similarly, SUID is reset when the contents of the file change.
Ignore nosuid sections. Sections with nosuid completely ignore SUID/SGID bits. Standard practice for /tmp, /dev/shm, /run. Check: mount | grep nosuid or cat /proc/mounts | grep nosuid. Created a SUID Shell in /tmp And it doesn't work? The first thing to check.
Forget the flag -p at the bash. Bash by default resets the effective UID to real UID at startup. Without -p (privileged mode) SUID on bash is useless – get a shell with regular user rights. Conscious protective mechanism bash, and it catches beginners is almost guaranteed.
Do not use GTFOBins. Find SUID on awk, less or aspell and lose half an hour without knowing what to do. On GTFOBins for each of them there is a ready-made team with instructions. Don’t remember everything – remember the address of the directory.
Before you break, you need to understand how the protection is arranged. In Linux, each file and directory has three rights groups: the owner (user), the group (group), the rest (others). Each group receives a combination of three permissions: reading (r = 4), recording (w = 2), execution (x = 1). More details in our linux guide for the pentester.
When in the conclusion ls -la You see a line like -rwxr-xr-x, read from left to right: the owner can all (rwx = 7), group - read and perform (r-x = 5), the rest - too (r-x = 5). In the numerical format — 755. Team chmod 755 file sets these linux file permissions.
But standard rwx for understanding privesc vectors is not enough. There is a fourth, senior level in the chmod numerical record of access rights — it is responsible for special bits: SUID (4), SGID (2) and sticky bit (1). Recording chmod 4755 file means: SUID included (4), owner of rwx (7), group r-x (5), other r-x (5). It is these special bits that turn the usual binary into the attack vector when the configuration curve.
File /etc/passwd read by all (rights 644), and /etc/shadow with password hashes, only root. This difference is the foundation of Linux security, and every privesc vector essentially bypasses this foundation in one way or another.
SUID bit Linux – when the program gets other people’s rights
SUID (Set User ID) is a mechanism in which the program is launched not with the rights of the person who caused it, but with the rights of the owner of the file. Analogy: you — the usual employee — gave the director’s key card, but it only works while you are inside one particular cabinet. Included – the authority of the director. Out is a regular employee again.
A classic legitimate example — /usr/bin/passwd. The program should change the file /etc/shadow, which reads only root. Without SUID, the average user would not be able to change their own password. With SUID, the program is run on root name, makes a change and ends. It's safe because passwd does one specific operation.
The problem appears when the admin puts SUID on a binary capable of performing arbitrary commands. find, vim, python, bash – each of them, in the presence of a SUID-bit, becomes a straight road to root shell. In MITRE ATT&CK terminology, the abuse of SUID/SGID is classified as Technique Setuid and Setgid (T1548.001, Privilege Escalation). The attacker finds misconfigured binaries exploitation and uses the full-time capabilities of the program to increase privileges.
What does SUID look like in the system and a trap with the title S
You can install SUID in two ways: symbolic chmod u+s file or numerical chmod 4755 file. In the numerical record, the fourth in the senior category is SUID. After installation in the output ls -la position x the owner is replaced by s:
-rwsr-xr-x – SUID is installed, execution is allowed (line s). Binarnick will start on behalf of the owner.
-rwSr-xr-x – SUID is installed, but performance is NOT allowed (capital S). The file cannot be started, operation via SUID is excluded.
Difference between s and S The trap I fell for twice. Capital S means that someone has put SUID without a execution right—usually a configuration error, not an attack vector. Don't waste time on these files when exploration.
SGID Access Rights – SUID Group Analog
SGID (Set Group ID) works similarly to SUID, but for the owner group. When SGID is installed on the executable file, the process is triggered with the rights of the file owner group, not with the group of the launch user.
Installation: chmod g+s file or chmod 2755 file. In the conclusion ls -la position x in triplet group is replaced by s: -rwxr-sr-x. Vulnerable SGID binarys give the attacker not root, but a membership in the target group — and if that group has access to sensitive files (e.g., a group shadow can read /etc/shadow), it is a full vector of escalation.
SGID on directories is a very different behavior
On the SGID directories behaves fundamentally differently: all new files created within the SGID-directory inherit a group of directories, and not the main group of the creator. It is used for command directories where multiple users need group sharing.
For escalating the privileges of CTF SGID on directories is less interesting as a direct vector. But in real pentests, the SGID directory contains a config with passwords, available only to a certain group – and obtaining membership in this group through SGID-binary opens access to credenshels. A chain of two steps instead of one.
Sticky bit Linux – protection of general directories
Sticky bit is the least “attacking” of three special bits, but you need to understand it for the full picture of pwn linux permissions. Installed on directories: chmod +t dir or chmod 1777 dir.
Effect: In the directory with sticky bit, the user can only delete their files, even if the directory has rights 777 (full access for all). Canonical example — /tmp. Without sticky bit, any user could delete other people's files from /tmp, breaking a bunch of system processes.
In the conclusion ls -ld /tmp sticky bit is marked with a letter t in position x for others: drwxrwxrwt. Capital T – sticky bit is, but there is no screen for others (similar to the capital S for SUID).
For escalation of privileges sticky bit itself is not a vector. But here’s what’s critical to practice: if the file system is mounted with an option nosuid, then SUID/SGID bits on files inside it the kernel simply ignores. This is standard practice for /tmp, /dev/shm, /run. Beginners regularly stumble on this: copy the binary in /tmp, put SUID through chmod u+s — and nothing works because the section is mounted with nosuid. Check: grep nosuid /proc/mounts.
Search for Linux SUID files – exploration before operation
Intelligence is the foundation of any privileged access. According to MITRE ATT&CK, file and directory detection is File and Directory Discovery (T1083, Discovery). In practice, it all comes down to several teams.
Manual search SUID via find
Basic team – learn by heart:
find / -perm -4000 -type f 2>/dev/null
find / -perm -2000 -type f 2>/dev/null
find / -perm -u=s -o -perm -g=s -type f 2>/dev/null
Let's look at the parts: / Search from the root. -perm -4000 – files with SUID installed (4 in the senior category). -type f – only ordinary files, not directories and not symbols. 2>/dev/null – redirecting “Permission neza” errors into a void so as not to clog the output.
On typical Ubuntu 22.04 the conclusion will show a dozen-two standard binary: /usr/bin/passwd, /usr/bin/su, /usr/bin/sudo, /usr/bin/mount, /usr/bin/umount. All are legitimate and expected. The binary is of interest, which should not be on this list: find, vim, python3, bash, cp, nano, docker.
CTF reception: to cut off standard binary and find only added later, use find / -xdev -perm -4000 -newer /bin/bash 2>/dev/null. Flag -newer show files modified later /bin/bash – that is, added after installation of the system. Flag -xdev does not allow you to switch to other file systems.
Automation: LinPEAS and privilege scanners
Manual search is a base, but on the CTF time is expensive. LinPEAS (Linux Privilege Escalation Awesome Script) automatically checks dozens of privilege vectors, including SUID/SGID. Download the script, do it chmod +x linpeas.sh && ./linpeas.sh. LinPEAS highlights potentially vulnerable SUID binary red and yellow, giving instant prioritization.
There is also a specialized tool – suid3num. It categorizes the found SUID files into standard (expected for distribution) and non-standard (potentially vulnerable), plus automatically checks them on the basis of GTFOBins. The tool groups binary in the category "default", "not default" and "custom" - greatly accelerates the analysis.
But no automatic scanner covers – custom binary. CTFs often come across compiled programs without names from GTFOBins. Here only manual analysis helps: strings binary_name show string constants, ltrace ./binary_name – challenges of library functions. If in the conclusion strings See a challenge like system("tar") or system("ls") without an absolute path is an almost guaranteed vector through PATH hijacking.
GTFOBins examples — a catalog of vulnerable SUIDs of binary
GTFOBins (gtfobins.github.io) is a directory of standard Unix utilities that can be used to bypass security restrictions. For each binary, the operating techniques are specified in different contexts: SUID, sudo, capabilities, reading/writing files.
The algorithm of working with GTFOBins on CTF is five steps:
Found a non-standard SUID binary through find.
Opening GTFOBins, looking for a binary by name.
Go to the SUID section on its page.
Copy the command, adapt the way for a particular machine.
Get root shell.
Binary, which are most commonly found in labs and CTFs:
find One of the most popular. If at find It is worth SUID, enough to perform find . -exec /bin/sh -p \; -quit. Parameter -exec launches an arbitrary team, -p saves effective UID, -quit completes the find after the first match. The result is root-hell.
bash – if on /bin/bash is worth SUID (in reality it is crazy, but in CTF happens), the team bash -p launches the shell with the owner's rights. Flag -p disables the reset of privileges that bash makes by default – without it, SUID on bash is useless.
python3 – with SUID allows you to perform python3 -c 'import os; os.execl("/bin/sh", "sh", "-p")'. The interpreter is started from root, generates shells with preserved privileges.
vim/nano – text editors with SUID make it possible to edit any file from root. Through vim can open /etc/passwd or /etc/sudoers and add a user with UID 0 or a NOPASSWD record for sudo.
cp – there are three methods of operation of SUID: copying the substituted /etc/passwd, cloning SUID-bit on another binary and modification /etc/sudoers. Every worker when the copying utility has a misconfigured SUID.
The full list of binary with SUID-operation techniques on GTFOBins contains dozens of positions: from aa-exec and arp to awk, gdb and docker. You don’t need to remember everything – you need to remember where to look.
CTF Escalation of privileges – step-by-step scenarios
The theory without practice is dead. Three scenarios covering the main SUID-exploitation patterns.
Scenario 1: straight SUID on standard binary
Situation: received user-hell, intelligence through find / -perm -4000 -type f 2>/dev/null shows in the list /usr/bin/find with rights -rwsr-xr-x 1 root root.
What it means: find executed on behalf of root (SUID-bit installed, owner – root). U find has a parameter -exec, performing an arbitrary command for each file found.
Operation: find . -exec /bin/sh -p \; -quit. Check: id in the opened shell will show uid=0(root). Time from detection to root - 10 seconds.
On GTFOBins page find in the SUID section contains the same command — vector confirmation.
Scenario 2: PATH hijacking through custom binary
Situation: a non-standard binary was found during exploration /opt/backup with rights -rwsr-xr-x 1 root root. Team strings /opt/backup shows the challenge system("tar czf /tmp/backup.tar.gz /home").
What's the hole: the binary causes tar without an absolute path (not /usr/bin/tar, but simply tar). The system is looking for tar by the PATH environment variable, going the directories from left to right. Put your fake tar the directory that in PATH is standing earlier /usr/bin – and the binary will perform our substitution with root rights.
echo '#!/bin/sh' > /tmp/tar
echo '/bin/sh -p' >> /tmp/tar
chmod +x /tmp/tar
export PATH=/tmp:$PATH
/opt/backup
Result: instead of tar Our script is called, which opens the shell with root privileges. In terms of MITRE ATT&CK, it is the intersection of the Setuid and Setgid (T1548.001) techniques and the manipulation of the execution environment.
A similar focus works with anyone system() without the absolute path. On one CTF SUID-binary welcome called the file greetings along the relative path – the attacker replaced him with a symbol on the /bin/sh and got root.
Scenario 3: SUID on text editor
Situation: intelligence shows /usr/bin/vim.tiny with SUID root.
Logic: vim with root rights can edit any file in the system. The two main vectors:
Through /etc/sudoers: open vim.tiny /etc/sudoers, add a line username ALL=(ALL) NOPASSWD: ALL, save through :wq!. After that sudo su gives root without a password.
Through /etc/passwd: generate password hash through openssl passwd -6 -salt xyz yourpassword, then in vim add to /etc/passwd line with UID 0 — a new user with root rights. Option: replace the hash root in /etc/shadow through find with -exec sed, if find has SUID.
Both options require an understanding of the system file format. Each field in /etc/passwd divided by colon – the third field (UID) determines the level of privilege. UID 0 – root.
Linux privesc checklist for CTF and Labs
A systematic approach saves time. The order of action after receiving a user-hell, built in the probability of triggering in the CTF:
id and whoami. Check out the groups: membership docker, lxd or disk – independent escalation vectors not related to SUID.
sudo -l – what commands can be executed via sudo without a password? Often the fastest vector, faster than SUID.
find / -perm -4000 -type f 2>/dev/null and separately -perm -2000. Compare with the default set, allocate non-standard.
cat /etc/crontab and ls -la /etc/cron.d/. Look for scripts running root but available on the record to the current user.
getcap -r / 2>/dev/null. Linux capabilities is a more granular alternative to SUID (capabilities linux security). Binarnick with cap_setuid+ep equivalent to SUID root in terms of privesc.
find /etc -writable -type f 2>/dev/null. If /etc/passwd available on recording – root without exploits and without SUID.
uname -a. Old nuclei have public exploits of escalating privilege.
LinPEAS combines points 1-7 and adds dozens of additional checks. Launch if manual intelligence did not give results in 5-10 minutes.
Each point is a potential vector. There is usually one or two in the CTF. There may be several parallel chains on the real pentest.
Frequent Beginner Mistakes When Working with SUID
I will take the failures on which I lost time myself and see how others lose.
SUID confusion with sudo. SUID - bit on the file, the program is launched from the file owner automatically at any start. Sudo is a separate mechanism that checks /etc/sudoers and explicitly allowing specific users to execute specific commands from root. Two independent mechanisms. SUID does not require a password or checks sudoers. Sudo does not require SUID on the target binary. MITRE ATT&CK shares them: SUID – T1548.001, sudo – T1548.003 (Sudo and Sudo Caching).
Do not check the owner of the binary. SUID-bit is not equal to "root". If the binary belongs to the user www-data and has SUID – the launch will give the rights www-data, not root. Always see the third column in ls -la: -rwsr-xr-x 1 root root - here root root means the owner of the root and the root group. Without this check, you spend time on binary, which will give useless privileges.
Copy the binary and lose SUID. When copying through cp SUID bit is reset – the protective mechanism of the nucleus. If you need to transfer SUID binary, use cp --preserve=mode or work with the original on the spot. Similarly, SUID is reset when the contents of the file change.
Ignore nosuid sections. Sections with nosuid completely ignore SUID/SGID bits. Standard practice for /tmp, /dev/shm, /run. Check: mount | grep nosuid or cat /proc/mounts | grep nosuid. Created a SUID Shell in /tmp And it doesn't work? The first thing to check.
Forget the flag -p at the bash. Bash by default resets the effective UID to real UID at startup. Without -p (privileged mode) SUID on bash is useless – get a shell with regular user rights. Conscious protective mechanism bash, and it catches beginners is almost guaranteed.
Do not use GTFOBins. Find SUID on awk, less or aspell and lose half an hour without knowing what to do. On GTFOBins for each of them there is a ready-made team with instructions. Don’t remember everything – remember the address of the directory.
