In most cases, gaining root privileges on Linuxis not an easy task. Security updates are usually released on a daily basis, and when a new zero-day or exploit is discovered in the Linux environment, in most cases it will be updated within hours. Therefore, when an attacker gains elevated privileges on a machine, the first thing they would probably want to do is maintain those privileges. One of the most common methods attackers use to do this is to use the suid mechanism.
What does SUID mean?
As many readers will know, Linux has three basic permissions: read, write, and execute. But beyond that, Linux also has some other privileges that are used in specific cases. Among them you can find setuid and setgid, which are intended for situations where you have a program that must run as a specific user or group (usually root), but you don't want to grant elevated privileges to every user of the program. When a program is executed with the setuid/setgid bit, the program can request the operating system to acquire the owner's (or group's) permissions for the process.
Take, for example, the ping command. To send an ICMP packet, ping must use a raw socket, which on Linux requires root privileges. However, ping is a basic command with frequent use and we cannot allow every “ping-user” to have elevated privileges. So what is the solution? The SUID permissions. When ping is executed, it actually runs as root, regardless of which user runs it.
An intruder would find it very easy, once it gains elevated privileges, to write a simple program that does nothing more than open a shell and obtain suid rights. After doing this, it can return to the machine from a low-privileged webshell or any other low-privileged back door and use the dropped suid-shell to gain root privileges.
Fortunately, this suid shell is extremely easy to detect. Due to the risk of such executables being present on the machine, most Linux distributions come with very few suid binaries. Sysadmins can regularly search for suid binaries on the machine and can easily be notified of any new creations, unwanted suid binaries. A common solution for this as an intruder would be to simply replace the legitimate suid binary with a malicious one. However, again, this is often closely monitored and there are many ways to ensure that suid files have not changed. It is still possible to use the built‑in commands dpkg -verify or rpm -Va for this purpose.
What is Shadow SUID?
Shadow SUID is the same as a regular suid file, only it does not have the setuid bit, which makes it very difficult to find or observe.
The way Shadow SUID works is that it takes over the setuid bit from an existing setuid binary, using the binfmt_misc mechanism, which is part of the Linux kernel.
This takeover is triggered when a targeted setuid binary command is executed that has been set up for this purpose before execution. The important thing you need to understand is that you do not need to modify the original suid file to target it. To create a Shadow suid, all you need is at least one suid binary on the machine.
Am I vulnerable?
Given that this has been part of the Linux Kernel since 2004, the likelihood is that you are. However, you can check if your kernel came with the binfmt module by running the following code on the command line:
$ grep ‘BINFMT_MISC’ / boot / config-‘uname -r`
Have I been affected?
First, check if the binfmt_misc filesystem is mounted using:
$ mount | grep binfmt_misc
Next, check the relevant path
$ ls -la / proc / sys / fs / binfmt_misc
This will result in something like this:
Any other folder besides “register” and “status” should be inspected carefully.
If it looks more like this:
Print the additional file and see if there is “C” in the “flags” field as shown below:
To remove the binfmt_misc rule, simply write “-1” in the file.
Note that it may also be a legitimate file, so if you are not sure, ask for further advice before proceeding.
How can I protect myself?
For endpoints without SentinelOne protection, there is no easy answer, as any recovery step can be bypassed. However, the best simple solution, which again must be done carefully, would be to delete the relevant .ko file:
# modinfo -n binfmt_misc
/lib/modules/4.10.0-42-generic/kernel/fs/binfmt_misc.ko
# rm $ (modinfo -n binfmt_misc)
Keep in mind that you may need to delete the .ko for all installed kernel versions.
How can SentinelOne help me?
With the new Linux agent (v2.6 SP2), you are fully protected from Shadow SUIDs. The agent continuously monitors any execution of the process and when a Shadow SUID is detected, the process is blocked, thus preventing damage. Additionally, given that it knows exactly how the operating system works, users are able to see the attack history behind the execution and understand how it originated.
