# InsanityHosting

## Enumeración ### Enumeración de servicios abiertos Comenzamos la resolución de esta nueva máquina enumerando que servicios tiene abiertos el objetivo. Primero realizamos el escaneo rápido de servicios. ``` nmap -p- --open --min-rate 2000 -Pn -n 192.168.248.124 ```

Tres puertos abiertos: 21, 22 y 80. Seguimos con la enumeración profunda de estos servicios. ``` nmap -p21,22,80 -sVC -Pn -n 192.168.248.124 ```

Destacable, podemos iniciar sesión de manera anónima en el servidor FTP. Servicios abiertos * Puerto 21 -> FTP -> vsftpd 3.0.2 * Puerto 22 -> SSH -> OpenSSH 7.4 * Puerto 80 -> HTTP -> Apache httpd 2.4.6 ### Enumeración FTP El sistema víctima está ejecutando un servidor FTP, en el cual podemos iniciar sesión de manera anónima. Veamos si contiene información interesante.

Encontramos un directorio "pub", en el cual no hay nada interesante. ### Enumeración Web En la máquina objetivo se está ejecutando un servidor Web en el puerto 80. Vamos a ver que contiene y a enumerar sus directorios y archivos.

Vamos a enumerar directorios y archivos interesantes que nos permitan avanzar en la resolución de la máquina. ``` dirsearch -u "http://192.168.248.124/" -i 200,301 -t 20 ```

Hay múltiples directorios que pueden ser interesantes. En el directorio /news, encontramos un posible nombre de usuario de sistema.

Encontramos también un Panel de phpmyadmin para el cual no tenemos credenciales.

Y un login de inicio de sesión.

Y otro login de sesión, en este caso parece que para un servidor Mail. Tenemos un nombre de usuario, y un par de paneles de login. Vamos a realizar un pequeño ataque de fuerza bruta con Burp Intruder sobre estos logins.

Aunque todas las configuraciones de usuario y contraseña devuelven resultado 302, si analizamos las respuestas a las peticiones, vemos que la contraseña 123456 nos redirige a "index.php" mientras que las demás se quedan en "login.php".

Tenemos unas credenciales, otis:123456. Volvemos al login e intentamos iniciar sesión.

Accedemos a un Panel de Control con las credenciales obtenidas. Vamos a tratar de iniciar sesión también en el otro login de inicio de sesión en el servidor Mail con las mismas credenciales anteriores.

Credenciales válidas. ## Explotación Vamos a crear un servidor con una IP erronea y vemos la respuesta, que se envía al servidor Mail.

Viendo la respuesta obtenida, parece que la información se extrae de la base de datos del sistema. ¿Podría existir una vulnerabilidad de SQLi? Vamos a comprobarlo.

Existe una vulnerabildad de SQLi. Vamos a obtener el nombre de la base de datos y el nombre de usuario. ``` " union select 1,2,database(),user()# ```

Obtenemos la lista de bases de datos. ``` " UNION SELECT NULL, NULL, NULL, SCHEMA_NAME FROM information_schema.SCHEMATA; # ```

Veamos el contenido dentro de la base de datos "monitoring" ``` a" UNION SELECT group_concat(table_name),2,3,4 FROM information_schema.tables where table_schema = 'monitoring' -- - ```

Veamos que información contiene la tabla "users" ``` " UNION SELECT group_concat(column_name),2,3,4 FROM information_schema.columns where table_name = 'users' -- - ```

``` " UNION SELECT group_concat(username),group_concat(password),group_concat(email),4 FROM monitoring.users -- - ```

Obtenemos varios nombres de usuarios con hashes aparentemente de contraseñas. Vamos a repetir el mismo proceso anterior también para la base de datos "mysql".

Y volvemos a encontrar más usuarios con sus respectivos hashes de contraseñas. Vamos a tratar de descifrar todos los hashes para obtener credenciales que podamos utilizar. De los hashes obtenenidos de la base de datos "mysql" encontramos una coincidencia para el usuario "elliot".

Vamos con los otros hashes. Pero no obtenemos resultados positivos para ningún hash.

## Acceso como usuario "elliot" Anteriormente, encontramos unas credenciales para el usuario "elliot" y la máquina objetivo ejecuta un servicio SSH en el puerto 22. Vamos a probar si las credenciales elliot:elliot123 son válidas. PD: Cambiamos de IP por reinicio de la máquina.

Buscamos la flag local.txt

## Elevación de privilegios Una vez tomamos acceso al sistema como usuario "elliot", el siguiente paso será intentar obtener privilegios máximos dentro del sistema. Mientras enumerabamos anteriormente para buscar la flag local.txt, en el directorio del usuario "elliot" encontramos una carpeta .mozilla que no es común. Veamos su contenido.

Dentro de firefox encontramos un directorio que contiene diferentes archivos .db, cache... relacionados con el navegador Web.

Copiamos esta carpeta a nuestra máquina de ataque. ``` scp -r elliot@192.168.170.124:/home/elliot/.mozilla/firefox/esmhp32w.default-default/ /home/kali/Desktop/provinggrounds/insanityhosting ```

Existe un tool que podemos descargar [aquí](https://github.com/unode/firefox_decrypt), que sirve para descifrar estos archivos descargados y extraer entre otras cosas credenciales almacenadas en el navegador. ``` python3 firefox_decrypt.py /home/kali/Desktop/provinggrounds/insanityhosting/esmhp32w.default-default ```

Obtenemos las credenciales root:S8Y389KJqWpJuSwFqFZHwfZ3GnegUa. ¿Serán las credenciales del usuario "root"? Vamos a comprobarlo.

Obtenemos acceso al sistema con privilegios máximos. Solo queará buscar la flag proof.txt para terminar la resolución de este CTF.

{% embed url="" %}