Injection | Dockerlabs [WriteUp]

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

Resumen de conceptos trabajados:

Escaneo de Puertos Inyección SQL Acceso SSH Escalada de Privilegios

Si quieres conocer más sobre la plataforma Dockerlabs y ver cómo se configura, etc, en este post te cuento cómo hacerlo. Como habrás visto también, la IP en Dockerlabs es siempre la misma: 172.17.0.2

Una vez hemos descargado en nuestra máquina la máquina víctima de Dockerlabs y desplegada en nuestro entorno siguiendo los pasos anteriores que menciono en el post, empezamos con el escaneo.

ENUMERACIÓN -> ESCANEO DE PUERTOS

Para asegurarme de que la máquina víctima está activa y puedo conectarme a ella, le lanzo o bien un PING con trace route o directamente un nmap, de esta forma:

ping -c 1 172.17.0.2 -R

La máquina responde con un TTL de 64 por lo que se trata de una máquina Linux.

La otra forma de verificar que la máquina está activa es mediante el comando -sn de nmap:

nmap -sn 172.17.0.2

El comando «-sn» indica a Nmap que haga un «Ping Scan» o «Host Discovery», es decir, Nmap solo identificará qué hosts están activos en la red, pero no intentará descubrir qué puertos están abiertos en esos hosts. Cuando usas el comando nmap -sn [rango de IP], Nmap enviará solicitudes ICMP Echo (ping), solicitudes TCP SYN a puertos 443, y solicitudes ARP si estás en una red local. Si alguno de estos intentos tiene éxito, Nmap marcará el host como activo «Host is up«.

Ahora que tenemos conexión a la máquina y está activa, pasamos a hacer un escaneo de puertos completo mediante los siguientes comandos de NMAP (ver resto aquí):

nmap -sCV -p- --open --min-rate 5000 -n -vvv -Pn 172.17.0.2 -oN Escaneo

mandamos los resultados del escaneo al fichero «Escaneo» y vemos los resultados:

Como vemos en la captura, se identifica como los puertos 22 y 80 están abiertos. El puerto 22 SSH (Secure Shell) de autenticación de usuarios y el puerto 80 HTTP web (no cifrado por HTTPS, que es el puerto 443), responden a peticiones del servidor.

En ese punto, yo suelo empezar a revisar qué usuarios y contraseñas puedo encontrar desde la web, antes de probar otras formas de acceder quizás mediante fuerza bruta con Hydra, etc.

Al acceder al 172.17.0.1 en firefox, me resuelve con un panel de autenticación, pero no he conseguido ver nada mirando código fuente, o lanzando un whatweb IP, etc.

Al no encontrar ninguna pista más, decido ver si la versión web del Apache donde se aloja la web tiene algún exploit público disponible en exploit-db.com , que pueda probar, y efectivamente para la plataforma OpenBDS se reporta un exploit de 2017 que afecta a versiones anteriores a la 6.0 de OpenBSD HTTPd, específicamente relacionado con un ataque de Denegación de Servicio (DoS) por agotamiento de memoria.:

Sin embargo creo que el ataque no va por aquí, tiene que ser más sencillo.

Inyección SQL login panel

Después de ver que el resultado del puerto 80 devuelve un panel de login, pienso de qué forma podría ser vulnerable o no a SQL Injection (además por el nombre de la máquina que ya me está dando la pista…).

Pruebo en este caso con este comando en el campo usuario:

admin' or 1=1-- -

contraseña (laquesea)

En la consulta de SQL el proceso en el back en de la BBDD sería:

• Al incluir en el campo de usuario lo siguiente: admin' or 1=1-- -
• La consulta SQL se modificaría a algo como esto: SELECT * FROM usuarios WHERE nombre = 'admin' or 1=1-- -' AND contraseña = 'contraseña_ingresada';


Es decir:

1. Dado que normalmente los sistemas solo necesitan que exista al menos un registro que cumpla la condición para conceder acceso, esta inyección SQL logra acceso sin necesidad de conocer la contraseña correcta.
2. Como 1=1 siempre es verdadero, la condición or 1=1 anula cualquier necesidad de que el nombre de usuario y la contraseña sean correctos.
3. La consulta SQL seleccionará todos los registros de la tabla usuarios donde el nombre sea «admin» o donde 1=1 (lo que significa que seleccionará todos los registros porque 1=1 siempre es verdadero).

Y la web me responde con el siguiente aviso:

http://172.17.0.2/acceso_valido_dylan.php

OK, ya tenemos user and pss: Dylan ; KJSDFG789FGSDF78

Acceso por SSH Credenciales

Sabiendo del escaneo de puertos de inicio que el 22 ssh de autenticación de usuarios está abierto, pasamos a validarnos con estas credenciales:

Escalada de Privilegios

En este punto, conociendo el usuario, vamos a conocer cuáles son los archivos a los que tiene acceso Dylan como root para poder escalar privilegios.

Añadimos este comando:

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

Con este comando buscamos en todo el sistema de archivos (/) cualquier archivo que tenga el bit setuid (-perm -4000) activado como sudo. Los errores generados durante la búsqueda, como aquellos causados por la falta de permisos para acceder a ciertos directorios, los redirigimos a /dev/null para no mostrarlos en la terminal.

El bit setuid en este archivo /usr/bin/env, permite que se ejecute con los privilegios del propietario (root), por ello vamos al repositorio de GTFObins para el binario env y buscamos para escalarlo con SUID: https://gtfobins.github.io/gtfobins/env/#sudo

De esa forma llegamos a acceder a root:

/usr/bin/env /bin/sh -p