Capabilities
Theory
Linux capabilities provide a subset of the available root privileges to a process. This effectively breaks up root privileges into smaller and distinctive units. Each of these units can then be independently granted to processes. This way the full set of privileges is reduced, decreasing the risks of exploitation
Capabilities Sets
Conceptually capabilities are maintained in sets, which are represented as bit masks. For all running processes capability information is maintained per thread; for binaries in the file system it’s stored in extended attributes. Thread capability sets are copied on fork() and specially transformed on execve()
CapEff is the effective capability set represents all capabilities the process is using at the moment (this is the actual set of capabilities that the kernel uses for permission checks). For file capabilities the effective set is in fact a single bit indicating whether the capabilities of the permitted set will be moved to the effective set upon running a binary. This makes it possible for binaries that are not capability-aware to make use of file capabilities without issuing special system calls.
CapPrm is a superset of capabilities that the thread may add to either the thread permitted or thread inheritable sets. The thread can use the capset() system call to manage capabilities: It may drop any capability from any set, but only add capabilities to its thread effective and inherited sets that are in its thread permitted set. Consequently it cannot add any capability to its thread permitted set, unless it has the cap_setpcap capability in its thread effective set.
CapInh, using the inherited set all capabilities that are allowed to be inherited from a parent process can be specified. This prevents a process from receiving any capabilities it does not need. This set is preserved across an execve and is usually set by a process receiving capabilities rather than by a process that’s handing out capabilities to its children.
CapBnd, With the bounding set it’s possible to restrict the capabilities a process may ever receive. Only capabilities that are present in the bounding set will be allowed in the inheritable and permitted sets.
CapAmb is the ambient capability set applies to all non-SUID binaries without file capabilities. It preserves capabilities when calling execve. However, not all capabilities in the ambient set may be preserved because they are being dropped in case they are not present in either the inheritable or permitted capability set. This set is preserved across execve calls.
Practice
Processes Capabilities
We can can find the capabilities of a process as follow
#List current process capabilities
cat /proc/self/status | grep Cap
cat /proc/$$/status | grep Cap
capsh --print
#List capabilities of <PID> process
cat /proc/<PID>/status | grep CapUsing the capsh utility we can decode them into the capabilities name.
capsh --decode=0000003fffffffff
0x0000003fffffffff=cap_chown,cap_dac_override,cap_dac_read_search,cap_fowner,cap_fsetid,cap_kill,cap_setgid,cap_setuid,cap_setpcap,cap_linux_immutable,cap_net_bind_service,cap_net_broadcast,cap_net_admin,cap_net_raw,cap_ipc_lock,cap_ipc_owner,cap_sys_module,cap_sys_rawio,cap_sys_chroot,cap_sys_ptrace,cap_sys_pacct,cap_sys_admin,cap_sys_boot,cap_sys_nice,cap_sys_resource,cap_sys_time,cap_sys_tty_config,cap_mknod,cap_lease,cap_audit_write,cap_audit_control,cap_setfcap,cap_mac_override,cap_mac_admin,cap_syslog,cap_wake_alarm,cap_block_suspend,37Binaries Capabilities
Binaries can have capabilities that can be used while executing. We can search binaries with capabilities as follow
If you find that a binary have interesting capabilities, you can check on GTFOBins for known exploits.
Having the capability =ep means the binary has all the capabilities
Setcap with SUID/SUDO
If you found the setcap binary with the SUID bit or with SUDO permissions, you can obtain root access.
For example, we can leverage the CAP_SETUID capabilities with the python binary
Interesting Capabilities
CAP_SYS_ADMIN
CAP_SYS_ADMIN is largely a catchall capability, it can easily lead to additional capabilities or full root (typically access to all capabilities). CAP_SYS_ADMIN is required to perform a range of administrative operations, which is difficult to drop from containers if privileged operations are performed within the container.
Retaining this capability is often necessary for containers which mimic entire systems versus individual application containers which can be more restrictive. Among other things this allows to mount devices or abuse release_agent to escape from the container.
For example, if python have the CAP_SYS_ADMIN capabilities, we can mount a modified passwd file on top of the real passwd file.
First generate the new passwd file
Then we can use the following python script to mount it
CAP_SYS_PTRACE
CAP_SYS_PTRACE allows to use ptrace(2) and recently introduced cross memory attach system calls such as process_vm_readv(2) and process_vm_writev(2).
If this capability is granted and the ptrace(2) system call itself is not blocked by a seccomp filter, this will allow an attacker to bypass other seccomp restrictions, see PoC for bypassing seccomp if ptrace is allowed.
For example, if python have the CAP_SYS_PTRACE capabilities, we can inject a shellcode in a root process memory.
We can use the following python code to inject our shellcode
Now we can execute, and connect to the bind shell
Here is an other PrivEsc example with gdb if it have the CAP_SYS_PTRACE enabled
First, create a shellcode with msfvenom and python
Then, debug a root process with gdb ad copy-paste the previously generated gdb lines:
CAP_SYS_MODULE
CAP_SYS_MODULE allows the process to load and unload arbitrary kernel modules (init_module(2), finit_module(2) and delete_module(2) system calls).
This could lead to trivial privilege escalation and ring-0 compromise. The kernel can be modified at will, subverting all system security, Linux Security Modules, and container systems.
This means that you can insert/remove kernel modules in/from the kernel of the host machine.
In the following example the python binary has this capability.
In order to abuse this, lets create a fake lib/modules folder
Create the kernel module that is going to execute a reverse shell and the Makefile to compile it
The blank char before each make word in the Makefile must be a tab, not spaces!
We can compile it using our Makefile and the make command
If you can't find the /lib/modules/<version>/build folder, this is because you have not download the linux headers of your kernel version
Finally, we can execute this python code
In the following example the kmod binary has this capability.
It means that it's possible to use the command insmod to insert a kernel module. We can use the same C code seen in the previous example to get a reverse shell abusing this privilege.
The blank char before each make word in the Makefile must be a tab, not spaces!
We can compile it using our Makefile and the make command
If you can't find the /lib/modules/<version>/build folder, this is because you have not download the linux headers of your kernel version
Finally, load the module using insmode
CAP_DAC_READ_SEARCH
CAP_DAC_READ_SEARCH allows a process to bypass file read, and directory read and execute permissions. While this was designed to be used for searching or reading files, it also grants the process permission to invoke open_by_handle_at(2).
Any process with the capability CAP_DAC_READ_SEARCH can use open_by_handle_at(2) to gain access to any file, even files outside their mount namespace. The handle passed into open_by_handle_at(2) is intended to be an opaque identifier retrieved using name_to_handle_at(2). However, this handle contains sensitive and tamperable information, such as inode numbers. This was first shown to be an issue in Docker containers by Sebastian Krahmer with shocker exploit.
This means that you can bypass can bypass file read permission checks and directory read/execute permission checks.
In the following example the python binary has this capability.
We can abuse it to read the /etc/shadow file
In the following example the tar binary has this capability.
We can abuse it to read the /etc/shadow file
Alternatively, we can do as follow
CAP_DAC_OVERRIDE
CAP_DAC_OVERRIDE allows to ignore the permission bits of files. With this capability, you can modify any file like passwd, sudoers or shadow to obtain root access.
This mean that you can bypass write permission checks on any file, so you can write any file.
In the following example the python binary has this capability.
We can abuse it to override the /etc/sudoer file
We can now spawn an elevated shell
Alternatively, we can overwritte the /etc/passwd file. First we have to generate a new password hash
Then, use the following script to edit the /etc/passwd file
We can now easily su as root
In the following example the vim binary has this capability.
We can abuse it to override the /etc/shadow file. First we can generate a new password hash
Now we can just vim the /etc/passwd file and replace the root hash by the generated one
We can now easily su as root
CAP_CHOWN
CAP_CHOWN allow us to make arbitrary changes to file UIDs and GIDs.
This means that it's possible to change the ownership of any file.
In the following example the python binary has this capability.
We can abuse it to modify the file owner of the /etc/shadow file or the /root. First we can check what is our current user id
Replace the attribute numbers with the current user id.
We can now generate a new hash
And edit the /etc/shadow file to change the root password
We can now easily su as root
In the following example the ruby binary has this capability.
We can abuse it to modify the file owner of the /etc/shadow file or the /root directory. First we can check what is our current user id
Replace the attribute numbers with the current user id.
We can now generate a new hash
And edit the /etc/shadow file to change the root password
We can now easily su as root
CAP_FOWNER
CAP_CHOWN allow us to bypass permission checks on operations that normally require the filesystem UID of the process to match the UID of the file. excluding those operations covered by CAP_DAC_OVERRIDE and CAP_DAC_READ_SEARCH. Additionally it allow us to set inode flags, ACLs on arbitrary files, ignore the directory sticky bit on file deletion.
This means that it's possible to change the permission of any file.
In the following example the python binary has this capability.
We can abuse it to modify the file permissions of the /etc/shadow. First generate a new hash
Give us permissions over the /etc/shadow file
And edit the /etc/shadow file to change the root password
We can now easily su as root
In the following example the ruby binary has this capability.
We can abuse it to modify the file permissions of the /etc/shadow. First generate a new hash
Give us permissions over the /etc/shadow file
And edit the /etc/shadow file to change the root password
We can now easily su as root
CAP_SETUID
In the following example the python binary has this capability.
We can abuse it to spawn an elevated shell
In the following example the ruby binary has this capability.
We can abuse it to spawn an elevated shell
In the following example the perl binary has this capability.
We can abuse it to spawn an elevated shell
In the following example the php binary has this capability.
We can abuse it to spawn an elevated shell
CAP_SETGID
CAP_SETGID allow us to make arbitrary manipulations of process GIDs and supplementary GID list.
This means that it's possible to set the effective group id of the created process.
In the following example the python binary has this capability.
In this case you should look for interesting files that a group can read/write because you can impersonate any group:
Find the group id of the targeted group
We can spawn a shell with the targeted GID
In the following example the ruby binary has this capability.
In this case you should look for interesting files that a group can read/write because you can impersonate any group:
Find the group id of the targeted group
We can spawn a shell with the targeted GID
In the following example the perl binary has this capability.
In this case you should look for interesting files that a group can read/write because you can impersonate any group:
Find the group id of the targeted group
We can spawn a shell with the targeted GID
In the following example the php binary has this capability.
In this case you should look for interesting files that a group can read/write because you can impersonate any group:
Find the group id of the targeted group
We can spawn a shell with the targeted GID
CAP_SETFCAP
CAP_SETFCAP allow us to set arbitrary capabilities on a file.
This means that it's possible to set capabilities on files and processes
In the following example the python binary has this capability.
We can abuse it to add the cap_setuid capability to the binary of our choice. To exploit, we can use the following script
Execute it on the file of your choice
Note that if you set a new capability to the binary with CAP_SETFCAP, you will lose this cap.
Once you have SETUID capability you can go to its section to see how to escalate privileges.
CAP_SYS_RAWIO
CAP_SYS_RAWIO provides a number of sensitive operations including access to /dev/mem, /dev/kmem or /proc/kcore, modify mmap_min_addr, access ioperm(2) and iopl(2) system calls, and various disk commands. The FIBMAP ioctl(2) is also enabled via this capability, which has caused issues in the past. As per the man page, this also allows the holder to descriptively perform a range of device-specific operations on other devices.
This can be useful for privilege escalation and Docker breakout.
CAP_KILL
In the following example the python binary has this capability.
If there is a node program running as root (or as a different user)you could probably send it the signal SIGUSR1 and make it open the node debugger to where you can connect.
CAP_NET_BIND_SERVICE
CAP_NET_BIND_SERVICE allow us to Bind a socket to Internet domain privileged ports (port numbers less than 1024).
This means that it's possible to listen in any port (even in privileged ones). You cannot escalate privileges directly with this capability.
In the following example the python binary has this capability.
Then, we are able to listen on any port
And connect from it to any othe port
CAP_NET_RAW
CAP_NET_RAW allows a process to be able to create RAW and PACKET socket types for the available network namespaces. This allows arbitrary packet generation and transmission through the exposed network interfaces. In many cases this interface will be a virtual Ethernet device which may allow for a malicious or compromised container to spoof packets at various network layers. A malicious process or compromised container with this capability may inject into upstream bridge, exploit routing between containers, bypass network access controls, and otherwise tamper with host networking if a firewall is not in place to limit the packet types and contents. Finally, this capability allows the process to bind to any address within the available namespaces. This capability is often retained by privileged containers to allow ping to function by using RAW sockets to create ICMP requests from a container.
This means that it's possible to sniff traffic. You cannot escalate privileges directly with this capability.
In the following example the python binary has this capability.
We are able to run the following code and sniff traffic of the "lo" (localhost) interface.
In the following example the tcpdump binary has this capability.
Then, we can sniff sensitive information by running tcpdump for a while.
CAP_NET_ADMIN + CAP_NET_RAW
CAP_NET_ADMIN allows the capability holder to modify the exposed network namespaces' firewall, routing tables, socket permissions, network interface configuration and other related settings on exposed network interfaces. This also provides the ability to enable promiscuous mode for the attached network interfaces and potentially sniff across namespaces.
In the following example the python binary has this capability.
We can run following code to dump iptables filter table rules.
Or flush iptables filter table
CAP_LINUX_IMMUTABLE
CAP_LINUX_IMMUTABLE allow us to set the FS_APPEND_FL and FS_IMMUTABLE_FL inode flags
If you find that a file is immutable and python has this capability, you can remove the immutable attribute and make the file modifiable
In the following example the python binary has this capability.
If you find that a file is immutable, you can remove the immutable attribute and make the file modifiable:
We can use the following script to remove the attribute
CAP_SYS_CHROOT
CAP_SYS_CHROOT permits the use of the chroot(2) system call. This may allow escaping of any chroot(2) environment, using known weaknesses and escapes.
You may want to have a look on chw00t, a chroot breaking tool.
CAP_SETPCAP
CAP_SETCAP is a Linux capability that allows a process to modify the capability sets of another process. It grants the ability to add or remove capabilities from the effective, inheritable, and permitted capability sets of other processes. However, there are certain restrictions on how this capability can be used.
A process with CAP_SETPCAP can only grant or remove capabilities that are in its own permitted capability set. In other words, a process cannot grant a capability to another process if it does not have that capability itself. This restriction prevents a process from elevating the privileges of another process beyond its own level of privilege.
Moreover, in recent kernel versions, the CAP_SETPCAP capability has been further restricted. It no longer allows a process to arbitrarily modify the capability sets of other processes. Instead, it only allows a process to lower the capabilities in its own permitted capability set or the permitted capability set of its descendants. This change was introduced to reduce potential security risks associated with the capability.
References
Last updated
Was this helpful?