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

Resumen de conceptos trabajados:

Escaneo de Puertos
Reconocimiento Web
Fuzzing Web
Fuerza Bruta
Acceso SSH

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 (opcional), 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 OpenSSH ni de Apache:

RECONOCIMIENTO WEB

En este punto, continuaremos con la investigación del puerto 80 web.

Analizamos la web en búsqueda de información sensible que nos pueda dar pistas de intrusión…

  • Menú con enlaces ancla
  • Robots.txt
  • Código fuente
  • un correo con un posible usuario a marcar «silvio«, y un dominio para probar por virtual hosting «delacal.com.ar» (devuelve el mismo contenido que la IP).
  • directorios /descargas y /img
  • Botón de «descargas» que apunta a http://172.17.0.2/descargas.html que profundizamos.

Información que podemos extraer con whatweb:

FUZZING WEB

A partir de aquí vamos a profundizar en el análisis, buscando directorios que puedan tener expuesta información sensible.

Usaremos GOBUSTER para hacer fuzzing web y buscar directorios que contengan las extensiones más típicas:

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

Encontramos directorios interesantes como:

  • /index.php => apunta a la página por defecto.
  • /img/ => solo un listado de imágenes subidas
  • /index1.html => devuelve una página de «Apache2 Debian Default Page».
  • /descargas.html => página con enlaces de descargas de software externos.
  • /pass.txt

Buscamos dentro del directorio /pass.txt y encontramos 3 usuarios y lo que parecen ser sus contraseñas en base 64:

Si las decodificamos tenemos las creds:

Teniendo cada usuario y contraseña, lo añadimos a dos ficheros txt con los usuarios y las passwords para hacer un ataque por fuerza bruta al ssh:

FUERZA BRUTA

Aplicamos fuerza bruta con Hydra

Ahora si intento acceder como root por ssh, me salta este mensaje de error, pero eso ocurre cuando la clave del host SSH en known_hosts ha cambiado, lo que puede deberse a que la máquina objetivo se ha reiniciado, ha cambiado su clave SSH o ha sido reemplazada por otra instancia.

ACCESO SSH

Para corregirlo, ejecutar este comando:

ssh-keygen -f "/root/.ssh/known_hosts" -R "172.17.0.2"

Una vez corregido, accedemos a root de nuevo por ssh con la pass anterior, y ya somos root.

RESUMEN

Para resolver la máquina sjd en Dockerlabs, comenzamos identificando que estaba activa y ejecutaba un sistema Linux mediante un escaneo con nmap, que reveló dos puertos abiertos: 22 (SSH) y 80 (HTTP).

Luego, exploramos el sitio web en el puerto 80 con whatweb y gobuster, descubriendo directorios interesantes como /img/ (conteniendo imágenes públicas) y /descargas.html. Posteriormente, refinamos la búsqueda incluyendo archivos .txt y encontramos /pass.txt, el cual contenía credenciales en formato Base64.

Decodificamos estas credenciales y las organizamos en archivos users.txt y creds.txt, permitiéndonos ejecutar un ataque de fuerza bruta en SSH con hydra, logrando acceso exitoso con los usuarios sjd, admin y root.

Tras conectarnos por SSH con ssh root@172.17.0.2 usando la contraseña encontrada, nos aseguramos de tener acceso completo al sistema verificando con whoami.

Otros posts relacionados