On Linux and macOS, a program normally runs with the privileges of the user who starts it. The setuid and setgid bits change that: the program runs with the privileges of its owning user or group instead. MITRE tracks the abuse of this as T1548.001, Setuid and Setgid, a privilege escalation technique.
How attackers use it
Some programs need elevated rights to work, even when the person running them does not have those rights. Setting the bits is one way to deliver that, and MITRE points out that any user can set the flag on their own applications. The chmod command does it either with a bitmask such as chmod 4777 file or in shorthand with chmod u+s file. Setgid uses chmod 2775 or chmod g+s.
MITRE documents two abuse patterns.
- An adversary sets the bit on their own malware so it can run in an elevated context later.
- An adversary hunts for existing binaries that already have the bits set, and abuses one that is vulnerable or offers a shell escape.
The bits show up as an s in place of the x when you view attributes with ls -l. Finding such files is a simple search with the find command, which is exactly what defenders and adversaries both do.
How to detect it
MITRE's detection strategy has two angles.
- Watch for
chmodoperations that set setuid or setgid bits, and correlate them with a privileged process starting afterwards. - Watch for execution where the effective user ID differs from the real user ID, especially from user writable or unusual paths, and for root-owned binaries launched by unprivileged users.
On Linux, audit rules on chmod family system calls feed the first. Process events that record both UID and EUID feed the second.
How to reduce the risk
MITRE lists one mitigation, Operating System Configuration. Applications with known vulnerabilities or known shell escapes should not have the setuid or setgid bits set, and the number of programs with those bits should be kept to a minimum across the system.
In practice, record the expected list on your base image, then diff against it on a schedule. Mount user writable and data filesystems with nosuid where your workloads allow it.
Check your own environment
A read-only listing of setuid and setgid files on one filesystem, for Linux or macOS.
find / -xdev -type f \( -perm -4000 -o -perm -2000 \) -ls 2>/dev/null
- Compare the output to your golden image.
- Look closely at anything in a home directory,
/tmpor another user writable path. - For each unfamiliar entry, ask whether the program needs the bit at all.
Quick check
How can you tell a setuid file in an ls -l listing?
An s appears in the owner execute position instead of an x.
What is the first mitigation MITRE gives for this technique?
Keep the number of setuid and setgid programs to a minimum, and never set the bits on applications with known vulnerabilities or shell escapes.
Sources
- MITRE ATT&CK, Abuse Elevation Control Mechanism: Setuid and Setgid: https://attack.mitre.org/techniques/T1548/001
