Patriaquerida | Dockerlabs [WriteUp]

En este writeup vamos a resolver una de las máquinas de la plataforma Dockerlabs llamada Patriaquerida, con el nivel de dificultad «Fácil».

Resumen de conceptos trabajados:

Escaneo de Puertos Reconocimiento Web Fuzzing Web Directory Traversal Escalada Privilegios por binarios SUID

Al final del write up te cuento un resumen de toda la máquina. 🙂

Si quieres conocer más sobre la plataforma Dockerlabs y ver cómo se configura, etc, en este post te cuento cómo hacerlo.

Básicamente los pasos son: 1) Crear una carpeta con el nombre de la máquina, 2) Descargar la máquina de Dockerlabs, 3) Descomprimirla y desplegarla.

Para todas las máquinas, la IP de Dockerlabs es siempre la misma: 172.17.0.2

Una vez hemos descargado la máquina víctima de Dockerlabs y desplegada en nuestro entorno, empezamos con el escaneo.

ESCANEO DE PUERTOS

Comenzamos primero viendo si la máquina está activa y podemos conectarnos a ella, y después continuamos con el descubrimiento de puertos para luego hacer un escaneo de los servicios y versiones que corren para esos puertos.

¿Está la máquina víctima activa y nos podemos comunicar con ella?

Aquí lo que haremos es ejecutar estos comandos para ver su el «host is up» y ver el SO.

nmap -sn 172.17.0.2

ping -c 1 172.17.0.2 -R

La explicación de los comandos sería:

-sn : realiza un Ping Scan para verificar que el host está activo sin intentar descubrir puertos.

ping: comprueba si la máquina víctima está conectada y responde en la red. Básicamente, manda un mensaje para ver si la máquina responde con un «¡Sí, estoy aquí!».

-c 1: aquí indicamos que solo queremos mandar un mensaje («un ping») en vez de muchos.

[IP de la máquina víctima]: dirección de la máquina víctima.

-R: este comando Trace Route indica que quieres rastrear la ruta que sigue el mensaje para llegar a la máquina víctima y volver.

En este caso el TTL es de 64 por lo que estamos antes una máquina Linux.

A partir de aquí comenzamos con el escaneo de puertos con el siguiente comando:

sudo nmap -p- --open -sS --min-rate 5000 -vvv -n -Pn 172.17.0.2 -oG Escaneo

Se detectan los servicios web y ssh en los puertos 80 y 22.

Pasamos a ver las versiones de cada puerto abierto en busca de posibles exploits ya publicados:

nmap -sCV -p80,22 172.17.0.2

No se detectan a priori interesantes exploits para esa versión de cada servicio:

RECONOCIMIENTO WEB

Viendo que no hay nada relevante para estas versiones, pasamos a analizar la web desde el navegador en busca de -enlaces internos, -Robots.txt, -Plugins, versión web, etc.

Para ello usaremos Wappalyzer, Whatweb, etc.

Al incluir la IP en el navegador vemos que se devuelve una página estática de una página por defecto de Apache 2 Ubuntu.

Al pasarle algunas herramientas para extraer algo más de info de la página, vemos lo siguiente, aunque nada muy relevante a priori:

DESCUBRIMIENTO DE CARPETAS Y EXTENSIONES DE ARCHIVOS CON FUZZING

A partir de aquí vamos a hacer descubrimiento de directorios con GoBuster para encontrar posibles carpetas, subcarpetas y extensiones que puedan dar información sensible:

gobuster dir -u http://172.17.0.2/ -w /usr/share/wordlists/dirbuster/directory-list-lowercase-2.3-medium.txt -x php,pdf,html

Vemos que las rutas /index.php y /index.html devuelven un 200, pero sólo la .php devuelve un mensaje interesante:

Teniendo en cuenta el mensaje vamos a probar la ruta:

http://172.17.0.2/.hidden_pass

que nos devuelve una credencial que puede ser usuario o contraseña, «balu».

Visto ya el fuzzing y que encontramos esto, ahora vamos a utilizar la herramienta Nikto que se encarga de realizar escaneos de vulnerabilidades en servidores web.

Su objetivo principal es detectar configuraciones inseguras, archivos sensibles y vulnerabilidades conocidas en el servidor web o sus aplicaciones.

DIRECTORY TRAVERSAL

En nuestro caso, como no hemos encontrado nada más en el servidor web (Apache), con Nikto podríamos descubrir:

1. Archivos sensibles o configuraciones inseguras:
   • Por ejemplo, si el servidor tiene archivos como phpinfo.php o directorios como /backup accesibles públicamente.
2. Errores de configuración:
   • Por ejemplo, si Apache permite métodos HTTP inseguros como PUT o DELETE.
3. Vulnerabilidades específicas:
   • Si Apache 2.4.41 tiene algún exploit conocido que puedas aprovechar.

Descubrimiento de rutas vulnerables: El archivo index.php parece tener un parámetro llamado page que podría ser vulnerable a un Directory Traversal. Esto permitiría leer archivos sensibles en el sistema.

/index.php?page=../../../../../../../../etc/passwd

Si probamos a acceder a esa ruta en el navegador, nos encontramos con:

http://172.17.0.2/index.php?page=../../../../../../../../../../etc/passwd

Al analizar el archivo /etc/passwd , vemos que la mayoría de los usuarios como daemon, bin, nobody, etc., son cuentas de sistema que no permiten login directo (/usr/sbin/nologin).

Sin embargo, encontramos 3 usuarios relevantes:

• root: Usuario administrador.
• pinguino: Usuario con un directorio /home/pinguino.
• mario: Otro usuario con un directorio /home/mario.

Ahora tenemos 3 usuarios y una posible contraseña que podemos probar por ssh.

NOTA: si al intentar entrar por ssh os salta ese aviso,

es porque ya has iniciado sesión por ssh en otra máquina anterior, y lo que hay que hacer es eliminar esa parte, y ya te dejará con:

ssh-keygen -f '/home/kali/.ssh/known_hosts' -R '172.17.0.2'

Después de probar con mario y root, accedemos con «pinguino» y contraseña «balu».

Una vez dentro, vemos un archivo con la contraseña de «mario» que es «invitaacachopo».

En este punto, tenemos los usuarios pinguino y mario, con las contraseñas balu y invitaacachopo , sin embargo nos falta la de root, por lo que voy a intentar conectarme como usuario mario para ver si encuentro desde ahí la pass de root…

No vemos archivos relevantes, y al parecer el usuario mario no tiene permisos para usar sudo…

Intentamos buscar binarios SUID que nos permitan ejecutar procesos con los permisos del propietario, que en algunos casos es root. Para ello ejecutamos:

find / -perm -u=s -type f 2>/dev/null

y tenemos este listado:

ESCALADA DE PRIVILEGIOS POR BINARIOS SUID

Vemos que python3.8 tiene permiso SUID activado, es decir, que si se ejecutase este binario, se podría operar con privilegios de root.

Si vamos a consultar en GTFObins las formas de cómo podemos abusar de binarios comunes como SUID en Python para escalar privilegios, nos encontramos con:

que si lo adaptamos a nuestro caso en python3.8, sería:

/usr/bin/python3.8 -c 'import os; os.setuid(0); os.system("/bin/bash")'

• os.setuid(0): Cambia el ID de usuario del proceso a 0, que corresponde al usuario root.
• os.system("/bin/bash"): Lanza una shell interactiva, pero esta vez con los privilegios de root gracias al cambio de UID.

Y entonces ya estaríamos accediendo a la shell como root.

RESUMEN Primero, realizamos un escaneo de puertos con nmap y descubrimos que la máquina tenía abiertos los puertos 22 (SSH) y 80 (HTTP). Al explorar el servidor web, encontramos una pista que mencionaba un archivo oculto (.hidden_pass), al cual accedimos y obtuvimos la contraseña balu. Posteriormente, descubrimos que el archivo index.php era vulnerable a un ataque de Directory Traversal, lo que nos permitió leer el archivo /etc/passwd y encontrar usuarios del sistema, específicamente pinguino. Con las credenciales pinguino:balu, logramos conectarnos por SSH como este usuario. Una vez dentro, enumeramos archivos y descubrimos una nota que revelaba la contraseña del usuario mario: invitaacachopo. Al conectarnos como mario, buscamos binarios con permisos especiales (SUID) y encontramos que el binario python3.8 estaba configurado para ejecutarse con privilegios de root. Siguiendo las instrucciones de GTFOBins, ejecutamos un comando con Python que nos otorgó una shell como root. Esto nos dio control total del sistema.