Daily Budge - TryHackMe
SUMMARY
Debemos encontrar dos banderas en la maquina Daily Bugle. Donde a partir del escaneo de puertos de Nmap pude saber que hay un servicio HTTP, SSH, MariaDB. Además, con un script de Nmap supe que hay un sitio web almacenado en el servidor web, y que ha sido creado y esta siendo gestionado por el CMS Joomla. Además, a través del recurso joomla.xml pude saber la versión del CMS. Luego, buscando en Internet llegue a saber que esa versión del CMS es vulnerable a SQLi. Luego, explote su vulnerabilidad con sqlmap o con un script Python, encontrado en un repositorio GitHub, con el fin de enumerar información sobre las bases de datos. Llegando, a encontrar unas credenciales válidas para la autenticación en un formulario que me permitió acceder al portal de administración del CMS. Donde, cambie el código fuente de un archivo de un template con el fin de que me genere una reverse shell cuando lo ejecute. Llegando acceder al sistema destino. Luego, realice un escalda de privilegios horizontal mediante la búsqueda de unas credenciales en un archivo de configuración, encontrado en el directorio raíz del CMS. Luego, realice un escalada de privilegios vertical mediante el archivo binario yum, que podía ejecutarlo con los privilegios del usuario root.
FASE RECONOCIMIENTO ACTIVO
Para resolver este ejercicio empezaremos utilizando el comando openvpn con el fin de establecer una conexión VPN con la red virtual dónde está la máquina tokyo ghoul. Para ello utilizaremos el archivo de configuración, que lo podemos descargar en la plataforma deTryhackme, 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 tokyo ghoul.
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 tokyo ghoul. 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
- A partir del script http-generator.nse de Nmap llegamos a saber que hay un sitio web que ha sido creado y está siendo gestionado por el CMS Joomla.
- Además, se puede observar la lista de recursos o paginas web del sitio web, que han sido prohibido para que sean mostrados en los resultados de búsqueda de cualquier motor de búsqueda. También podemos observar la lista de recurso prohibidos, observando el contenido del archivo robots.txt a través del navegad
- Hay un servicio SSH, que esta levantado en el puerto 22, y el programa servidor SSH que se está corriendo. Además, la versión del programa servidor SSH
- El DBMS MariaDB que se está ejecutando en el sistema destino, y que esta levantado en el puerto 3306.
Ahora, observamos el sitio web, que ha sido creado mediante el CMS Joomla, desde mi navegador web.
Podemos observar que la pagina de inicio del sitio web presenta un login o formulario, y si intentamos insertar consultas SQL en los campos del login, no obtendremos respuesta. Además, podemos con la extensión Wappalyzer podemos verificar que el sitio web ha sido creado y esta siendo gestionado por el CMS Joomla.
Ahora accederemos al recurso /administrator , que ha sido prohibido de ser mostrado en los resultados de búsqueda de cualquier motor de busqueda.
Podemos observar que se trata de un login o formulario para acceder al portal de administración del CMS, y si intentamos insertar consultas SQL en los campos del login, no obtendremos respuesta.
Ahora buscaremos información en Internet sobre el CMS Joomla.
Donde llegamos a encontrar unas rutas de unos recursos que presenta el CMS Joomla con el fin de poder saber su versión.
Ahora accederemos a la ruta del recurso /administrator/manifests/files/joomla.xml a través de mi navegador web.
Podemos observar que la versión del CMS Joomla es 3.7.0.
Ahora buscaremos información en Internet sobre vulnerabilidades que presenta el CMS Joomla en su versión 3.7.0.
Podemos observar en el artículo( https://blog.sucuri.net/2017/05/sql-injection-vulnerability-joomla-3-7.html) que el CMS Joomla en su versión 3.7.0 es vulnerable a SQLi debido a que no sanatiza o valida adecuadamente los valores que se le insertan al parámetro GET list[fullordering], que presenta el componente com_fields.
Esto lo podemos verificar, accediendo a la ruta del recurso a través de mi navegador web, e insertando un carácter como ‘ o ‘’ en el valor del parámetro GET list[fullordering] con el fin de observar un mensaje de error enviado por el DBMS, que utiliza el sitio web y el CMS.
FASE GANAR ACCESO O EXPLOTACION O HACKING
Ahora, utilizaremos sqlmap con el fin de automatizar el proceso de explotación de la vulnerabilidad SQLi.
- Utilizaremos el parámetro –dbs con el fin de enumerar todas las bases de datos, que están siendo administradas y gestionadas por el DBMS, que utiliza el sitio web y el CMS.
- Especificaremos el parámetro GET list[fullordering], que permitirá insertar las consultas SQL maliciosas, mediante el parámetro -p.
- Utilizaremos el parámetro –level para indicar el nivel de profundidad con el que se realizara sqlmap las pruebas de inyección SQL.
- Utilizaremos el parámetro –risk para indicar el nivel de riesgo, que nos determina la cantidad y la agresividad de las pruebas de inyección SQL que sqlmap realizará durante la evaluación de la vulnerabilidad.
- Utilizaremos el parámetro -u para especificar el URL, que contiene el componente com_fields y el parámetro GET list[fullordering] vulnerables.
Podemos observar que sqlmap llego a enumerar 5 base de datos administrados por el DBMS del sistema destino.
Ahora enumeraremos las tablas de la base de datos Joomla.
- Utilizaremos el parámetro –tables con el fin de enumerar todas las tablas de la base de datos especificada.
- Utilizaremos el parámetro -D para indicar la base de datos de la cual enumeraremos sus tablas.
Podemos observar que sqlmap llego a enumerar 72 tablas de la base de datos Joomla.
Ahora enumeraremos las columnas de la tabla #__users.
- Utilizaremos el parámetro -T para especificar la tabla a cuál enumeraremos sus columnas.
- Utilizaremos el parámetro –columns para indicar que queremos enumerar las columnas de la tabla.
Podemos observar que sqlmap enumero las 6 columnas de la tabla #__users con los tipos de datos que almacena cada columna.
Ahora volcaremos todos los registros de todas columnas de la tabla #__users.
Podemos observar que sqlmap llego a volcar los registros de la columna. Donde encontramos las credenciales de un usuario que posiblemente es el administrador del CMS Joomla.
Otra manera que pudimos haber realizado para explotar la vulnerabilidad SQLi presente en el CMS Joomla es utilizando este script https://github.com/stefanlucas/Exploit-Joomla , cuyo código está en Python.
Podemos observar que, mediante la ejecución del script, llegamos a obtener todos los registros de la tabla #__users de una manera mas automatizada que a través de la herramienta sqlmap. Además, podemos observar que la contraseña del usuario jonah, esta en forma de hash.
Ahora, utilizaremos John the Ripper para poder crackear este hash y obtener la contraseña.
Podemos observar que John the Ripper llego a crackear el hash y obtuvimos la contraseña asociada con el username jonah.
Ahora probaremos estas credenciales de inicio de sesión en el formulario, que encontramos anteriormente, para acceder al portal de administración del CMS Joomla.
Podemos observar que llegamos acceder al portal de administración del CMS. Además, podemos observar que el CMS consta de dos templates, que vienen a ser plantillas o diseños predefinidos que definen como se mostrara el contenido front-end del sitio web.
Ahora aprovecharemos en modificar el código fuente del archivo error.php, que forma parte del template Protostar, con el fin de que sea un script que nos genere una reverse Shell cuando accedemos a él mediante nuestro navegador web.
Ahora que hemos modificado el contenido del código fuente del archivo error.php, solo necesitamos acceder a él mediante nuestro navegador web para que el servidor web lo ejecute, y nos genere una reverse Shell, pero antes debemos habilitar el puerto 1500 en nuestro sistema para que este escuchando y esperando la conexión entrante generada por la reverse Shell.
Podemos observar que llegamos acceder al sistema destino siendo el usuario apache.
Además, podemos observar que al usuario apache 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 buscaremos credenciales en los archivos de configuración en el directorio raíz del CMS y del sitio web.
Podemos observar que llegamos a encontrar un archivo de configuración llamado configuration.php, que contiene dos posibles passwords: nv5uz9r3ZEDzVjNu y UAMBRWzHO3oFPmVC. Además, para ser credenciales para ingresar al servidor de base de datos, que se está ejecutando en el sistema destino y utilizando en el sitio web y en el CMS.
Ahora probaremos estas credenciales para acceder al servidor de base de datos.
Podemos observar que llegamos acceder al servidor de base de datos, y podemos enumerar todas las bases de datos, que listamos anteriormente.
Ahora probaremos si el administrador del sistema objetivo ha reutilizado sus credenciales para acceder al servidor de base de datos con las credenciales de inicio de sesión al sistema destino.
Podemos observar que la credencial nv5uz9r3ZEDzVjNu viene a ser la credencial de inicio de sesión del usuario local jjameson.
De esta manera llegamos a ser el usuario jjameson mediante una escalada de privilegios horizontal.
Ahora debemos buscar un vector de escalada de privilegios con el fin de ser un usuario con privilegios más elevados. Para ello enumeraremos los comandos y programas que puede ejecutar el usuario jjameson con los privilegios del usuario root.
Podemos observar que el usuario jjameson puede ejecutar comandos asociados con el archivo binario /usr/bin/yum y con los privilegios del usuario root.Además, no se requiere introducir contraseña para ejecutar los comandos.
Ahora ejecutaremos los siguientes comandos con el fin de ejecutar un plugin personalizado con /usr/bin/yum, que me ejecutara una Shell con los privilegios del usuario root.
De esta manera realizamos una escalada de privilegios vertical y llegamos a ser el usuario root.
Ahora observaremos las dos banderas contenidas en los archivos user.txt y root.txt. Para localizar los archivos utilizaremos el comando find, y buscaremos desde el directorio /, archivos con sus nombres.
