Uploader – The Hackers Labs [Write Up]

Esta es mi primera máquina en la plataforma de hacking ético llamada The Hackers Labs.

La máquina se llama Uploader y tiene una dificultad de Principiante y se encuentra dentro de la categoría de Hacking Web.

Resumen de conceptos trabajados:

Escaneo de Puertos Enumeración de Servicios File Upload Vulnerability Remote Code Execution (RCE) Fallo de Sanitización Information Disclosure Crackeo de hashes PrivEsc por Binary Abuse

Si es tu primera máquina de The Hackers Labs y no sabes cómo empezar a comprometer la máquina víctima, 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…

Vemos que la IP «is up» está activa y su ttl es de 64, es decir, SO Linux.

Fase de Enumeración / Escaneo de Puertos

Comenzamos el análisis con la fase de enumeración y escaneo de puertos mediante el comando:

sudo nmap -p- --open -sSCV --min-rate 5000 -vvv -n -Pn 192.168.1.210 -oN escaneo

El escaneo de puertos, servicios y versiones nos dice que de los 65.535 puertos TCP que hay en total, solo responde como «open» o abierto, uno, que es el puerto 80 web y que corre bajo servidor Apache versión 2.4.58 y que soporta en la cabecera de respuesta http la opción POST de envío o subida de datos (muy en línea con el nombre de la máquina UPLOADER XD).

Por asegurarnos, vamos a hacer un escaneo de los puertos abiertos por UDP, aunque teniendo en cuenta que se trata de una máquina Linux en principio lo descartaría…

Para ello aplicamos el comando:

sudo nmap -sU --top-ports 200 --min-rate=5000 -PN 192.168.1.210

pero nos muestra que están cerrados, por lo que continuamos con TCP.

A continuación, buscamos exploits públicos sobre la versión del servidor Apache 2.4.58 pero no parece que haya ninguno, ni que a priori la intrusión venga por aquí…

Por lo que el siguiente paso que haría sería acceder a la IP a través del navegador o haciendo un curl en consola para ver qué información devuelve y revisar el código fuente en búsqueda de versiones del CMS u otra información relevante que nos sirva para hacer esa subida de ficheros maliciosa y comprometer la máquina.

Vamos a probar a hacer un escaneo con nmap para, mediante una serie de scripts, detectar qué vulnerabilidades más conocidas bajo el comando “vuln” encuentra para esa IP. Se aplicaría sobre el puerto abierto encontrado de la IP victima (irá cambiando en el writeup por ser dinámica y resolverlo en varios días, pero el rango está dentro de 192.168.1.XXX).

Interesante que no encuentra a priori una vulnerabilidad concreta, pero sí detecta un directorio /uploads que le resulta «potencialmente interesante».

Subida insegura de archivos

Por lo que vamos a ir a la IP en el navegador, y vemos una aplicación web que efectivamente nos permite subir ficheros.

Vamos a hacer un análisis algo más profundo para detectar (si es que existen) directorios, subdominios o ficheros ocultos….ya de primeras, y como nos anticipaba el reconocimiento vuln de nmap, existe un directorio /uploads y fichero «upload.php» pero queremos ver si hay algo más de información.

Si usamos gobuster para ello, vemos que sólo nos encuentra el directorio que ya sabíamos /uploads/, y el fichero index.html que resuelve con el contenido de la misma IP.

Si vamos al código fuente, a priori no nos dicen que haya alguna excepción en cuanto al formato de los ficheros a subir.

Por lo que vamos a continuar probando la aplicación para subirle un fichero y ver qué respuesta nos da…

Al subirle un fichero nos devuelve esta respuesta, y si nos vamos al directorio /uploads/ vemos nuestro fichero subido.

Remote Code Execution (RCE) mediante ejecución directa del archivo PHP

Sabiendo que nuestros archivos subidos se almacenan en /uploads, vamos a crear una reverse shell en php que nos permita conectarnos con la máquina víctima.

Para ello podemos ir a la página de pentestmonkey (php-reverse-shell) y descargarnos el archivo comprimido en nuestra kali y modificarlo.

NOTA: recuerda que te lo bajas en formato tar.gz , por lo que usando este comando puedes descomprimirlo:

tar -xvf php-reverse-shell.tar.gz

Y ahora modificamos el archivo php con la IP nuestra atacante (eso lo podemos saber usando el comando «ifconfig») y un puerto aleatorio para escuchar con netcat (yo usé el 4444).

una vez tienes este php malicioso configurado con tu IP atacante y el puerto, lo que hacemos primero es ponernos en escucha por el puerto 4444 con netcat, y después, nos vamos a la web, subimos nuestro fichero php malicioso (reverse shell), lo buscamos en /uploads y lo ejecutamos … en el momento se nos abrirá la shell en netcat, confirmando la RCE.

Ahora tenemos conexión con la máquina víctima como usuario www-data

Si ahora navegamos hasta el directorio /uploads veremos nuestro fichero subido

Fallo de Sanitización

Incluso si retrocedemos un directorio a /html , podremos ver el contenido del archivo «uploads.php» (que vimos haciendo fuzzing) y nos encontramos con que:

ERRORES DE SANITIZACIÓN DE LA APLICACIÓN

1. No usan htmlspecialchars() ni similar. Si alguno de esos mensajes incluye datos derivados del nombre del archivo o de otra entrada de usuario, podríamos inyectar HTML/JS y tener un XSS reflejado. No es lo que hemos usado para la reverse shell, pero es otra debilidad del código.
2. Sin restricción de tipo de archivo (ni siquiera en cliente). No hay atributo accept=».jpg,.png,…» Eso solo es seguridad de “chichinabo”, pero ya indica que el programador no se ha preocupado ni del front. Nombre del campo genérico name=»archivo» se envía tal cual a $_FILES[‘archivo’] en el backend. Si en el servidor no hay control de extensión/MIME, cualquier cosa vale: .php, .phtml, .phar, etc.
3. El “ID” que muestra está relacionado con el directorio o ruta donde se guarda el archivo que subimos. Si el backend usa ese mismo valor para crear carpetas o rutas (por ejemplo /uploads/ebcdb3b4/), y predecimos o enumeramos esos IDs, acabamos sabiendo dónde está el .php malicioso y llamarlo por URL.

Si ejecutamos este comando, podemos ver que hay dos usuarios, el root y el operatorx:

Information Disclosure

Accediendo a la home, vemos al usuario operatorx y un fichero txt Redme que dice:

Sabiendo que buscamos un zip «oculto» lo que podemos hacer es usar el comando find para poder acceder a él…

find / -type f -name "*.zip" 2>/dev/null

Detectado el .zip lo que hacemos ahora es descargárnoslo a nuestra máquina atacante para ver qué contiene, para ello lo que hacemos es levantarnos un servidor en python que mediante el comando wget nos permita obtenerlo.

Nos movemos a la carpeta /srv/secret en la máquina víctima que es donde está el fichero .zip , y levantamos el servidor:

ahora desde nuestra máquina atacante, hacemos la petición por wget, y conseguimos descargarnos el .zip

Crackeo de hashes

Vemos que al intentar unzipear el fichero, nos aparece un mensaje de skipping que nos dice que los ficheros internos están protegidos con contraseña y que además usa un formato PKZip no estándar (v5.1) que unzip de Linux no puede manejar sin una herramienta adicional.

Como es un ZIP protegido, lo que tenemos que hacer es convertir el ZIP a un formato crackeable por JohnTheRipper por ejemplo y lo alojamos en credenciales.txt

zip2john File.zip > credenciales.txt

Y sobre ese hash que obtenemos lo crackeamos usando John con su wordlists rockyou y tenemos la contraseña:

ahora volvemos a descomprimir el File.zip usando «7z x File.zip» y ya obtenemos la password del usuario operatorx: d0970714757783e6cf17b26fb8e2298f

Con esta contraseña, probamos a hacer un pivoting de usuario de w-data a operatorx:

Pero después de probar varias veces, me dice que hay un fallo en la autenticación. Después de darle vueltas y preguntar a ChatGPT, resulta que esa contraseña está hasheada en MD5, por lo que tenemos que crackearla.

Para ello, me copio esa contraseña en un txt y la crackeo usando Hashcat:

echo d0970714757783e6cf17b26fb8e2298f > hash.txt

hashcat -m 0 -a 0 hash.txt /usr/share/wordlists/rockyou.txt

Y tenemos la contraseña: 112233

Con el comando «su operatorx» e introduciéndole la contraseña anterior, ya estamos dentro. Ahora si nos movemos a la carpeta /home y luego al usuario /operatorx , vemos la user flag.

PrivEsc por Binary Abuse / GTFOBins

Ahora tocaría la escalada de privilegios a root.

Para ello lo primero que hacemos es comprobar los permisos de sudo que tiene el usuario mediante el comando «sudo -l»:

Vemos que puede ejecutar el binario tar sin usar contraseña.

En este punto podemos ir a GTFObins para buscar el binario «tar» y ver cómo acceder a root mediante el comando siguiente:

sudo tar -cf /dev/null /dev/null --checkpoint=1 --checkpoint-action=exec=/bin/sh

Y efectivamente si lo ejecutamos como usuario operatorx, ya somos root y podemos ver la flag:

RESUMEN DE LA MÁQUINA UPLOADER DE THE HACKERS LABS

Esta máquina tenía únicamente un servicio web activo. Al entrar, vimos que la web permitía subir archivos sin ningún tipo de control. Eso significa que, en vez de subir una imagen o un PDF, podíamos subir un archivo PHP con código malicioso, capaz de darnos acceso a la máquina. Creamos una reverse shell (una forma de conectar desde la víctima a nuestro equipo) y, al ejecutarla desde el directorio /uploads, conseguimos entrar en el sistema como el usuario más básico: www-data. Una vez dentro, empezamos a investigar el sistema y encontramos una pista en la carpeta de un usuario llamado operatorx: decía que había guardado un archivo ZIP “muy importante” en un lugar secreto. Buscando por todo el sistema, lo encontramos en /srv/secret. Ese ZIP estaba protegido con contraseña, así que lo descargamos, lo convertimos a un formato crackeable y obtuvimos la contraseña del ZIP. Dentro estaba el hash (una contraseña en forma encriptada) de operatorx. Como ese hash también estaba protegido, lo desciframos con una herramienta de fuerza bruta (hashcat), lo que nos dio la contraseña real del usuario. Con ella ya pudimos acceder como operatorx. Por último, comprobamos qué permisos especiales tenía ese usuario y vimos que podía ejecutar el comando tar como administrador sin contraseña. Ese comando tiene una forma documentada de convertirse en root (recogida en la web GTFObins). La ejecutamos… ¡y nos convertimos en root! Con ello pudimos acceder a la flag final y completar la máquina.

EXTRA – ESCALADA A ROOT MODIFICANDO PASSWD

Como el usuario operatorx puede ejeuctar el binario tar como usuario root, lo que podemos hacer es lo siguiente:

• Copiamos el passwd actual de la máquina a nuestra carpeta con

cp /etc/passwd .

• Editamos el fichero con nano

nano passwd

• Cambiamos esta línea por la siguiente

root:x:0:0:root:/root:/bin/bash

root::0:0:root:/root:/bin/bash

• Guardamos el archivo y lo comprimimos en un tar

tar -cvf passwd.tar passwd

• y sobrescribimos el passwd del sistema usando tar con sudo

sudo /usr/bin/tar -xvf passwd.tar -C /etc

En este punto ya podemos ejecutar «su root» y acceder como root sin contraseña (porque se la hemos quitado con la x ).

Por qué funciona:

• tar ejecutado como sudo puede leer y escribir cualquier archivo del sistema.
• /etc/passwd se puede sobrescribir aunque seas usuario normal.
• Si root no tiene contraseña → puedes hacer su root sin pedirte nada.