Boardlight
Platform
HackTheBox
O.S
Linux
Level
Easy
Skills
Fuzzing Web
Web Application
PHP Basics
Fase 1: Reconocimiento
Realizo un escaneo inicial de la máquina para identificar sus puertos abiertos y los servicios en ejecución. Para ello, utilizo Nmap con parámetros que optimizan el proceso, como el SYN Scan (-sS), el cual envía paquetes SYN sin completar la conexión TCP, permitiendo un análisis más sigiloso y rápido. Además, deshabilito la resolución DNS con el parámetro -n, lo que evita consultas innecesarias y acelera el escaneo.
sudo nmap -sS --min-rate 5000 -p- --open -n -Pn -v 10.10.10.8 -oN target
En el resultado descubrimos que solo tenemos abiertos los puerto TCP 80 y TCP 22.
Procedo a enviar una serie de scripts por defecto de nmap (Scripts NSE) contra cada uno de los puertos e intento detectar las versiones de los servicios que corren dentro de cada puerto.
Al observar y buscar un poco por internet, no encuentro ningún script confiable que funcione contra las versiones de OpenSSH y Apache mostradas por nuestro escaneo. Por lo que decido analizar un poco más desde mi terminal la web que sirve el Apache.
Utilizando la herramienta WhatWeb, podemos obtener información sobre los servicios que se ejecutan en la página, incluyendo sus versiones, el servidor que la respalda (en este caso, Ubuntu Linux), la dirección IP y un correo electrónico. Sin embargo, por el momento, no encuentro información particularmente relevante. Por ello, procederé a examinar la página desde una interfaz más amigable a través del navegador web.
Fase 2: Explotación
Tras acceder al sitio web y analizar su funcionamiento básico, exploré las distintas páginas disponibles y realicé una enumeración de archivos PHP potencialmente interesantes utilizando Gobuster. Sin embargo, después de este análisis, no encontré información de valor relevante.
Aún así había un pequeño detalle que me llamó bastante la atención...
En toda la página se nombraba un nombre de dominio, incluso si volvemos a revisar la información arrojada por WhatWeb, nos daremos cuenta de que el nombre del correo electrónico estaba asociado a este mismo dominio. Por lo tanto, decido asociar la dirección IP de la máquina a este nombre de dominio y realizar un fuzzing de posibles subdominios.
Fuzzing
Para esta técnica, decido usar una herramienta bastante completa llamada ffuf con los siguientes parámetros:
-H: Agrega una cabecera HTTP, en este caso la cabecera 'Host', la cual es útil en un entorno como el actual, donde sospechamos que se esté usando VirtualHosting para alojar otro dominio dentro de la misma IP.
-u: URL objetivo
-w: Aquí le indicamos la lista de palabras que se desea utilizar para realizar las pruebas de Fuzzing, en este caso, le indico un diccionario de Seclists el cual es bastante útil para encontrar subdominios web.
Al analizar las respuestas me doy cuenta de que lago no iba bien. Todas las opciones parecían salir como válidas a la hora de ser un posible subdominio, lo cual obviamente, era completamente falso.
Decidí realizar algunas pruebas para identificar el origen del error. Para ello, utilicé cURL para simular manualmente el envío de una petición a un subdominio inexistente, replicando el comportamiento de ffuf. Al hacerlo, noté que el servidor, por algún motivo, redirigía estas solicitudes al dominio principal, devolviendo un código de estado exitoso. Esto explicaba la confusión de ffuf al ejecutar el ataque, ya que interpretaba todas las respuestas como válidas.
Para evitar esto y realizar un fuzzing más preciso, utilizaré el parámetro -fs (filter size). Este parámetro permite filtrar respuestas según su tamaño, lo que nos ayuda a descartar aquellas que coincidan con los falsos positivos detectados anteriormente. En este caso, esos falsos positivos tienen el mismo tamaño que la respuesta del dominio principal, lo que indica que el servidor devuelve siempre el mismo contenido.
Al aplicar este filtro, podemos ignorar respuestas irrelevantes y enfocarnos únicamente en los resultados realmente útiles. 👀
Gracias a ello podemos ver una respuesta con un tamaño distinto y que seguramente nos devuelva una página diferente. Para comprobarlo, añadiremos el subdominio a nuestra configuración local de DNS, permitiendo que nuestro sistema lo interprete correctamente y podamos acceder a él.
Al acceder exitosamente al subdominio, lo primero que haría sería buscar en internet el nombre del servicio, sus credenciales por defecto y probarlas. Otra opción sería realizar rápidamente intentos con combinaciones comunes como “admin:admin” o “admin:password”, entre otras.
Por suerte, la combinación “admin:admin” funcionó. En caso de no haber sido así, se podrían haber explorado otras opciones, como realizar un ataque de fuerza bruta utilizando herramientas como Hydra u otras similares.
Una vez dentro como admin, busco la versión del servicio para ver si existe una vulnerabilidad asociada.
Al parecer, esta versión de Dolibarr no restringe adecuadamente la ejecución remota de comandos a través de PHP.
Después de una larga búsqueda, encontré una explicación de la vulnerabilidad: simplemente creamos un sitio dentro de Dolibarr y añadimos una página, luego editamos su código HTML, donde podemos inyectar código PHP malicioso para lograr la ejecución remota de comandos (RCE).
Procedemos a inyectar un código básico que nos permita obtener una reverse shell en nuestra máquina local.
Es importante tener en cuenta que la inyección solo funciona si las etiquetas PHP se escriben en mayúsculas (<?PHP ... ?>). Esto se debe a una deficiente sanitización del código dentro del editor HTML de Dolibarr.
Procedemos a visualizarla y al intentar cargar la página se ejecuta el código PHP y obtenemos acceso como el user www-data.
Dentro del fichero de configuración de conexión a la base de datos de Dolibarr, logro encontrar un usuario y una contraseña.
Pruebo a iniciar sesión con MySQL, pero ya os adelanto que no hay nada de interés.
Así que pruebo un inicio de sesión por SSH, pero tampoco funcionaba. Lo último que se me ha ocurrido es revisar el fichero de los usuarios del sistema y comprobar quienes tenian una bash asociada.
¡Bingo! Descubro que, aparte de root, solo hay un usuario con una bash asociada. Viendo esto, intento iniciar sesión reutilizando la contraseña de la base de datos...
¡Y funcionó!
¡Accedemos con éxito y conseguimos la flag del usuario!
Fase 3: Escalada de privilegios
Para esta escalada de privilegios he utilizado el script LinPEASS:
Lo he transferido a la máquina a explotar mediante un servidor HTTP montado rápidamente por PHP.
Tras su ejecución y un análisis detallado, descubro un archivo interesante con permisos SUID.
Ejecuto el binario enlightenment para ver qué versión se encuentra corriendo en el sistema.
Rápidamente voy a buscarla en Internet y encuentro que contiene una vulnerabilidad asociada relacionada con escalada de privilegios :)
Antes de buscar algún exploit público, entro a Metasploit a ver si hay suerte de encontrar algo relacionado.
Debido a que es un exploit de escalada de privilegios, va a requerir como parámetro una sesión anterior en la que se encuentre un acceso a la máquina víctima dentro de metasploit.
Para lograr esto, voy a usar el exploit multihandler para ponerme en escucha dentro de metasploit y así enviarme una reverse shell desde la sesión SSH que logramos abrir anteriormente.
Luego de tener lo necesario para utilizar el exploit de escalada de privilegios, ponemos la sesión actual en segundo plano (Ctrl +Z).
Como la shell que tenemos en la sesión parece ser incompatible con el exploit de enlightenment, decido convertirla en un Meterpreter para que metasploit no de problemas. Y ahora si, por último configuramos el exploit de enlightenment con la nueva sesión de Meterpreter.
Conversión de Shell a Meterpreter.
Configuración del exploit para escalar privilegios.
Vamos al directorio de root y podemos ver la flag.
Last updated