⭐ Oopsie – Hack The Box Write-up ⭐

Resumen

Oopsie es una máquina Linux de Hack The Box centrada principalmente en enumeración web, divulgación de información, Broken Access Control y escalada de privilegios.

Durante la enumeración inicial descubrimos un servidor web en el puerto 80. Aunque la página principal no mostraba directamente un panel de autenticación, utilizamos Burp Suite para inspeccionar y enumerar el sitio web.

La enumeración permitió descubrir el directorio /cdn-cgi/login, donde encontramos una página de login. Tras acceder como usuario
guest, analizamos las cookies utilizadas por la aplicación.

Mediante la modificación de los valores relacionados con el usuario y el nivel de acceso, descubrimos una vulnerabilidad de Broken Access Control que permitió acceder a
funcionalidades reservadas para el administrador.

A continuación, enumeramos identificadores de usuario hasta encontrar el Access ID del usuario administrador. Al modificar nuestra sesión para utilizar dicho
identificador, conseguimos acceder a la página de subida de archivos.

Subimos una reverse shell PHP al directorio /uploads y conseguimos obtener acceso inicial a la máquina como el usuario del servidor web.

Durante la enumeración del sistema encontramos un archivo que contenía credenciales del usuario robert. Utilizando estas credenciales conseguimos acceder mediante SSH.

Finalmente, enumeramos archivos pertenecientes al grupo bugtracker y encontramos el binario /usr/bin/bugtracker, configurado con el bit SUID.
El binario ejecutaba el programa cat de forma insegura, permitiendo abusar de PATH Hijacking para conseguir una shell con privilegios de root.

Conceptos Clave

• Web Enumeration
• Intercepting Proxy
• Burp Suite
• Directory Enumeration
• Cookies
• Broken Access Control
• IDOR / User ID Enumeration
• Privilege Manipulation
• File Upload
• PHP Reverse Shell
• Initial Foothold
• Credential Disclosure
• SSH
• SUID
• PATH Hijacking
• Privilege Escalation

Flujo del Ataque

1. Enumeración de puertos y servicios
2. Descubrimiento de HTTP en el puerto 80
3. Acceso a la aplicación web
4. Configuración de Burp Suite como proxy
5. Spidering y enumeración de la aplicación
6. Descubrimiento de /cdn-cgi/login
7. Acceso como usuario guest
8. Análisis de cookies y valores de sesión
9. Modificación del nivel de privilegios
10. Acceso a funcionalidades restringidas
11. Enumeración de identificadores de usuario
12. Descubrimiento del Access ID del administrador
13. Acceso a la página de subida de archivos
14. Subida de una reverse shell PHP
15. Localización del directorio /uploads
16. Ejecución de la reverse shell
17. Acceso inicial como usuario del servidor web
18. Enumeración del sistema
19. Descubrimiento de credenciales para el usuario robert
20. Acceso mediante SSH
21. Enumeración de archivos pertenecientes al grupo bugtracker
22. Descubrimiento del binario SUID /usr/bin/bugtracker
23. Análisis del funcionamiento del binario
24. Identificación de cat como ejecutable llamado de forma insegura
25. Explotación mediante PATH Hijacking
26. Obtención de una shell como root
27. Obtención de la flag final

Comprobación de Conectividad

Comenzamos comprobando que la máquina objetivo es accesible:

ping 10.129.x.x

Enumeración

Escaneo de Puertos

Utilizamos Nmap para identificar los puertos abiertos, los servicios disponibles y sus versiones:

nmap -sCV -q 10.129.x.x

El escaneo mostró dos servicios principales:

El puerto 80 indica que la máquina está ejecutando un servidor web HTTP, por lo que continuamos la enumeración utilizando el navegador.

Enumeración Web

Accedemos a la aplicación utilizando la dirección IP de la máquina:

http://10.129.x.x

La página principal mostraba información sobre los servicios de la empresa, incluyendo un mensaje
indicando que era necesario iniciar sesión para acceder a determinadas funcionalidades.

Sin embargo, no encontramos inicialmente un panel de login navegando manualmente por la página.

La pista de la máquina en HTB nos indica que debemos realizar Spidering utilizando Burp Suite.

Interceptación de Tráfico con Burp Suite

Burp Suite funciona como un proxy de interceptación entre nuestro navegador y
el servidor web.

La comunicación puede representarse de la siguiente forma:

Firefox
   │
   │ HTTP Request
   ▼
Burp Suite
   │
   │ Inspected / Modified Request
   ▼
Web Server

Configuramos Firefox para utilizar el proxy local de Burp:

Manual Proxy

HTTP Proxy: 127.0.0.1
Port: 8080

A continuación navegamos por la aplicación mientras Burp registra las peticiones realizadas.

Esto nos permite descubrir rutas y recursos que no son visibles directamente desde la página
principal.

Descubrimiento de la Página de Login

Mediante la enumeración del sitio descubrimos el directorio:

/cdn-cgi/login

Al acceder a:

http://10.129.x.x/cdn-cgi/login

obtenemos la página de autenticación.

Esta es la respuesta a la pregunta:

What is the path to the directory on the webserver that returns a login page?

Respuesta:

/cdn-cgi/login

Acceso como Guest

Tras intentar acceder usando credenciales tipo admin/admin, decido acceder a la aplicación como usuario guest, pero vemos que para la página Uploads necesitaré escalar privilegios como admin.

Mientras navego con burp, comienzo a analizar las peticiones y las cookies utilizadas por la aplicación.

Las cookies almacenan información relacionada con nuestra sesión y, en este caso, también incluyen valores relacionados con nuestro nivel de acceso y nuestro identificador de usuario.

Este tipo de implementación puede resultar peligrosa si el servidor confía directamente en los valores enviados por el cliente.

Broken Access Control

Mediante las dev tools de Mozilla (F12) vemos las cookies y descubrimos que determinados valores podían ser modificados desde el navegador.

La pregunta de Hack The Box era:

What can be modified in Firefox to get access to the upload page?

La respuesta es:

Cookie

Modificando la cookie relacionada con nuestra sesión y nivel de acceso conseguimos acceder a funcionalidades que normalmente estaban restringidas al usuario admin.

Esto representa una vulnerabilidad de:

Broken Access Control

El servidor debería comprobar en su lado qué privilegios tiene realmente el usuario, en lugar de confiar directamente en valores modificables desde el navegador.

Enumeración de Usuarios

Continuamos navegando por la aplicación web y accedemos a la sección Account. Al observar la URL, podemos comprobar que la aplicación utiliza
un identificador numérico para determinar qué usuario se está consultando. Comprobamos que somos el usuario guest, cuyo perfil aparece
asociado al parámetro id=2.

Esto nos indica que los perfiles de usuario podrían estar siendo identificados mediante valores numéricos consecutivos. Como prueba, modificamos manualmente el parámetro id, cambiando su valor de 2 a 1, para comprobar si corresponde a otro usuario.

Al modificar el identificador conseguimos acceder a la información correspondiente al usuario administrador.

Entre los datos obtenidos se encuentra el Access ID del administrador:

34322

Este identificador resulta especialmente interesante porque posteriormente podemos modificar nuestra cookie de sesión para utilizar el Access ID del administrador
y obtener acceso a funcionalidades restringidas, como la página de subida de archivos.

Este comportamiento está relacionado con una vulnerabilidad de tipo:

IDOR / Insecure Direct Object Reference

Una vulnerabilidad IDOR se produce cuando una aplicación expone un identificador interno y permite acceder a recursos pertenecientes a otros usuarios
simplemente modificando dicho valor, sin realizar una comprobación adecuada de autorización en el servidor.

En este caso, la aplicación permite enumerar información de otros usuarios modificando directamente el parámetro id en la URL. Esto nos permite descubrir la
información del usuario administrador y obtener su Access ID, que posteriormente utilizaremos para escalar nuestros privilegios dentro de la aplicación.

Acceso a la Página de Upload

Con la información obtenida durante la enumeración de usuarios, ya conocemos el Access ID correspondiente al usuario administrador. El siguiente paso consiste en modificar los valores almacenados en nuestra cookie de sesión para intentar suplantar sus privilegios.

Abrimos las herramientas de desarrollo del navegador (DevTools) y modificamos los valores de las cookies, asignando el Access ID del administrador:

34322

También modificamos el valor correspondiente al rol de usuario, cambiándolo a:

admin

Esto demuestra que la aplicación confía en valores controlados directamente por el cliente para determinar los privilegios del usuario, sin realizar una validación adecuada en el servidor.

Después de modificar estos valores, conseguimos acceder a la sección Upload, una funcionalidad que originalmente estaba restringida a usuarios con
privilegios de administrador.

Esto es especialmente interesante porque una subida de archivos mal protegida puede permitir subir archivos ejecutables.

En este caso, aprovechamos esta funcionalidad para subir un archivo PHP que contiene una reverse shell, con el objetivo de obtener ejecución de comandos en la máquina objetivo.

Creación de la Reverse Shell

Creamos un archivo PHP:

nano revshell.php

El archivo contiene una reverse shell configurada con nuestra dirección IP de VPN de Kali y el puerto en el que íbamos a escuchar.

En nuestra máquina Kali iniciamos un listener:

nc -lvnp 4444

La comunicación puede representarse de la siguiente forma:

Oopsie
   │
   │ Reverse Connection
   ▼
10.10.14.x:4444
   │
   ▼
Kali
nc -lvnp 4444

Subimos el archivo PHP utilizando la funcionalidad de upload disponible para el administrador.

Localización del Archivo Subido

Después de subir el archivo necesitamos localizar la ruta donde el servidor lo ha almacenado.

Probamos con el directorio habitual:

/uploads

La respuesta del servidor indicó que el directorio existía.

Por tanto, el archivo subido se encontraba en:

/uploads

Esta es la respuesta a la pregunta:

On uploading a file, what directory does that file appear in on the server?

Respuesta:

/uploads

Obtención de la Reverse Shell

Con el listener preparado en Kali, accedemos al archivo PHP subido:

http://10.129.x.x/uploads/revshell.php

Al ejecutarse el archivo, la máquina víctima establece una conexión hacia nuestra máquina Kali.

Comprobamos la terminal de Kali que tiene el listener y vemos que hemos obtenido la shell.

Obtenemos así una shell inicial como el usuario utilizado por el servidor web.

Antes debemos estabilizar la shell.

Antes de nada, conviértela en una TTY completa para poder usar autocompletado, Ctrl+C, editores, etc.:

python3 -c 'import pty; pty.spawn("/bin/bash")'

Luego, en la misma shell:

export TERM=xterm

Y en tu terminal de Kali (fuera de la shell, con Ctrl+Z para suspenderla):

stty raw -echo; fg

Al volver a la shell pulsa Enter un par de veces y ya tendrás una shell interactiva casi completa.

(O`R AQUI VOY, comprobar en kali para estabilizar la shell)

Comprobamos nuestra identidad:

whoami

Resultado esperado:

www-data

Ya tenemos un initial foothold dentro de la máquina.

Enumeración del Sistema

Una vez dentro de la máquina continuamos con la enumeración del sistema.

Buscamos archivos de configuración, credenciales y posibles usuarios del sistema que puedan
permitir movimiento lateral.

Durante esta enumeración encontramos un archivo que contenía una contraseña compartida con
el usuario robert.

El archivo era:

db.php

Esta es la respuesta a la pregunta:

What is the file that contains the password that is shared with the robert user?

Respuesta:

db.php

Dentro del archivo encontramos credenciales que podían reutilizarse para acceder como el usuario
robert.

Acceso como Robert

Utilizamos las credenciales encontradas para conectarnos mediante SSH:

ssh robert@10.129.x.x

Después de autenticarnos obtenemos una shell estable como:

robert@oopsie:~$

Esto representa un movimiento lateral desde el usuario del servidor web hacia un usuario local
del sistema.

Enumeración de Privilegios

El siguiente objetivo es comprobar si el usuario robert puede ejecutar programas
con privilegios elevados.

La pregunta de HTB nos proporciona una pista:

What executable is run with the option "-group bugtracker"
to identify all files owned by the bugtracker group?

La respuesta es:

find

Podemos utilizar:

find / -group bugtracker 2>/dev/null

Este comando busca en el sistema archivos pertenecientes al grupo:

bugtracker

Durante esta enumeración encontramos:

/usr/bin/bugtracker

Identificación del Binario SUID

Comprobamos los permisos del binario:

ls -la /usr/bin/bugtracker

El resultado muestra un permiso similar a:

-rwsr-xr--

La letra:

s

indica que el binario tiene configurado el bit:

SUID

SUID significa:

Set owner User ID

Cuando un ejecutable tiene el bit SUID activado, puede ejecutarse utilizando los privilegios del
propietario del archivo.

En este caso, el propietario es:

root

Por tanto, independientemente del usuario que ejecute el binario:

/usr/bin/bugtracker

el programa utilizará privilegios de:

root

Análisis de Bugtracker

Ejecutamos el binario:

/usr/bin/bugtracker

El programa solicita un Bug ID y posteriormente intenta mostrar información relacionada con
ese identificador.

Durante el análisis descubrimos que el binario llama al ejecutable:

cat

Sin embargo, lo hace de forma insegura.

El programa no utiliza una ruta absoluta como:

/bin/cat

En su lugar, depende del valor de la variable de entorno:

PATH

Esto abre la posibilidad de realizar un ataque de:

PATH Hijacking

PATH Hijacking

Linux busca los ejecutables siguiendo el orden definido en la variable:

PATH

Podemos comprobarla mediante:

echo $PATH

Si conseguimos colocar un directorio controlado por nosotros al principio del PATH, podemos
hacer que el sistema ejecute nuestro propio archivo antes que el ejecutable legítimo.

En este caso, el objetivo es crear un ejecutable llamado:

cat

El binario bugtracker intentará ejecutar cat, pero encontrará primero
nuestro archivo malicioso.

Explotación mediante PATH Hijacking

Creamos un directorio temporal:

mkdir /tmp/path

Entramos en él:

cd /tmp/path

Creamos un archivo llamado:

cat

El archivo ejecutará una shell:

nano cat

Añadimos:

#!/bin/bash
/bin/bash

Guardamos el archivo y le damos permisos de ejecución:

chmod +x cat

A continuación modificamos nuestra variable PATH para colocar nuestro directorio al principio:

export PATH=/tmp/path:$PATH

Comprobamos qué ejecutable será utilizado:

which cat

El resultado debería mostrar:

/tmp/path/cat

Obtención de Root

Una vez modificado el PATH ejecutamos nuevamente:

/usr/bin/bugtracker

Cuando el binario intenta ejecutar cat, en lugar de utilizar el ejecutable legítimo,
ejecuta nuestro archivo.

Como bugtracker tiene el bit SUID y pertenece a root, nuestro código
se ejecuta con privilegios elevados.

Comprobamos nuestra identidad:

whoami

Resultado:

root

También podemos comprobarlo mediante el prompt:

root@oopsie:~#

Esto confirma que la escalada de privilegios ha sido exitosa.

Obtención de la Root Flag

Una vez obtenida la shell como root, accedemos al directorio:

cd /root

Enumeramos su contenido:

ls

Finalmente leemos la flag:

cat root.txt

✅ Root flag obtenida con éxito.

Preguntas de Hack The Box

Herramientas Utilizadas

Vulnerabilidades y Técnicas

Lecciones Clave

• La enumeración web puede revelar funcionalidades que no son visibles desde la página principal.
• Un proxy como Burp Suite permite interceptar, inspeccionar y modificar peticiones HTTP.
• Las aplicaciones nunca deberían confiar en valores de privilegios enviados directamente por el cliente.
• Los identificadores de usuario deben comprobarse correctamente para evitar vulnerabilidades IDOR.
• Las funcionalidades de subida de archivos deben validar estrictamente el tipo y contenido de los archivos.
• Las credenciales no deben almacenarse directamente en archivos accesibles desde usuarios comprometidos.
• Los binarios SUID deben revisarse cuidadosamente porque pueden ejecutarse con privilegios elevados.
• Los programas privilegiados deben utilizar rutas absolutas para ejecutar otros binarios.
• La variable PATH puede ser manipulada para secuestrar la ejecución de programas si no se implementan controles adecuados.
• Varias vulnerabilidades aparentemente pequeñas pueden encadenarse hasta conseguir acceso completo al sistema.

Conclusión

Oopsie demuestra cómo una cadena de vulnerabilidades relativamente sencillas puede terminar en
el compromiso completo de una máquina.

El ataque comienza con la enumeración de una aplicación web y el descubrimiento de una página de
login oculta. Posteriormente, la manipulación de cookies y la enumeración de identificadores
permiten escalar desde un usuario guest hasta obtener acceso a funcionalidades de administrador.

El acceso a la funcionalidad de subida de archivos permite obtener una shell inicial en el servidor
mediante una reverse shell PHP.

A continuación, la enumeración del sistema revela credenciales reutilizadas que permiten acceder
como el usuario robert mediante SSH.

Finalmente, un binario SUID configurado de forma insegura permite abusar de la variable
PATH y ejecutar código con privilegios de root.

Resultado: compromiso completo de la máquina mediante Web Enumeration → Broken Access Control → File Upload → Credential Reuse → SUID PATH Hijacking.

⚠️ Aviso Legal

Este contenido es exclusivamente educativo.

Todas las pruebas fueron realizadas en un laboratorio controlado de
Hack The Box.

No utilices estas técnicas contra sistemas, aplicaciones o redes sin autorización explícita.