Torrijas – The Hackers Labs [Write Up]

Seguimos con otra máquina de nivel Principiante adaptada para nivel de «eJPT» de la plataforma de TheHackersLabs. La máquina se llama «Torrijas» .

Conceptos trabajados:

Enumeración de puertos y servicios Descubrimiento de usuarios Vulnerabilidad LFI Exposición de credenciales Reutilización de contraseñas Almacenamiento inseguro en base de datos Mala configuración de privilegios SUDO

Resumen: En la resolución de la máquina Torrijas, comenzamos con una fase de enumeración que nos lleva a identificar un WordPress vulnerable a Local File Inclusion (LFI), lo que nos permitió acceder al archivo wp-config.php y obtener credenciales de base de datos. Aprovechando la reutilización de contraseñas, conseguimos acceso tanto a MySQL como al sistema mediante SSH, desde donde continuamos la enumeración y descubrimos nuevas credenciales en texto plano que nos permitieron pivotar de usuario. Finalmente, al revisar los privilegios, identificamos que podíamos ejecutar binarios como root sin contraseña, lo que aprovechamos para obtener una shell con privilegios elevados y ser root.

Si es tu primera máquina de The Hackers Labs y no sabes cómo empezar a comprometer la máquina, te recomiendo que visites este post donde te cuento paso a paso cómo hacerlo.

Básicamente lo que tienes que hacer es descargarte el laboratorio/máquina de la plataforma, importarla desde tu Virtual Box o VMWare, iniciarla y ya desde tu máquina Kali atacante buscar por la red interna la IP con el comando arp-scan…

Identificamos la IP de la máquina víctima porque la MAC comienza con un 08:00 que marca a las máquinas virtuales.

Por otro lado decir que, en el comando de arp-scan utilizamos eth0 porque es nuestro adaptador de red que conecta con la máquina víctima. Eso lo podemos ver haciendo un ifconfig, donde vemos la interfaz de red asociada a la IP de nuestra máquina atacante:

Ahora usamos los comandos ping y nmap para ver si la máquina víctima está activa e incluso anticipar su SO…

ENUMERACIÓN DE PUERTOS Y SERVICIOS

Comenzamos con la fase de reconocimiento y escaneo de puertos y servicios que corren para esa IP víctima.

En estos laboratorios, se suele empezar por un escaneo de puertos por TCP ya que la mayoría de servicios útiles en máquinas de laboratorio (HTTP, SSH, SMB, MySQL, etc.) usan TCP. Si no encontráramos nada por este protocolo, trataríamos de hacer un escaneo con nmap por UDP.

Por tanto, en nuestro caso y para empezar, aplicaremos el siguiente comando nmap por TCP (si quieres conocer el significado de cada comando, te dejo este post donde lo explico):

nmap -p- --open -sS --min-rate 5000 -vvv -n -Pn 192.168.1.239 -oN Escaneo_TCP

El escaneo, además de los típicos puertos abiertos en este tipo de laboratiros como son el 22 ssh de acceso a usuarios autenticados, y el puerto 80 http donde corre un servidor web, vemos que corre está abierto el puerto 3306 mysql.

Conocidos estos puertos abiertos de la máquina víctima, lo que hacemos a continuación es enumerar, mediante un script básico de nmap, cuáles son los servicios y versiones que corren para esos puertos.

Al analizar por las versiones y servicios de esos puertos abiertos, no detecto a priori ninguna vulnerabilidad pública expuesto o CVE, etc, por lo que sabiendo que el puerto web está abierto, me pongo a realizar la investigación activa del activo web.

Accedo a la IP desde el navegador y me encuentro con una página web cuyo contenido y temática no tiene nada que ver con el nombre del laboratorio. Una cosa que me fijé es que el title dice «torrija.thl», por lo que decido modificar el etc/hosts asociando la IP de la máquina con ese dominio por si se estuviera aplicando virtual hosting….

Sin embargo al probarlo, el contenido que devuelve es el mismo…

Analizo las tecnologías que carga la página para ver si me detecta la versión del CMS, tipo de lenguaje de programación que se ejecuta en el backend o algún otro tipo de aplicación que cargue el servidor y pueda explotarla. Pero ni usando whatweb ni con Wappalizer detecto nada relevante.

Paso ahora a investigar el código fuente en busca de posibles comentarios o pistas a través de enlaces internos/externos que me puedan dar directorios ocultos (antes de aplicar fuzzing web).

Y veo que las imágenes que se cargan en la web caen bajo el directorio /images/, de hecho, si lo ejecuto en el navegador, me devuelve el listado de imágenes cargadas en el servidor.

Esto ya es una pista de que el servidor tiene habilitado el Directory Listing de Apache. Esto ocurre porque en Apache está habilitada la opción: «Options Indexes».

El que podamos encontrar esta información expuesta desde el navegador ya supone una brecha de «information discloser» permitiendo conocer la versión de Apache/2.4.62 (Debian), la estructura de directorios del servidor, identificar archivos interesantes, descubrir nombres de rutas ocultas o incluso encontrar backups, scripts o archivos de configuración, etc.

Sabiendo esto, paso a realizar fuzzing web con gobuster para detectar archivos y directorios ocultos:

gobuster dir -u http://192.168.1.239/ -w /usr/share/seclists/Discovery/Web-Content/common.txt -x php,html,txt,bak,old,zip,tar.gz,.json,.config 

El ataque nos devuelve los siguientes directorios entre los que destaca /wordpress (que ya me hace intuir que el CMS detrás de la aplicación es este y que luego tendremos que ver su versión y potenciales vulnerabilidades o formas de explotación como el reconocimiento con «wpscan») ….

Si accedemos a esa ruta, vemos que se despliega un sitio llamado «Torrijas del primo» de WordPress en su versión 6.7.2 .

DESCUBRIMIENTO DE USUARIOS

Sabiendo que se trata de un WordPress, lo que se me ocurre es analizar con la herramienta WPScan ese directorio donde se aloja para ver usuarios, plugins y sus versiones, y tema:

wpscan --url http://torrija.thl/wordpress/ --enumerate u,vp,t

De todo el escaneo, me identifica el usuario «administrator», que validamos que efectivamente existe accediendo al panel de login http://torrija.thl/wordpress/wp-admin/users.php (que identificamos haciendo fuzzing web antes) y colocando ese usuario con una contraseña inventada:

Conocemos la url contra la que WordPress hace la comprobación de credenciales, por lo que si además conocemos el usuario, lo que hago a continuación es aplicar fuerza bruta con Hydra.

Pero antes que tengo saber cuál es la ruta del envío del login en ese panel. Para ello uso Burpsuite y capturo la petición por POST con todos los valores necesarios:

• log=administrator
• pwd=admin
• wp-submit=Acceder
• redirect_to=http://192.168.1.239/wordpress/wp-admin/users.php
• testcookie=1

Por lo que el comando exacto a ejecutar con Hydra seria:

hydra -l administrator -P /usr/share/wordlists/rockyou.txt 192.168.1.239 http-post-form "/wordpress/wp-login.php:log=^USER^&pwd=^PASS^&wp-submit=Acceder&testcookie=1:la contraseña que has introducido para el nombre de usuario administrator no es correcta" -I 

Al final del comando de testcookie hay que introducir el mensaje de error que aparece, que en nuestra captura anterior es «la contraseña que has introducido para el nombre de usuario administrator no es correcta», ahora el ataque con hydra nos devuelve esto:

Pese a que este ataque con Hydra nos saca como que sí se han encontrado contraseñas, en realidad son falsos positivos ya que WordPress siempre devuelve un estado 200. De hecho si probamos cada contraseña, el panel de login no nos permite entrar.

En este punto decido volver a analizar con wpscan la existencia de plugins que puedan ser vulnerables, ya que sabiendo que se trata de un WordPress, estos suelen ser vector de ataque. Este es el comando para un escaneo específico para plugins, agresivo.

wpscan --url http://192.168.1.239/wordpress/ --enumerate ap --plugins-detection aggressive --no-banner

De ambos plugins, me llama la atención el «web-directory-free» ya que está desactualizado, tiene directory listing y es un plugin menos habitual que «akismet» (muy usando antispam para filtrar comentarios y envíos de formularios no deseados).

Si accedemos directamente a la url del plugin desde el navegador, podemos ver que efectivamente tiene directory listing y podemos ver los recursos listados en esa ruta:

De primeras vemos que hay un archivo readme.txt, por lo que voy a abrirlo ya que suele contener información relevante acerca del plugin como la versión, características, etc.

Efectivamente se referencia a la versión del plugin, por lo que podemos ver si públicamente hay reportado algún exploit o vulnerabilidad asociada:

VULNERABILIDAD LFI

Haciendo la búsqueda en Google, nos aparece como primer resultado esta web donde parece mencionar Local File Inclusion para cualquier versión inferior a la 1.7.2 del plugin.

Si accedemos a la página, nos reporta que efectivamente esa versión es vulnerable a Local File Inclusion y se asocia a la CVE-2024-3673 .

Vemos que ese CVE en su página referencia a la web de WPScan, y en ella nos dice cómo explotarlo mediante una POC.

Vamos por tanto a probar ese endpoint vulnerable al que referencia en admin-ajax.php pero ajustando algunos valores para una mejor extracción y lectura del contenido:

curl -s -X POST "http://192.168.1.239/wordpress/wp-admin/admin-ajax.php" \
-d "action=w2dc_controller_request&template=../../../../../../etc/passwd" \
| sed 's/\\n/\n/g' | sed 's/\\"/"/g'

Y efectivamente nos confirma que es vulnerable a LFI y nos reporta los usuarios validos con shell: donde los más «raros» o menos comunes son «primo» y «premo».

Ahora con estos usuarios, probamos con hydra a hacer fuerza bruta sobre el puerto 22 de la máquina para ver si alguno tiene credenciales de acceso.

Por hacerlo más rápido, voy probando por separado con cada uno, y sólo es con el usuario «premo» con el que me encuentra la contraseña.

Encontrada la password, me dirijo a acceder a p22 y encontramos la primera flag.

El siguiente paso es escalar privilegios a root, por lo que comenzamos a investigar a qué grupo pertenecemos, qué privilegios tengo como usuario, qué usuarios hay en el sistema, etc.

El usuario «premo» no pertenece a ninguno grupo importante como sudo, adm, etc.

Confirmamos los 3 usuarios detectados anteriormente.

Y confirmamos también que este usuario no puede ejecutar el comando sudo…

en este punto tenemos que investigar y buscar por ficheros que están oculto en el sistema, como por ejemplo los que detecté al inicio con un escaneo con gobuster hacia ficheros de configuración(ej. wp-config). Para ello usaremos el comando:

find / -name wp-config.php 2>/dev/null

EXPOSICIÓN DE CREDENCIALES

Nos lo encuentra, y al abrirlo/explorarlo vemos que se muestran credenciales para la DB:

Con estas dos credenciales y sabiendo que dentro existe una DB llamada wordpress, lo que haremos como usuario premo es acceder por mysql:

Ok, ya estamos dentro, por lo que iremos analizando las bases de datos existentes (aunque sabemos que la nuestra es wordpress), buscaremos las tablas y después buscaremos por los usuarios y contraseñas, de esta forma:

La contraseña como vemos está haseada

REUTILIZACIÓN DE CONTRASEÑAS

Sabiendo que esa contraseña de «administrator» está hasheada, vamos a probar si accedemos de nuevo por mysql reutilizando la misma contraseña anterior pero para root en la base de datos…muchas veces ocurre que en este tipo de laboratorios se reutilizan contraseñas…

Y efectivamente estamos dentro y podemos ver las distintas bases de datos:

ALMACENAMIENTO INSEGURO EN BBDD

Aquí vemos la de «Torrijas» que no vimos con admin, por lo que seguimos investigando y llegamos a ver la contraseña de «primo»:»queazeshurmano».

Ahora como el usuario «premo» pivotamos al usuario «primo» con – su primo – y estamos dentro:

MALA CONFIGURACIÓN DE PRIVILEGIOS SUDO

No veo de primeras la flag de root pero si aplicamos un «sudo -l» vemos los privilegios asignamos a binarios:

Y aquí nos dice que podemos ejecutar el binario bpftrace como root SIN contraseña.

Por lo que vamos a la página web de GTFObins y vemos de qué forma podemos ejecutar como sudo ese binario para escalar privilegios a root: https://gtfobins.linuxsec.org/#bpftrace

Ejecutamos ese comando y ya somos root. Ya solo tenemos que desplazarnos a la carpeta de root «cd root» y con «ls -la» vemos la root flag 😉

RESUMEN DE LA MÁQUINA TORRIJAS

Comenzamos con una fase de enumeración donde se identifican los servicios expuestos, destacando un servidor web con WordPress. A través del análisis de una funcionalidad vulnerable, descubrimos la vulnerabilidad de tipo Local File Inclusion (LFI) que permite acceder a archivos sensibles del sistema, entre ellos el wp-config.php, donde obtener credenciales de base de datos críticas. Con estas credenciales, logramos acceso tanto a la base de datos MySQL como posteriormente al sistema mediante reutilización de contraseñas, accediendo como el usuario premo. Durante la enumeración interna, identificamos otros usuarios del sistema y, tras explorar las bases de datos, descubrimos nuevas credenciales en texto plano que nos permiten pivotar al usuario primo, avanzando así en el control del sistema. Finalmente, al revisar los privilegios del usuario primo, detectamos que se puede ejecutar el binario bpftrace como root sin contraseña. Aprovechando esta mala configuración y apoyándonos en técnicas documentadas, ejecutamos una shell con privilegios elevados, obteniendo acceso completo como root y comprometiendo totalmente la máquina.