Wall - HackTheBox

En este post se explicarán los pasos que se han seguido para conseguir vulnerar la seguridad de la máquina Wall en Hack The Box, tal y como se refleja, es un sistema Linux con un nivel de dificultad medio (4.6)

Ilustración 1: Wall.

Se dio comienzo a la fase de enumeración con NMAP:

Ilustración 2: Usando NMAP para descubrir que puertos y servicios tiene habilitado la máquina Wall.

Ilustración 3: Resultados de NMAP.

Los resultados obtenidos muestran que solo está abierto el puerto 22 con el servicio SSH y el puerto 80 con el servicio apache, quizás alojando una web.

Ilustración 4: Servicio Apache en la máquina Wall.

Se necesitaban vectores de ataque para conseguir vulnerar la seguridad de la máquina Wall, así que se optó por hacer uso de herramientas como DIRB y Nikto para encontrar rutas desconocidas o vulnerabilidades aparentes:

• DIRB:

Ilustración 5: Resultados de DIRB.

• Nikto:

Ilustración 6: Resultados de Nikto.

Los resultados aportados por ambos aplicativos no fueron muy esclarecedores, lo más interesante fue el directorio http://10.10.10.157/monitoring, que mostraba un panel de inicio de sesión:

Ilustración 7: Directorio http://10.10.10.157/monitoring.

Para indagar un poco más se decidió buscar ficheros con extensión PHP en la URL, para ello se hizo uso de Wfuzz:

Ilustración 8: Wfuzz buscando ficheros con extensión PHP en http://10.10.10.157/.

Ilustración 9: Wfuzz buscando ficheros con extensión PHP en http://10.10.10.157/monitoring/.

Se encontraron los siguientes ficheros PHP en la ruta http://10.10.10.157/:

Ilustración 10: http://10.10.10.157/aa.php.

Ilustración 11: http://10.10.10.157/panel.php.

Aún seguía sin existir un claro vector de ataque, así que se decidió aumentar la intensidad de la búsqueda haciendo uso de un diccionario más grande (https://github.com/danielmiessler/SecLists/) en la herramienta DIRB:

Ilustración 12: Ejecución de DIRB con un diccionario proveniente del repositorio de SecLists en Github.

De esta forma tampoco se encontraba nada, por tanto, se acudió al foro de Hack The Box, donde se hablaba de que uno de los CVE que había que usarse era propio del creador de la máquina, por lo que si se buscaba en su repositorio de Github quizás se podría encontrar algo más:

Ilustración 13: CVE-2019-13024 de la herramienta Centreon.

Todo apuntaba a que debía estar instalada la aplicación Centreon en la máquina Wall. Y así se refutaba accediendo a http://10.10.10.157/centreon/:

Ilustración 14: http://10.10.10.157/centreon/.

No conocía la aplicación hasta el momento, la curiosidad reside en que una vez descubierta, investigué en todos los diccionarios del repositorio SecLists de Github para comprobar en cuales aparecía, así como también en el directorio /usr/share/wordlists/ de Kali Linux:

Ilustración 15: Búsqueda de coincidencias en el directorio /usr/share/wordlists/.

Ilustración 16: Diccionarios de SecLists que contienen la coincidencia.

Ilustración 17: Coincidencias encontradas en SecLists.

No se encontró ninguna coincidencia en el directorio /usr/share/wordlists de Kali y solo en algunos diccionarios (muy atípicos) del repositorio SecLists de Github. Lo que creo que sin la pista del foro de Hack The Box, hubiese sido muy difícil encontrarlo.

El exploit de la aplicación Centron, que daría el primer acceso a la máquina víctima, necesitaba de unas credenciales para poder ejecutarse. Así que, el siguiente paso fue usar de nuevo la herramienta DIRB, para encontrar posibles rutas dentro de Centreon que desvelaran una mala configuración o ficheros de Backups:

Ilustración 18: DIRB en http://10.10.10.157/centreon/.

No se encontró ningún fichero o directorio que aportara un usuario y contraseña, pero si estaba permitido realizar peticiones a la API y poder autentificarse haciendo uso de esta.

Ilustración 19: Intento de autentificación haciendo uso de la API de Centreon.

Dado que el usuario por defecto en Centreon es "admin", se decidió realizar un ataque de diccionario a la contraseña, haciendo uso de Hydra y de la API de Centreon:

Ilustración 20: Ataque de diccionario a la contraseña haciendo uso de Hydra.

Ilustración 21: Credenciales obtenidas.

Se obtuvo que el usuario y la contraseña eran "admin" y "password1" respectivamente. También se podía haber realizado este ataque al panel de inicio de sesión que se encontraba en http://10.10.10.157/Centreon/index.php, solo que había que percatarse de que existe un token CSRF (https://stackoverflow.com/questions/5207160/what-is-a-csrf-token-what-is-its-importance-and-how-does-it-work) que se genera en cada petición:

Ilustración 22: Inspeccionado el código y observando cómo se genera el token.

Ilustración 23: Analizando una petición POST de la aplicación y observando que se envía un token.

Para que el ataque al panel de inicio de sesión fuese exitoso se debe realizar cada petición con un token diferente, generado por la aplicación. Se puede hacer un script manualmente o usar esta herramienta (https://github.com/J3wker/anti-CSRF_Token-Bruteforce):

Ilustración 24: Usando https://github.com/J3wker/anti-CSRF_Token-Bruteforce.

Se obtuvo la misma combinación de usuario y contraseña. Accediendo a la herramienta se veía de la siguiente forma:

Ilustración 25: Panel principal de Centreon.

Analizando el exploit (https://github.com/mhaskar/CVE-2019-13024) se observa que en http://10.10.10.157/centreon/main.get.php?p=60901 es donde se inyecta el payload, si se navega hasta dicha pagina se puede observar que es el panel de configuración de lo que se denominan "pollers":

Ilustración 26: Panel de Pollers.

Ilustración 27: Configuración del poller Centreon.

En la configuración de los pollers se puede observar los caracteres no permitidos y no se tiene posibilidad de modificarlos.

En el exploit se debía modificar el payload, para comprobar su funcionamiento se inyectó el comando "ping 10.10.15.216" y si con tcpdump la máquina atacante capturaba el paquete ICMP, se podría determinar el correcto funcionamiento del exploit e inyectar una reverse shell. También se añadió un "print" en las peticiones para visualizarlo con mayor detalle.

Ilustración 28: Modificando el payload.

Ilustración 29: tcpdump a la espera de la recepción de paquetes ICMP.

Se realizaron varios intentos y modificaciones, pero ninguno resultó exitoso:

Ilustración 30: Fallo en la ejecución del exploit.

Mis write-ups siempre intentan mostrar todos los conocimientos que he adquirido durante el proceso, de forma didáctica, así como todos los pasos que he realizado, pero en este caso se esperará al vídeo de IppSec (https://www.youtube.com/channel/UCa6eh7gCkpPo5XXUDfygQQA) o se consultarán otros write-ups (https://github.com/Hackplayers/hackthebox-writeups/tree/master/machines/Wall).

Pero existía una forma más sencilla de comprometer el sistema, en la barra de navegación se podía acceder a una sección que permitía la ejecución de comandos:

Ilustración 31: Sección de ejecución de comandos en Centreon.

Por tanto, con la ayuda de GTFOBinds (https://gtfobins.github.io/) se consiguió abrir una reverse shell:

Ilustración 32: Reverse shell haciendo uso de socat.

Ilustración 33: Ejecución del comando socat.

Ilustración 34: Reverse shell establecida.

Para realizar la escalada de privilegios primero se ejecutó un script de enumeración en el sistema y así comprobar las diferentes posibilidades que pueden existir:

Ilustración 35: Ejecución de LinuxEnumeration.sh

Ilustración 36: Los diferentes servicios con conexiones abiertas.

Ilustración 37: La base de datos mysql tiene contraseña por defecto.

Ilustración 38: El hash de una contraseña.

Ilustración 39: Ficheros con SUID.

El vector de ataque más claro es /bin/screen-4.5.0, porque existe un exploit (https://www.exploit-db.com/exploits/41154) que permitiría ser root del sistema. Es muy simple, solo hay que ejecutar los comandos que se indican:

Ilustración 40: Creación del fichero libhax.c.

Ilustración 41: Creación del fichero rootshell.c.

Ilustración 42: Descarga del fichero rootshell.c.

Ilustración 43: Descarga del fichero libhax.c.

Ilustración 44: Compilación de los ficheros haciendo uso de gcc.

Ilustración 45: Ejecución de rootshell tal y como se indica en el exploit.

Cuando se ejecuta se obtiene acceso al sistema como usuario administrador y por tanto a las flags user.txt y root.txt.

Como conclusión se podría decir que ha sido una máquina en la que la enumeración tiene mucha importancia, pero a la vez un poco tediosa, puesto que en sí dependía mucho del diccionario que se use, la modificación del primer exploit sin duda es la parte más dura y la escalada de privilegios era muy rutinaria.