Linux Capabilities
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Learn & practice GCP Hacking:
HackTricks Training GCP Red Team Expert (GRTE)
![](https://book.hacktricks.xyz/~gitbook/image?url=https%3A%2F%2Ffiles.gitbook.com%2Fv0%2Fb%2Fgitbook-x-prod.appspot.com%2Fo%2Fspaces%252F-L_2uGJGU7AVNRcqRvEi%252Fuploads%252FelPCTwoecVdnsfjxCZtN%252Fimage.png%3Falt%3Dmedia%26token%3D9ee4ff3e-92dc-471c-abfe-1c25e446a6ed&width=768&dpr=4&quality=100&sign=9c8fe74f&sv=1)
RootedCON 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.\
Capacidades de Linux
Las capacidades de Linux dividen los privilegios de root en unidades más pequeñas y distintas, permitiendo que los procesos tengan un subconjunto de privilegios. Esto minimiza los riesgos al no otorgar privilegios de root completos innecesariamente.
El Problema:
Los usuarios normales tienen permisos limitados, afectando tareas como abrir un socket de red que requiere acceso de root.
Conjuntos de Capacidades:
Hereditarias (CapInh):
Propósito: Determina las capacidades transmitidas desde el proceso padre.
Funcionalidad: Cuando se crea un nuevo proceso, hereda las capacidades de su padre en este conjunto. Útil para mantener ciertos privilegios a través de la creación de procesos.
Restricciones: Un proceso no puede adquirir capacidades que su padre no poseía.
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.
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.
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.
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.
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.
Para más información, consulta:
Capacidades de Procesos y Binarios
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. 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
Puedes encontrar las capacidades del proceso actual en cat /proc/self/status
o haciendo capsh --print
y de otros usuarios en /proc/<pid>/status
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 de límites
CapAmb = Conjunto de capacidades ambientales
Estos números hexadecimales no tienen sentido. Usando la utilidad capsh podemos decodificarlos en el nombre de las capacidades.
Vamos a revisar ahora las capabilities utilizadas por ping
:
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.
Vamos a verificar 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):
Como puedes 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 particular. Esta llamada al sistema solo necesita proporcionar el PID para obtener más información.
Capacidades de los Binarios
Los binarios pueden tener capacidades que se pueden usar mientras se ejecutan. Por ejemplo, es muy común encontrar el binario ping
con la capacidad cap_net_raw
:
Puedes buscar binarios con capacidades usando:
Dropping capabilities with capsh
Si eliminamos las capacidades CAP_NET_RAW para ping, entonces la utilidad ping ya no debería funcionar.
Además de la salida de capsh en sí, el comando tcpdump 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 permiso para abrir un socket ICMP. Ahora sabemos con certeza que esto funciona como se esperaba.
Eliminar Capacidades
Puedes eliminar capacidades de un binario con
User Capabilities
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, esto y esto, 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
.
Ejemplo de archivo:
Capacidades del Entorno
Compilando el siguiente programa es posible generar un shell bash dentro de un entorno que proporciona capacidades.
Dentro del bash ejecutado por el binario ambiental compilado es posible observar las nuevas capacidades (un usuario regular no tendrá ninguna capacidad en la sección "actual").
Solo puedes agregar capacidades que estén presentes tanto en el conjunto permitido como en el conjunto heredable.
Binarios conscientes de capacidades / Binarios tontos en capacidades
Los binarios conscientes de capacidades no usarán las nuevas capacidades otorgadas por el entorno, sin embargo, los binarios tontos en capacidades las usarán ya que no las rechazarán. Esto hace que los binarios tontos en capacidades sean vulnerables dentro de un entorno especial que otorga capacidades a los binarios.
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:
Capacidades en Contenedores Docker
Por defecto, Docker asigna algunas capacidades a los contenedores. Es muy fácil verificar cuáles son estas capacidades ejecutando:
![](https://book.hacktricks.xyz/~gitbook/image?url=https%3A%2F%2Ffiles.gitbook.com%2Fv0%2Fb%2Fgitbook-x-prod.appspot.com%2Fo%2Fspaces%252F-L_2uGJGU7AVNRcqRvEi%252Fuploads%252FelPCTwoecVdnsfjxCZtN%252Fimage.png%3Falt%3Dmedia%26token%3D9ee4ff3e-92dc-471c-abfe-1c25e446a6ed&width=768&dpr=4&quality=100&sign=9c8fe74f&sv=1)
RootedCON 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.
Privesc/Escape de Contenedor
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.
Puedes forzar capacidades en programas usando setcap
, y consultar estas usando getcap
:
El +ep
significa que estás agregando la capacidad (“-” la eliminaría) como Efectiva y Permitida.
Para identificar programas en un sistema o carpeta con capacidades:
Ejemplo de explotación
En el siguiente ejemplo, el binario /usr/bin/python2.6
se encuentra vulnerable a privesc:
Capacidades necesarias para que tcpdump
permita a cualquier usuario esnifar paquetes:
El caso especial de capacidades "vacías"
De la documentación: 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:
no es propiedad de root
no tiene bits
SUID
/SGID
establecidostiene un conjunto de capacidades vacío (por ejemplo:
getcap myelf
devuelvemyelf =ep
)
entonces ese binario se ejecutará como root.
CAP_SYS_ADMIN
CAP_SYS_ADMIN
es una capacidad de Linux altamente potente, a menudo equiparada a un nivel casi root debido a sus extensos privilegios administrativos, como montar dispositivos o manipular características del kernel. Si bien es indispensable para contenedores que simulan sistemas completos, CAP_SYS_ADMIN
plantea desafíos de seguridad significativos, especialmente en entornos contenedorizados, debido a su potencial para la escalada de privilegios y el compromiso del sistema. Por lo tanto, su uso requiere evaluaciones de seguridad rigurosas y una gestión cautelosa, con una fuerte preferencia por eliminar esta capacidad en contenedores específicos de aplicaciones para adherirse al principio de menor privilegio y minimizar la superficie de ataque.
Ejemplo con binario
Usando python, puedes montar un archivo passwd modificado encima del archivo passwd real:
Y finalmente montar el archivo passwd
modificado en /etc/passwd
:
Y podrás su
como root usando la contraseña "password".
Ejemplo con entorno (Docker breakout)
Puedes verificar las capacidades habilitadas dentro del contenedor de docker usando:
Dentro de la salida anterior, puedes ver que la capacidad SYS_ADMIN está habilitada.
Montar
Esto permite que el contenedor de docker monte el disco del host y acceda a él libremente:
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:
CAP_SYS_PTRACE
Esto significa que puedes escapar del contenedor inyectando un shellcode dentro de algún proceso que se esté ejecutando en el host. Para acceder a los procesos que se ejecutan dentro del host, el contenedor debe ejecutarse al menos con --pid=host
.
CAP_SYS_PTRACE
otorga la capacidad de utilizar funcionalidades de depuración y seguimiento de llamadas al sistema proporcionadas por ptrace(2)
y llamadas de adjunto de memoria cruzada como process_vm_readv(2)
y process_vm_writev(2)
. Aunque es poderoso para fines de diagnóstico y monitoreo, si CAP_SYS_PTRACE
está habilitado sin medidas restrictivas como un filtro seccomp en ptrace(2)
, puede socavar significativamente la seguridad del sistema. Específicamente, puede ser explotado para eludir otras restricciones de seguridad, notablemente las impuestas por seccomp, como lo demuestran pruebas de concepto (PoC) como esta.
Ejemplo con binario (python)
Ejemplo con binario (gdb)
gdb
con capacidad ptrace
:
Crea un shellcode con msfvenom para inyectar en memoria a través de gdb
Depurar un proceso root con gdb y copiar y pegar las líneas de gdb generadas anteriormente:
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
).
No podrás ver la salida del comando ejecutado, pero será ejecutado por ese proceso (así que obtén un rev shell).
Si obtienes el error "No symbol "system" in current context.", revisa el ejemplo anterior cargando un shellcode en un programa a través de gdb.
Ejemplo con entorno (Docker breakout) - Inyección de Shellcode
Puedes verificar las capacidades habilitadas dentro del contenedor de docker usando:
List processes running in the host ps -eaf
Get the architecture
uname -m
Find a shellcode for the architecture (https://www.exploit-db.com/exploits/41128)
Find a program to inject the shellcode into a process memory (https://github.com/0x00pf/0x00sec_code/blob/master/mem_inject/infect.c)
Modify the shellcode inside the program and compile it
gcc inject.c -o inject
Inject it and grab your shell:
./inject 299; nc 172.17.0.1 5600
CAP_SYS_MODULE
CAP_SYS_MODULE
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.
Esto significa que puedes insertar/quitar módulos del kernel en/el kernel de la máquina host.
Ejemplo con binario
En el siguiente ejemplo, el binario python
tiene esta capacidad.
Por defecto, el comando modprobe
verifica la lista de dependencias y los archivos de mapa en el directorio /lib/modules/$(uname -r)
.
Para abusar de esto, creemos una carpeta falsa lib/modules:
Luego compila el módulo del kernel que puedes encontrar 2 ejemplos a continuación y cópialo a esta carpeta:
Finalmente, ejecuta el código python necesario para cargar este módulo del kernel:
Ejemplo 2 con binario
En el siguiente ejemplo, el binario kmod
tiene esta capacidad.
Lo que significa que es posible usar el comando insmod
para insertar un módulo del kernel. Sigue el ejemplo a continuación para obtener un reverse shell abusando de este privilegio.
Ejemplo con entorno (Docker breakout)
Puedes verificar las capacidades habilitadas dentro del contenedor de docker usando:
Dentro de la salida anterior, puedes ver que la capacidad SYS_MODULE está habilitada.
Crea el módulo del kernel que va a ejecutar un reverse shell y el Makefile para compilarlo:
El carácter en blanco antes de cada palabra make en el Makefile debe ser una tabulación, no espacios!
Ejecuta make
para compilarlo.
Finalmente, inicia nc
dentro de un shell y carga el módulo desde otro y capturarás el shell en el proceso de nc:
El código de esta técnica fue copiado del laboratorio de "Abusing SYS_MODULE Capability" de 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
CAP_DAC_READ_SEARCH
CAP_DAC_READ_SEARCH permite a un proceso eludir los permisos para leer archivos y para leer y ejecutar directorios. Su uso principal es para la búsqueda o lectura de archivos. Sin embargo, también permite a un proceso utilizar la función open_by_handle_at(2)
, que puede acceder a cualquier archivo, incluidos aquellos fuera del espacio de nombres de montaje del proceso. El identificador utilizado en open_by_handle_at(2)
se supone que es un identificador no transparente obtenido a través de name_to_handle_at(2)
, pero puede incluir información sensible como números de inode que son vulnerables a la manipulación. El potencial de explotación de esta capacidad, particularmente en el contexto de contenedores Docker, fue demostrado por Sebastian Krahmer con el exploit shocker, como se analizó aquí. Esto significa que puedes eludir las verificaciones de permisos de lectura de archivos y las verificaciones de permisos de lectura/ejecución de directorios.
Ejemplo con binario
El binario podrá leer cualquier archivo. Así que, si un archivo como tar tiene esta capacidad, podrá leer el archivo shadow:
Ejemplo con binary2
En este caso supongamos que el binario python
tiene esta capacidad. Para listar archivos de root podrías hacer:
Y para leer un archivo podrías hacer:
Ejemplo en el Entorno (Docker breakout)
Puedes verificar las capacidades habilitadas dentro del contenedor de docker usando:
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, 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, la siguiente es una versión modificada que te permite indicar el archivo que deseas leer como primer argumento y volcarlo en un archivo.
El exploit necesita encontrar un puntero a algo montado en el host. El exploit original usó el archivo /.dockerinit y esta versión modificada usa /etc/hostname. Si el exploit no está funcionando, tal vez necesites establecer un archivo diferente. Para encontrar un archivo que esté montado en el host, simplemente ejecuta el comando mount:
![](https://book.hacktricks.xyz/~gitbook/image?url=https%3A%2F%2F2730383215-files.gitbook.io%2F%7E%2Ffiles%2Fv0%2Fb%2Fgitbook-x-prod.appspot.com%2Fo%2Fspaces%252FOGiU7XValBchYYDg6h1H%252Fuploads%252Fgit-blob-e8bf27d92631c9009d2613b4bac9f501b6290062%252Fimage%2520%28407%29%2520%281%29.png%3Falt%3Dmedia&width=768&dpr=4&quality=100&sign=d4e2edbc&sv=1)
El código de esta técnica fue copiado del laboratorio de "Abusing DAC_READ_SEARCH Capability" de https://www.pentesteracademy.com/
![](https://book.hacktricks.xyz/~gitbook/image?url=https%3A%2F%2Ffiles.gitbook.com%2Fv0%2Fb%2Fgitbook-x-prod.appspot.com%2Fo%2Fspaces%252F-L_2uGJGU7AVNRcqRvEi%252Fuploads%252FelPCTwoecVdnsfjxCZtN%252Fimage.png%3Falt%3Dmedia%26token%3D9ee4ff3e-92dc-471c-abfe-1c25e446a6ed&width=768&dpr=4&quality=100&sign=9c8fe74f&sv=1)
RootedCON 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.
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.
Hay muchos archivos que puedes sobrescribir para escalar privilegios, puedes obtener ideas de aquí.
Ejemplo con binario
En este ejemplo, vim tiene esta capacidad, por lo que puedes modificar cualquier archivo como passwd, sudoers o shadow:
Ejemplo con binario 2
En este ejemplo, el binario python
tendrá esta capacidad. Podrías usar python para sobrescribir cualquier archivo:
Ejemplo con entorno + CAP_DAC_READ_SEARCH (escape de Docker)
Puedes verificar las capacidades habilitadas dentro del contenedor de docker usando:
Primero que nada, lee la sección anterior que abusa de la capacidad DAC_READ_SEARCH para leer archivos arbitrarios 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, agregar a ellos un nuevo usuario, y usar shocker_write
para sobrescribirlos. Luego, acceder a través de ssh.
El código de esta técnica fue copiado del laboratorio de "Abusing DAC_OVERRIDE Capability" de https://www.pentesteracademy.com
CAP_CHOWN
Esto significa que es posible cambiar la propiedad de cualquier archivo.
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:
O con el binario ruby
teniendo esta capacidad:
CAP_FOWNER
Esto significa que es posible cambiar los permisos de cualquier archivo.
Ejemplo con binario
Si python tiene esta capacidad, puedes modificar los permisos del archivo shadow, cambiar la contraseña de root y escalar privilegios:
CAP_SETUID
Esto significa que es posible establecer el id de usuario efectivo del proceso creado.
Ejemplo con binario
Si python tiene esta capacidad, puedes abusar de ella muy fácilmente para escalar privilegios a root:
Otra forma:
CAP_SETGID
Esto significa que es posible establecer el id de grupo efectivo del proceso creado.
Hay muchos archivos que puedes sobrescribir para escalar privilegios, puedes obtener ideas de aquí.
Ejemplo con binario
En este caso, deberías buscar archivos interesantes que un grupo pueda leer porque puedes suplantar cualquier grupo:
Una vez que hayas encontrado un archivo que puedes abusar (mediante lectura o escritura) para escalar privilegios, puedes obtener un shell impersonando al grupo interesante con:
En este caso, se impersonó al grupo shadow, por lo que puedes leer el archivo /etc/shadow
:
Si docker está instalado, podrías suplantar el grupo docker y abusar de él para comunicarte con el socket de docker y escalar privilegios.
CAP_SETFCAP
Esto significa que es posible establecer capacidades en archivos y procesos
Ejemplo con binario
Si python tiene esta capacidad, puedes abusar de ella muy fácilmente para escalar privilegios a root:
Tenga en cuenta que si establece una nueva capacidad en el binario con CAP_SETFCAP, perderá esta capacidad.
Una vez que tenga la capacidad SETUID, puede ir a su sección para ver cómo escalar privilegios.
Ejemplo con entorno (Docker breakout)
Por defecto, la capacidad CAP_SETFCAP se otorga al proceso dentro del contenedor en Docker. Puede verificar eso haciendo algo como:
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 salidas 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 darlas, pero el binario no podrá ejecutarse después de esto:
From the docs: 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, 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 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. 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
.
Esto puede ser útil para escalada de privilegios y escape de Docker.
CAP_KILL
Esto significa que es posible matar cualquier proceso.
Ejemplo con binario
Supongamos que el python
binario tiene esta capacidad. Si pudieras también modificar alguna configuración de servicio o socket (o cualquier archivo de configuración relacionado con un servicio), podrías ponerle un backdoor, y luego matar el proceso relacionado con ese servicio y esperar a que se ejecute el nuevo archivo de configuración con tu backdoor.
Privesc con kill
Si tienes capacidades de kill y hay un programa node ejecutándose como root (o como un usuario diferente), probablemente podrías enviarle la señal SIGUSR1 y hacer que abra el depurador de node al que puedes conectarte.
![](https://book.hacktricks.xyz/~gitbook/image?url=https%3A%2F%2Ffiles.gitbook.com%2Fv0%2Fb%2Fgitbook-x-prod.appspot.com%2Fo%2Fspaces%252F-L_2uGJGU7AVNRcqRvEi%252Fuploads%252FelPCTwoecVdnsfjxCZtN%252Fimage.png%3Falt%3Dmedia%26token%3D9ee4ff3e-92dc-471c-abfe-1c25e446a6ed&width=768&dpr=4&quality=100&sign=9c8fe74f&sv=1)
RootedCON 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.
CAP_NET_BIND_SERVICE
Esto significa que es posible escuchar en cualquier puerto (incluso en los privilegiados). No puedes escalar privilegios directamente con esta capacidad.
Ejemplo con binario
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 privilegios específicos)
CAP_NET_RAW
CAP_NET_RAW 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.
Ejemplo con binario
Si el binario tcpdump
tiene esta capacidad, podrás usarlo para capturar información de la red.
Nota que si el entorno está otorgando esta capacidad, también podrías usar tcpdump
para espiar el tráfico.
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/
CAP_NET_ADMIN + CAP_NET_RAW
La capacidad CAP_NET_ADMIN otorga al titular el poder de alterar configuraciones de red, incluyendo configuraciones de firewall, tablas de enrutamiento, permisos de socket y configuraciones de interfaces de red dentro de los espacios de nombres de red expuestos. También permite activar el modo promiscuo en las interfaces de red, lo que permite la captura de paquetes a través de los espacios de nombres.
Ejemplo con binario
Supongamos que el binario de python tiene estas capacidades.
CAP_LINUX_IMMUTABLE
Esto significa que es posible modificar los atributos del inode. No puedes escalar privilegios directamente con esta capacidad.
Ejemplo con binario
Si encuentras que un archivo es inmutable y python tiene esta capacidad, puedes eliminar el atributo inmutable y hacer que el archivo sea modificable:
Tenga en cuenta que generalmente este atributo inmutable se establece y se elimina utilizando:
CAP_SYS_CHROOT
CAP_SYS_CHROOT permite la ejecución de la llamada al sistema chroot(2)
, lo que puede permitir potencialmente la fuga de entornos chroot(2)
a través de vulnerabilidades conocidas:
CAP_SYS_BOOT
CAP_SYS_BOOT 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_SYSLOG
CAP_SYSLOG 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.
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 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:
S_IFCHR: Archivos especiales de caracteres, que son dispositivos como terminales.
S_IFBLK: Archivos especiales de bloques, que son dispositivos como discos.
Esta capacidad es esencial para procesos que requieren la capacidad de crear archivos de dispositivo, facilitando la interacción directa con el hardware a través de dispositivos de caracteres o bloques.
Es una capacidad predeterminada de docker (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:
Tener acceso inicial al host (sin privilegios).
Tener acceso inicial al contenedor (privilegiado (EUID 0), y efectivo
CAP_MKNOD
).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:
En el Host como un Usuario Estándar:
Determina tu ID de usuario actual con
id
, por ejemplo,uid=1000(standarduser)
.Identifica el dispositivo objetivo, por ejemplo,
/dev/sdb
.
Dentro del Contenedor como
root
:
De vuelta en el Host:
Este enfoque permite al usuario estándar acceder y potencialmente leer datos de /dev/sdb
a través del contenedor, explotando los espacios de nombres de usuario compartidos y los permisos establecidos en el dispositivo.
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
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.
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.
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.
Referencias
La mayoría de estos ejemplos fueron tomados de algunos laboratorios de https://attackdefense.pentesteracademy.com/, así que si quieres practicar estas técnicas de privesc, te recomiendo estos laboratorios.
Otras referencias:
![](https://book.hacktricks.xyz/~gitbook/image?url=https%3A%2F%2Ffiles.gitbook.com%2Fv0%2Fb%2Fgitbook-x-prod.appspot.com%2Fo%2Fspaces%252F-L_2uGJGU7AVNRcqRvEi%252Fuploads%252FelPCTwoecVdnsfjxCZtN%252Fimage.png%3Falt%3Dmedia%26token%3D9ee4ff3e-92dc-471c-abfe-1c25e446a6ed&width=768&dpr=4&quality=100&sign=9c8fe74f&sv=1)
RootedCON 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.
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Learn & practice GCP Hacking:
HackTricks Training GCP Red Team Expert (GRTE)
Last updated