WWBuddy - TryHackMe

August 16, 2023  

SUMMARY

Debemos encontrar una bandera en la maquina WWBuddy. Donde a partir del escaneo de puertos de Nmap pude saber que hay un servicio HTTP, SSH.Además, con un script de Nmap supe que hay una aplicación web. Luego, esta aplicación web constaba con la función Change password que era vulnerable a SQLi, que me permitió cambiar las contraseñas de los administradores de la aplicación web. Luego, realice una fuerza bruta de directorios sobre el directorio raíz del servidor web con gobuster, llegando a encontrar recurso escondido que me permitió explotar la vulnerabilidad Command Injection para obtener acceso al sistema destino. Luego, mediante la herramienta linpeas puede saber que el sistema destino presentaba la vulnerabilidad Baron Samedit, llegando a explotarla y ser root. Además, encontré unas credenciales almacenadas en los registros, llegando a ser el usuario Roberto. Luego, realice un cracking de contraseñas onlinea mediante la herramienta hydra contra el servicio SSH llegando a obtener las credenciales del usuario Jenny. Luego, realice una manipulación del valor de la variable de entorno USER, encontrando otra manera de ser root.

FASE RECONOCIMIENTO ACTIVO

Empezaremos utilizando el comando openvpn con el fin de establecer una conexión VPN con la red virtual dónde está la máquina WWBuddy. Para ello utilizaremos el archivo de configuración, que lo podemos descargar en la plataforma de Tryhackme, que puede incluir información como la dirección del servidor VPN, los certificados y claves de seguridad, la configuración de encriptación, etc.

Luego de que se establece la conexión VPN se crea una interfaz virtual de red en nuestra máquina. Donde se enruta todo el tráfico de red a través de esa interfaz.

Además, la plataforma de Tryhackme nos muestra la dirección ip de la máquina WWBuddy.

FASE ESCANEO Y ENUMERACION

Luego pasaremos a la fase de Escaneo y Enumeración con el fin de poder escanear los puertos del nodo. Además, obtendremos los servicios que se han levantado en los puertos abiertos, las versiones de los servicios, y el sistema operativo de la máquina WWBuddy. Para ello utilizaremos Nmap. Donde le pasaremos los siguientes parámetros:

• El parámetro -sC o –script=”default” para utilizar todos los scripts de la categoría default con el fin de realizar un escaneo y detección de los puertos de manera avanzada.
• El parámetros -sV con el fin de conocer las versiones de los servicios levantados en los puertos abiertos.
• El parámetro -n para evitar la resolución DNS, y el parámetro –max-rate para indicarle el número máximo de paquetes por segundo que va a utilizar Nmap para el escaneo con el fin de evitar sobrecargar la red con el tráfico generado por la herramienta.
• El parámetro -p- para realizar un escaneo de los 65535 puertos del nodo y el parámetro –open con el fin de que nos muestre información solo de los puertos abiertos.

Los resultados que obtuvimos del escaneo vienen a ser:

• Hay un servicio HTTP que se está levantado en el puerto 80, y el programa servidor HTTP que se está corriendo. Además, la versión del programa servidor
• Hay un servicio SSH que se está levantado en el puerto 22, y el programa servidor SSH que se está corriendo. Además, la versión del programa servidor SSH.
• A través del script http-title.nse de Nmap se pudo capturar el valor de la etiqueta o elemento HTML title, que viene a ser el titulo de una pagina web almacena servidor web.

Ahora, observamos la página web desde mi navegador web.

Podemos observar que el recurso que llego a encontrar el script de Nmap viene a ser un formulario o HTML. Además, llegamos a observar la etiqueta HTML a cuyo atributo href contiene un enlace que me redirige a otra pagina web que viene a ser un registro para que podamos crear una cuenta en la aplicación web.

Ahora intentaremos omitir la autenticación del formulario HTML, ingresando la siguiente consulta SQL en cualquiera de los dos parámetros del formulario.

Podemos observar que no llegamos omitir la autenticación ya que lo mas probable es que se utilice declaraciones preparadas o consultas parametrizadas con el fin de que a través de marcadores de posición evitar que las entradas del usuario se concatenen con la consulta SQL que realizara el sitio web hacia su base de datos par la autenticación.

Ahora crearemos una cuenta en el registro de la aplicación web con el fin de acceder al portal de la aplicación web.

Podemos observar que llegamos acceder al portal de la aplicación web. Donde podemos observar que la aplicación web es algo similar a Facebook ya que nos permite chatear con nuestra lista de contactos. Además, podemos editar la información de nuestro perfil, y poder observar los datos actualizados de nuestro perfil. Además, podemos observar un parámetro GET llamado uid en la URL de la página web donde podemos observar los datos de nuestro perfil.

FASE GANAR ACCESO O EXPLOTACION O HACKING

Ahora veremos si este parámetro GET es vulnerable a SQLi con el fin de inyectarle consultas SQL maliciosos y obtener información sobre las bases de datos que utiliza la aplicación web. Para ello utilizaremos la herramienta automatizada sqlmap. Además, especificaremos nuestras cookies de nuestra sesión.

Podemos observar que la herramienta nos dice que el parámetro GET uid no es vulnerable a SQLi, y por mas que esperemos no obtendremos nada.

Ahora si intentamos enviarnos un mensaje a nosotros mismos nos encontramos con un parámetro GET send en la URL, lo mas probable es que la aplicación web realice una consulta SQL hacia sus bases de datos con el fin de poder mostrar los mensajes del chat.

Ahora veremos si este parámetro GET es vulnerable a SQLi con el fin de inyectarle consultas SQL maliciosos y obtener información sobre las bases de datos que utiliza la aplicación web. Para ello utilizaremos la herramienta automatizada sqlmap. Además, especificaremos nuestras cookies de nuestra sesión.

Podemos observar que la herramienta nos dice que el parámetro GET uid no es vulnerable a SQLi, y por más que esperemos no obtendremos nada.

Ahora probaremos si la aplicación web es vulnerable a XXS ya que el username de nuestra cuenta se puede observar en varias partes del código fuente de la aplicacion web. Además, los usuarios para que puedan enviarnos mensajes van a tener que interactuar con nuestro perfil donde aparecerá nuestro username.

Empezaremos con un payload XSS sencillo, que nos generara una ventana emergente con el mensaje XSS en el caso de que sea vulnerable a XSS, y lo ingresaremos como nuestro username al momento de que creemos una nueva cuenta en el registro de la aplicación web.

Podemos observar que no se obtuvo la ventana emergente con el mensaje XSS. Por lo tanto, nuestro payload XSS no se ha ejecutado y la razón lo podemos ob el código fuente de la aplicación web. Donde podemos notar que la aplicación web está utilizando la operación de escape o codificación de caracteres con el fin navegadores web convierten los caracteres especiales como <, >, & en sus entidades HTML con el fin de que no se interpreten como código JavaScript, y no se

Ahora podemos observar que la aplicación web consta de la función cambiar contraseñas que puede ser vulnerable a SQLi ya que puede darse el caso de que e desarrollador haya olvidado utilizar marcadores de posición para el parámetro, que hace referencia a nuestro username y que contiene su valor, por lo que su va concatenara con la consulta SQL que realizara la aplicación web para actualizar el registro en la base de datos en el momento de que cambiemos nuestra contra

Aprovechando esto, podemos cambiar la contraseña de otro usuario como el del usuario WWBuddy, que al parecer viene a ser un Bot. Para ello nos crearemos cuenta con el username igual a WWBuddy’; – -. Luego, cambiaremos la contraseña de esta cuenta con el fin de que al momento de que la aplicación web realic consulta SQL con la cláusula UPDATE, se actualice la contraseña del usuario WWBuddy.

Podemos observar que se llego a cambiar la contraseña del usuario WWBuddy ya que la función cambiar contraseña es vulnerable a SQLi. Además, podemos o el panel del chat, que el bot WWBuddy también ha conversado con otros dos usuarios, que se han registrado y autenticado en la aplicación web.

Ahora intentaremos cambiar las contraseñas de los usuarios Henry y Roberto aprovechando que la función cambiar contraseña es vulnerable a SQLi, y con el fin acceder a sus cuentas.

Podemos observar que pudimos autenticarnos a la aplicación web utilizando las cuentas de los usuarios Henry y Roberto. Además, podemos observar que amb usuarios han establecido una conversación donde Roberto le indica a Henry que debería cambiar las credenciales de sus cuentas SSH ya que la fecha de cumpleaños como credencial no es segura. Además, en la conversación Roberto da entender que Roberto ya ha cambiado su contraseña para hacerla más segura.

Ahora intentaremos un cracking de contraseñas online sobre el servicio SSH en el sistema destino. Para ello utilizaremos Hydra y el diccionario que utilizaremos ataque de fuerza va a ser una lista de fechas en el formato: día/mes/año (Como se logra apreciar en la fecha de cumpleaños del usuario Henry). Para generar el diccionario utilizaremos el siguiente script en Python.

Después de haber esperado bastante tiempo, podemos observar que la herramienta no logra encontrar unas credenciales validas para el usuario Henry.

Ahora realizaremos fuerza bruta de directorios de una forma automatizada con la herramienta gobuster con el fin de encontrar recursos escondidos en el directorio raiz de la aplicacion web. Además, utilizaremos el parámetro -x para encontrar recursos escondidos con la extensión txt y php.

Podemos observar que la herramienta llego a encontrar un recurso nuevo escondido llamado admin.

Ahora accederemos al recurso desde mi navegador web.

Podemos observar que obtenemos un mensaje de que no tenemos los permisos para acceder al recurso, y que el intento va ser registrado en alguno del sistema pero si intentamos acceder al recurso siendo el usuario Henry, obtenemos el siguiente resultado.

Podemos observar que el recurso admin se trata de un tipo de registro, que registra los intentos no permitidos de acceder al recurso. Además, podemos observar que se registran los usernames de lo usuarios que intentaron acceder al recurso sin los permisos necesario. Podemos aprovechar esto para inyectar un comando PHP en el parámetro Username y luego intentar acceder al recurso admin con el fin de que se registre nuestro intento. Luego, accederemos al recurso admin siendo el usuario Henry para que el servidor web lo ejecute al momento de mostrarnos el contenido del recurso.

Para probar si la aplicación web presenta la vulnerabilidad Command Injection, utilizaremos el siguiente comando PHP.

Podemos observar que si se llego a ejecutar el comando PHP. Por lo tanto, el sitio web si presenta la vulnerabilidad Command Injection.

Ahora inyectaremos un comando, que nos generara una reverse Shell, en el parámetro Username con el fin de que quede registrado en el recurso admin, y sea ejecutado cuando accedemos a el siendo el usuario Henry, pero antes de acceder al recurso para que se ejecute nuestro comando, debemos habilitar el puerto 1800 en nuestro sistema para que este en escucha y esperando a la conexión entrante de la reverse Shell.

Podemos observar que llegamos acceder al sistema destino siendo el usuario www-data.

Además, podemos observar que al usuario www-data se le ha configurado para que utilice la Shell nologin cuando inicie sesión en el sistema destino. Esta Shell viene a ser no interactiva e inestable. Por lo tanto, realizaremos un tratamiento de la tty para tener una Shell estable e interactiva.

FASE ESCALADA PRIVILEGIOS

Ahora debemos buscar un vector de escalada de privilegios con el fin de ser un usuario con privilegios más elevados. Para ello utilizaremos la herramienta linpe nos automatiza el proceso de buscar vectores de escala de privilegios en el sistema destino. Esta herramienta lo puedes descargar en el siguiente enlace: https://github.com/carlospolop/PEASS-ng/releases/tag/20230413-7f846812.

Podemos observar que la herramienta linpeas llego a encontrar que el sistema objetivo puede presentar la vulnerabilidad Baron Samedit, que viene a ser un heap buffer overflow en el programa sudo y que permite una escalada de privilegios vertical permitiéndonos tener los privilegios del usuario root. Además, esta vulnerabilidad afecta al programa sudo en sus versiones 1.8.2-1.8.31p2.

Ahora comprobaremos si la versión del programa sudo en el sistema objetivo cae dentro de este rango.

Podemos observar que la versión del programa sudo si esta dentro del rango que se ven afectado por la vulnerabilidad.

Ahora con el siguiente comando podemos comprobar si de verdad el sistema objetivo presenta la vulnerabilidad Baron Samedit.

Podemos observar que el comando a sobrescrito el búfer de almacenamiento dinámico y bloqueo el programa. Por lo tanto, el sistema si es vulnerable a esta vulnerabilidad.

Ahora utilizaremos el siguiente exploit para explotar esta vulnerabilidad. Además, el exploit lo he obtenido de este repositorio: https://github.com/blasty/CVE-2021

Podemos observar que al ejecutar el exploit, nos piden que seleccione el tipo de sistema operativo que tiene el sistema destino. Para ello, podemos utilizar la informacion que nos provee linpeas sobre el sistema operativo del sistema destino. Luego, de especificar el tipo de objetivo mas cercano al sistema operativo del sistema destino, se nos generara una Shell con los privilegios del usuario root.

Otra manera que podemos optar para ser el superusuario root, seria tener en cuenta los resultados que la herramienta linpeas obtuvo de los registros del sistem

Podemos observar que el usuario Roberto ha realizado unas consultas SQL, pero en una de ellas parece ser que ha cometido un error ya que en ves de colocar solo su username ha colocado también su contraseña.

Ahora probaremos nuestra suposición intentando iniciar sesión siendo el usuario Roberto con esta supuesta credencial.

Podemos observar que nuestra suposición fue correcta, y llegamos a ser el usuario Roberto mediante una escalada de privilegios horizontal.

Ahora realizaremos un tratamiento de la tty para tener una Shell más estable e interactiva.

Ahora debemos encontrar otro vector de escalada de privilegios para ser un usuario con mayores privilegios. Para ello realizaremos una enumeración manual en los directorios del usuario Roberto.

Podemos observar que encontramos un archivo llamado importante en el directorio home del usuario Roberto. Además, su mensaje esta en portuges, y si realizamos una traducción al español, podemos obtener datos relevantes sobre la posible fecha de cumpleaños. Además, Para tener una idea sobre la posible de fecha de cumpleaños debemos conocer la fecha cuando se escribió este contenido en el archivo, es decir, la fecha de modificación. Para ello utilizaremos el siguiente comando.

Podemos observar que el día que escribió el mensaje en el archivo fue el 27 de Julio del 2020. A partir de esto, podemos deducir que la posible fecha de cumpleaños es 31 de Julio o 01 o 02 o 03 o 04 o 05 o 06 de Agosto del 2020. A partir de esto podemos crear un diccionario personalizado que contenga las posibles fechas de nacimiento con el fin de realizar un cracking de contraseñas teniendo en cuenta que las contraseñas por defecto de las cuentas SSH de los usuarios locales viene a ser la fecha de cumpleaños. Además, debemos tener en cuenta el formato de representación de la fecha de cumpleaños vista en la edición de los perfiles de la aplicación web.

Ahora realizaremos un cracking de contraseñas online usando la herramienta Hydra, y mediante el servicio SSH con el fin de obtener las credenciales del usuario local Jenny.

Podemos observar que la herramienta llego a encontrar las credenciales del usuario Jenny. Ahora nos autenticaremos mediante el servicio SSH en el sistema destino.

De esta manera obtuvimos acceso al sistema destino mediante una escalada de privilegios horizontal.

Ahora realizaremos un tratamiento de la tty para tener una Shell más estable e interactiva.

Ahora debemos encontrar otro vector de escalada de privilegios para ser un usuario con mayores privilegios. Para ello tendremos en cuenta otro resultado que llego a mostrarnos la herramienta lipneas viene a ser un archivo binario ejecutable desconocido con permiso SUID, cuyo propietario es el superusuario root.

Ahora intentaremos observar el código fuente del archivo binario con el fin de saber que comandos se ejecutan en segundo plano, es decir, su funcionamiento in

Pero podemos observar que el desarrollador del archivo binario ejecutable ha incurrido en el practica security throught obscurity con el fin de cifrar el código fuenente del archivo binario ejecutable y de esa manera poder evitar que sepan el funcionamiento interno del programa.

Ahora para poder observar el código fuente del programa utilizaremos ingeniería inversa mediante la herramienta Ghidra, que va primero realizar el desamblado, que consiste en tomar el código maquina representado en el archivo binario ejecutable y convertirlo en una representación legible. Luego, se realizará la decompilacion que consiste en convertir el código de maquina en un lenguaje de programación de alto nivel como C.

Podemos observar que llegamos a tener el código fuente del archivo binario ejecutable representado con lenguaje de programación C, utilizando la herramienta Ghidra y mediante ingeniería inversa. Ahora analizando el código fuente del archivo binario ejecutable:

1. Notamos que al inicio se obtiene el uid del usuario, quien ha ejecutado el archivo binario, mediante la función getuid.
2. Luego, verifica si el uid es menor a 1000, si ese es el caso entonces se imprime un mensaje, si no es así se utilizará la función system para ejecutar comandos en el sistema operativo del sistema destino con el fin de saber si el usuario, quien ha ejecutado el archivo binario, pertenece al grupo developer, si ese es el caso, entonces se imprime un mensaje, si no es así se utiliza la función getenv para obtener el valor del a variable de entorno USER.
3. Además, utiliza la función getuid para obtener el uid del usuario, quien ha ejecutado el archivo binario. Luego, utiliza la función setuid con el parámetro 0 con el fin de cambiar el UID efectivo del proceso a 0 y que pueda realizar los siguientes comandos con los privilegios del usuario root.
4. Luego, se establecen tres variables que se les va a asignar un valor hexadecimal, pero la variable local_48 contiene un valor hexadecimal que si lo representamos en código ASCCI viene a ser el nombre del comando usermod.
5. Luego, se utilizará la función strncat con el fin de concatenar el valor de la variable de entorno USER al valor de la variable local_48, y el resultado que se obtiene se almacena en la variable local_48.
6. Luego, se utiliza la función system para ejecutar el comando almacenado en la variable local_48.

En este punto nos damos cuenta de que el comando que ejecutara la función system va a depender del valor almacenado en la variable de entorno USER. Por ello podemos realizar una manipulación de esta variable de entorno para que cuando ejecutemos el archivo binario, se ejecute una Shell bash con los privilegios del superusuario root. Además, esto se podrá realizar con el usuario Jenny ya que su uid es mayor a 1000 y no pertenece a ningún grupo llamado developer.

Ahora le asignaremos el valor jenny; bash a la variable de entorno USER. Además, la clave del valor, que hemos asignado, esta en el uso del punto y coma ya que en muchos sistemas Unix/Linux, el punto y coma se utiliza para separar comandos en la misma línea con el fin de que el comando bash sea tomado en cuenta como otro comando por la función system del archivo binario ejecutable.

Podemos observar que se llego a modificar exitosamente el valor de la variable de entorno USER.

Ahora ejecutaremos el archivo binario ejecutable authenticate.

Podemos observar que llegamos a ser el superusuario root mediante una escalada de privilegios vertical.

Ahora observaremos la bandera contenida en el archivo root.txt Para localizar el archivo utilizaremos el comando find, y buscaremos desde el directorio /, archivos con sus nombres.