Este laboratorio está catalogado con la dificultad "Medio" y su autor es "El Pingüino de Mario".

ATENCIÓN

Las herramientas y técnicas utilizadas en la resolución de este laboratorio han sido ejecutadas en un entorno controlado. El autor de esta publicación no se hace responsable del mal uso que se haga de estas, ya que el objetivo final de esta publicación es transmitir conocimientos con fines éticos y educativos.

Resumen de contenido sobre este laboratorio

Tags: Seguridad Web, Bug Bounty, Cross-Site Request Forgery (CSRF)

• Explotación de un Cross-Site Request Forgery (CSRF) en la funcionalidad de cambio de contraseña, permitiendo cambiar la contraseña desde un origen distinto. Requisito necesario para completar el nivel 1.
• Explotación de un Cross-Site Request Forgery (CSRF) en la funcionalidad de actualización de campo "Biografía", permitiendo cambiar su valor desde un origen distinto. Requisito necesario para completar el nivel 2.
• Obtención de credenciales en texto plano y explotación de un binario SUID, permitiendo acceso al sistema mediante el servicio SSH y escalar privilegios al usuario root.

Reconocimiento inicial

Se inicia el reconocimiento mediante un ping a la máquina. Esto se hace por un lado para detectar que la máquina se encuentra accesible y por otro lado para poder detectar el sistema operativo mediante el TTL asignado.

ping -c 1 172.17.0.2

Se puede comprobar que el TTL asignado es 64, indicando que la máquina está accesible directamente sin ningún nodo intermediario y por otro lado que el sistema subyacente es GNU/Linux.

Una vez hecho esto, se realiza un reconocimiento de los servicios disponibles en dos fases. En la primera, se realiza un escaneo de todos los puertos TCP usando nmap para detectar en primera instancia cuales de ellos son accesibles (open), utilizando un escaneo TCP SYN.

sudo nmap -sS -p- --min-rate 1000 -n -Pn 172.17.0.2 -oN allPorts

En la segunda, se realiza un reconocimiento básico de los servicios subyacentes también mediante el uso de nmap. Esta vez, realizando dicha tarea de reconocimiento únicamente en los puertos detectados como abiertos.

nmap -sCV -p 22,5000 -n -Pn 172.17.0.2 -oN services

En este caso, se omite el escaneo de puertos UDP, ya que para esta máquina en particular no tiene ningún servicio relevante para llevar a cabo el ejercicio.

Acceso inicial (balulero)

En este caso se detecta que hay dos puertos abiertos:

• Puerto 22 (servicio SSH, OpenSSH)
• Puerto 5000 (servicio HTTP, Werkzeug / Python)

Además, gracias a la detección del servicio, se detecta que el sistema subyacente es Debian.

Nivel 1 — CSRF en funcionalidad de cambio de contraseña

Tras revisar el puerto 5000, se muestra la página de un "laboratorio CSRF" que invita a iniciar sesión.

URL -> http://172.17.0.2:5000/login

Al no disponer de credenciales, se pulsa en el enlace "¿No tienes cuenta? Regístrate" para acceder a un formulario de registro.

URL -> http://172.17.0.2:5000/register

Tras crear una cuenta, se vuelve a acceder al formulario de inicio de sesión para introducir las credenciales.

(registro realizado)
URL -> http://172.17.0.2:5000/login

Una vez introducidas las credenciales, se obtiene acceso a una funcionalidad de registro de tareas pendientes o TODO list.

URL -> http://172.17.0.2:5000/todois

En la parte superior derecha se puede apreciar un enlace "Panel" que permite acceder al panel de control del usuario. En este existe una funcionalidad para poder cambiar la contraseña del usuario.

(pulsar en "Panel")
URL -> http://172.17.0.2:5000/dashboard

Parece que esta funcionalidad es la que hay que explotar para avanzar en el laboratorio, ya que el propio formulario indica que es vulnerable a CSRF y que se intente cambiar la contraseña desde una fuente externa.

CSRF o Cross-Site Request Forgery es una vulnerabilidad que permite que una aplicación acepte peticiones emitidas por un tercero como si vinieran del usuario legítimo.

Es crítica porque aprovecha la sesión activa del usuario para ejecutar acciones sin su consentimiento. Si no se mitiga, puede derivar en cambios de datos no intencionados, operaciones sensibles no autorizadas o compromisos de cuenta.

Para comprobar que es vulnerable, se intercepta la petición con Burp Suite y se procede a introducir una contraseña y a pulsar en el botón "Actualizar Contraseña".

Al revisar la petición interceptada, se puede comprobar que esta no incluye ningún token anti-CSRF lo que puede dar a entender que sea vulnerable.

Por ello, para probar que es vulnerable, se modifica la cabecera Origin (también valdría con Referer) para simular que la petición se envía desde un origen distinto.

Origin: localhost
(también valdría -> Referer: localhost)

Tras mandar la petición, se puede comprobar que en la página de cambio de contraseña automáticamente salta un pop-up indicando que se ha conseguido explotar la vulnerabilidad CSRF, mostrando así el enlace y las credenciales para acceder al siguiente nivel.

URL -> http://172.17.0.2:5000/change-password

Nivel 2 — CSRF al actualizar el campo "Biografía"

Tras acceder al enlace proporcionado por el botón "Acceder al Nivel 2" en el anterior pop-up, este solicita unas credenciales.

URL -> http://172.17.0.2:5000/csrf-level2

Al proporcionar las credenciales, se redirige a la página de perfil del usuario donde muestra su información y la opción de actualizar cada dato de forma individual.

URL -> http://172.17.0.2:5000/csrf-level2

Nuevamente, parece que este apartado es el que hay que explotar para avanzar en el laboratorio, ya que el propio formulario indica que uno de los campos es vulnerable a CSRF y que el resto están protegidos con tokens CSRF.

Por ello, para comprobar cual de ellos no está protegido con un token CSRF, se realiza e intercepta la petición para actualizar cada uno de los campos de forma individual. Al hacerlo, se puede comprobar que efectivamente usan un token CSRF que se envía en el cuerpo de la petición para protegerse de esta vulnerabilidad.

Tras revisar cada operación de actualización de campo, se comprueba que en este caso la petición para actualizar el campo "biografía" no incluye un token CSRF en el cuerpo de la petición, lo que puede indicar que este sería el vulnerable.

Por ello, para probar que es vulnerable, se modifica la cabecera Origin (también valdría con Referer) para simular que la petición se envía desde un origen distinto.

Origin: localhost
(también valdría -> Referer: localhost)

Tras mandar la petición, se puede comprobar que en la página del perfil de usuario salta un pop-up indicando que se ha conseguido explotar la vulnerabilidad CSRF, acompañado de unas credenciales para el servicio SSH en texto plano asociadas al usuario "balulero".

URL -> http://172.17.0.2:5000/csrf-level2

De esta forma, es posible acceder a través del servicio SSH al sistema como el usuario "balulero".

ssh balulero@172.17.0.2
yes (aceptar conexión sin comprobar autenticidad)
<introducir la contraseña descubierta>
whoami
id
hostname

Escalada de privilegios (balulero -> root)

Al revisar el directorio principal de este usuario, este contiene un archivo "hint.txt" con una serie de pistas para escalar privilegios. Tras buscar binarios con SUID, se detecta "/usr/bin/env", cuyo propietario es el usuario "root".

ls -al
cat hint.txt
find / -perm -4000 2>/dev/null
ls -al /usr/bin/env

Comprobando este binario en GTFObins, se puede comprobar que existe una manera probada de aprovechar este binario para realizar operaciones aprovechando los privilegios asignados.

Referencia: https://gtfobins.github.io/gtfobins/env/#suid

En este caso, es posible abrir una consola interactiva como el usuario "root" directamente.

/usr/bin/env /bin/bash -p
whoami
id
hostname

En este punto, al haber obtenido acceso a la cuenta "root", se ha conseguido obtener los máximos privilegios posibles sobre el sistema objetivo (este laboratorio).

Mitigaciones a aplicar

• Para evitar la vulnerabilidad CSRF se deben usar tokens anti‑CSRF en cada petición sensible, asegurando que solo el usuario legítimo pueda generarlos. También se puede configurar las cookies con SameSite para que no viajen desde otros sitios y validar Origin/Referer cuando sea posible. Combinando estas medidas se bloquea que terceros ejecuten acciones en nombre del usuario.
• Ajustarse al principio de privilegio mínimo y conceder a los usuarios del sistema única y exclusivamente los privilegios que vayan a necesitar. Aplica de la misma forma para recursos del sistema y sus permisos. Recomendación: existen guías de hardening como "CIS Benchmarks" para aplicar buenas prácticas y asegurar entre otras cosas, los permisos para distintos tipos de software y sistemas expuestos en Internet.

¿Te gustó esta publicación? Sígueme y descubre más en mi blog principal: https://pyth0nk1d.medium.com