Pivoting into Docker containers

Cuando se obtiene una shell en un host Linux, es habitual descubrir que algunos servicios no corren en el propio host sino dentro de contenedores Docker. Cada contenedor tiene su IP interna (en la red puente por defecto, el rango 172.17.0.0/16, siendo 172.17.0.1 el host y 172.17.0.2, .3, ... los contenedores) y suele exponer puertos que no están publicados hacia fuera. Ese plano de red interno es terreno fértil: aplicaciones sin autenticación reforzada, versiones viejas, backups.

Descubrir contenedores y puertos. Sin herramientas instaladas, basta bash. Un barrido de ping encuentra IPs vivas en el rango del puente:

for i in $(seq 1 255); do ping -c1 -W1 172.17.0.$i | grep "bytes from" & done

Y un barrido de puertos contra una IP usando el pseudo-dispositivo /dev/tcp de bash (no hace falta nmap en la víctima):

for p in $(seq 1 65535); do (echo > /dev/tcp/172.17.0.2/$p) 2>/dev/null && echo "abierto: $p"; done

Llegar al servicio. El puerto del contenedor (p. ej. 172.17.0.2:5000) no es accesible desde nuestra máquina atacante. Se resuelve con un reenvío de puertos sobre SSH, de modo que un puerto local nuestro hable con el servicio interno:

ssh -L 5001:172.17.0.2:5000 usuario@objetivo   # ahora 127.0.0.1:5001 -> contenedor:5000

Qué buscar dentro. Una vez con shell en el contenedor (por ejemplo tras un RCE en la app que aloja), el botín suele estar en el /datastore o directorio de datos de la aplicación: ficheros de configuración, backups exportables y credenciales. Esos secretos a menudo sirven para volver al host por reutilización de credenciales (un su o un SSH con la contraseña hallada).

Salvedad. Tener root dentro de un contenedor no es root en el host: el contenedor está aislado salvo configuración insegura (montajes sensibles, --privileged, socket de Docker expuesto). El pivote típico de laboratorio no es escapar del contenedor, sino extraer credenciales de él y reutilizarlas contra el host.

Cómo detectarlo. La firma es de reconocimiento interno desde un host ya comprometido: un barrido de ping y de puertos contra 172.17.0.0/16 genera cientos de conexiones efímeras y ARP/ICMP al rango del puente en muy poco tiempo (visible en netflow/conntrack o con auditd sobre las llamadas connect), un patrón que un servicio normal no produce. Le acompañan un túnel ssh -L desde el host (una sesión SSH con reenvío inusual) y lecturas de directorios de datos del contenedor (/datastore). La reutilización posterior de una credencial hallada deja un su/login anómalo en el host.

Defensa. No guardar secretos en backups accesibles dentro del contenedor; segmentar la red del puente; no exponer el socket de Docker; mantener actualizadas las aplicaciones contenedorizadas.