Entrenando con Vulnhub - JANGOW: 1.0.1

4 minute read

Hola a tod@s!

De vez en cuando me dejo caer por Vulnhub para ver las nuevas máquinas que van sacando, para entrenar, más que nada. Esta la tenía en el tintero, así que al lío.

Descargamos la máquina virtual del repositorio. En el que encontrareis esta OVA para máquina virtual.

Una vez desplegada, vamos al lío. Nmap nos aporta un par de puertos (lo suyo es probar con todos, parámetro -p-). Los podemos ver a continuación, el 21 (ftp) y el 80 (http):

Comenzamos con el 80, en el raíz se muestra el directorio /site/:

Vemos el tipo de servidor web y sistema operativo que hay detrás, con ello, entramos y vemos el contenido que nos deja la propia web, para ver por donde podríamos avanzar.

Después de ver el código fuente de la página, lo interesante es una opción de Buscar que tiene la propia página:

Después de probar diferentes diccionarios y palabras vemos lo que se esconde:

Si introduces palabras, generalmente no te aporta una respuesta, o más bien, una página en blanco, ¿por qué?

Porque lo que hay que introducirle es un comando, ni más ni menos.

Este es su código fuente:

Tenemos una shell en esta página, comando que pongas, si existe y tienes privilegios para ejecutarlo, funcionará sin más.

Mientras, habíamos puesto otras herramientas a trabajar, por ej. Dirbuster :

Vemos un wordpress, o eso parece a priori. Pero por su contenido, es un directorio señuelo:

Si crees que es un Wordpress, te lías a lanzar wp-scan para sacar datos y pierdes algo de tiempo… pero por si acaso, miramos ese fichero “config.php” por si suena la flauta.

Se trata de la cadena de conexión a Base de Datos, nos apuntamos todo esto.

Comprobamos como en el puerto 3306, de la localhost hay un Mysql. Como vemos en la url.

netstat -antopu | grep LISTEN

Además del 21 y 80 que veíamos con Nmap, está el 22. Sin embargo, se encuentra filtrado. Habrá que buscarse la forma de acceder después.

Wfuzz detectó con uno de los diccionarios, el siguiente fichero:

Otro fichero de configuración, con otras credenciales. Lo mismo que antes, lo apuntamos.

De momento, tenemos un par de usuarios de Base de Datos y la misma contraseña.

Ahora probamos alguno de los usuarios en el FTP para saber si no sólo son usuarios de Base de Datos.

Podía verse este usuario directamente desde la web:

Genial, tenemos 1 usuario de sistema operativo, ya podríamos acceder por ssh, pero no lo tenemos directamente abierto para que accedamos, así que tendremos que buscar la manera.

Si alguno os preguntáis por qué no seguimos utilizando la shell vía web, esta es la respuesta, la limitación del usuario con el que accedemos:

Así que aprovechamos este FTP al que tenemos acceso para subir algún fichero que podamos aprovechar para proporcionarnos acceso al ssh o al Mysql que vimos previamente (si quisiéramos acceder a él).

Para ello, utilizaremos reGeorg . Con ello, crearemos un proxy socks en la máquina destino que nos permitirá acceder a cualquier puerto local de la máquina y que no esté accesible directamente.

Por un lado subimos el fichero “tunnel.nosocket.php”, que se encuentra ubicado dentro del directorio de reGeorg, al FTP como “tunnel.php”, en el directorio destino /tmp. Y le damos permisos para que el usuario www-data pueda copiarlo dentro de /site/. Filezilla es genial para esto. Con lectura para todos es suficiente.

Lo copiamos a su sitio:

Y ahora ya podemos acceder, mediante el proxy socks en el puerto 8080 de nuestro pc:

En el Putty , tenéis que configurarle el proxy socks (puerto 8080) y para dentro.

Comprobamos si lo hemos hecho bien, consultando el fichero de flag:

Ahora hay que escalar privilegios. Para saber lo que tendremos que buscar, antes vemos la versión de sistema operativo y kernel (lo habíamos hecho antes desde la misma shell):

Ubuntu 16.04.1 LTS con un kernel 4.4.0-31-generic. Hay multitud de herramientas que buscan vulnerabilidades de kernel, malas configuraciones, credenciales, etc.

Me puse a buscarlo a mano y encontré esta aplicación que me pareció curiosa:

Me llamó la atención porque lo vi en el histórico del usuario cuando accedí:

¿Otro señuelo?

Si lo abrimos con Ghidra , vemos una función xsh. Puede verse también key, arc4, etc. Me sonaba de haberlo visto antes.

Se trata de una utilidad que trata de evitar que los ficheros shell scripts estén accesibles directamente, para ello generan un binario (este binario, con el contenido del script cifrado), se descifra y ejecuta. Aquí os dejo una utilidad para obtener el código fuente del script original antes de cifrarlo.

Vemos como funciona.

Ahora tenemos en backup.sh el script que tratan de ocultar.

Antes de esto lo comprobé con strace, vi como se cargaba ese “cat” desde multitud de directorios

Dicho esto, pasamos a la vulnerabilidad que nos hace root de la máquina, seguro que no es la única, pero sí la primera que se prueba, siendo el sistema operativo y kernel que es, como no, Dirty Cow .

La máquina tiene gcc para que podamos compilarlo y ejecutarlo directamente.