DockerLabs Writeup — Perrito Mágico (Spanish)

A continuación, describo la guía de resolución del laboratorio de DockerLabs denominado “Perrito Mágico”.

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: Bug Bounty, Divulgación de información, Mala configuración en control de acceso basado en roles (RBAC), Privilegios SUDO, Seguridad API

• Revisión de documentación de la API de DockerLabs expuesta junto a una sesión activa en BunkerLabs para explotar una mala configuración de roles en uno de los recursos de la API que permite cambiar la imagen del logo de la maquina elegida. Resulta en obtención de credenciales en texto plano permitiendo acceso al sistema mediante el servicio SSH como el usuario balulerobalulito.
• Encontrado un binario con privilegios SUDO que permite escalar privilegios al contexto del 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 (balulerobalulito)

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 Ubuntu.

Tras revisar el puerto 5000, se muestra un clon de la página de **BunkerLabs**.

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

Como se puede apreciar a simple vista, se muestra un mensaje que indica **Acceso concedido., dando a entender que se ha accedido directamente al sitio de forma autenticada* sin introducir credenciales. Además, se puede verificar que se dispone de una cookie* de sesión activa para este sitio.

Abrir herramientas de desarrollador > Storage

Al revisar el directorio /api, este parece que expone la documentación de la API de DockerLabs. En el se muestran disponibles dos recursos: **/api/summary y `/gestion-maquinas/upload-logo`**.

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

El primero parece ser el encargado de devolver las máquinas, creadores y writeups disponibles. No requiere ningún parámetro adicional ni autenticación, ya que es un recurso utilizado para poblar la página principal con el contenido necesario.

Se puede probar que funciona como era de esperar realizando una petición con cURL.

curl -s http://172.17.0.2:5000/api/summary

El segundo en cambio parece ser que se utiliza para actualizar el logo de una máquina seleccionada. En contraposición al primer recurso, este tiene parámetros obligatorios como el ID de la máquina, el origen o el nuevo logo. Además, este si requiere de autenticación para realizar operaciones de este estilo.

Se puede comprobar que en este caso existe una máquina denominada Dockerlabs-Weak, y seguramente esta sea la que se deba utilizar para explotar la vulnerabilidad de esta API.

Al haber una única máquina, se supone que el valor del parámetro “machine_id” es “1” para esta.

URL -> http://172.17.0.2:5000/bunkerlabs
(click en "Dockerlabs-Weak")

Los posibles valores para el parámetro “origen” no se especifican en la documentación. Sin embargo, es posible obtenerlos revisando el código público de DockerLabs. Se detectan dos: “docker” y “bunker”.

Como el apartado del laboratorio corresponde a “BunkerLabs”, el valor a asignar debe ser “bunker” para que funcione.

URL -> https://github.com/Maalfer/dockerlabs/blob/main/dockerlabs/routes/machines.py
...

Valores encontrados para "origen": ["docker", "bunker"]

El parámetro “logo” debe ser una imagen válida a elección.

Tras confeccionar la petición a realizar y enviarla, esta parece que responde con un error, donde indica que falta un token CSRF.

curl -X POST http://172.17.0.2:5000/gestion-maquinas/upload-logo -H "Cookie: session=<RECORTADO>" -F "machine_id=1" -F "origen=bunker" -F "logo=@Pyth0nK1d.png"
...
{"error":"CSRF token missing"}

El token CSRF necesario para la petición se puede obtener revisando el código fuente de la página principal.

URL -> view-source:http://172.17.0.2:5000/bunkerlabs

Tras acertar con el nombre del parámetro necesario para el token CSRF, parece que se consigue realizar el cambio de imagen.

Además, en la propia respuesta muestra un mensaje dando la enhorabuena por haber conseguido explotar la vulnerabilidad, acompañado por unas credenciales asociadas al usuario balulerobalulito para poder acceder a través de SSH.

curl -X POST http://172.17.0.2:5000/gestion-maquinas/upload-logo -H "Cookie: session=<RECORTADO>" -F "csrf-token=<RECORTADO>" -F "machine_id=1" -F "origen=bunker" -F "logo=@Pyth0nK1d.png"
...
{"error":"CSRF token missing"}

curl -X POST http://172.17.0.2:5000/gestion-maquinas/upload-logo -H "Cookie: session=<RECORTADO>" -F "csrf_token=<RECORTADO>" -F "machine_id=1" -F "origen=bunker" -F "logo=@Pyth0nK1d.png"
...
¡Enhorabuena!

Al recargar la página principal, se puede ver este mismo mensaje de enhorabuena dentro de un pop-up.

URL -> http://172.17.0.2:5000/bunkerlabs
(recargar página)

Tras cerrar el pop-up y pulsar en la única máquina existente denominada Dockerlabs-Weak, se puede apreciar que efectivamente se ha actualizado la imagen satisfactoriamente.

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

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

Escalada de privilegios (balulerobalulito -> root)

Al listar los privilegios SUDO, se puede comprobar que el usuario “balulerobalulito” puede ejecutar el binario “/usr/bin/nano” como cualquier usuario del sistema sin proporcionar contraseña. Esto viene definido de la siguiente forma tras listar sus privilegios:

• (ALL) NOPASSWD: /usr/bin/nano

sudo -l

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.org/gtfobins/nano/#shell

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

sudo -u root /usr/bin/nano
CTRL+R CTRL+X
reset; sh 1>&0 2>&0
clear
/bin/bash

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).

BONUS: Revisión de la vulnerabilidad en la API

Tras revisar el contenido del recurso API encargado del cambio del logo de maquinas tiene permitido su uso a los usuarios con rol “jugador”, o lo que es lo mismo, cualquier usuario registrado y autenticado en la aplicación.

Esto permite que cualquier usuario autenticado pueda cambiar el logo de cualquier máquina disponible en la aplicación.

cd /app/dockerlabs
more maquinas.py

Nota importante: Esta vulnerabilidad corresponde a una versión antigua de la API y esto ya no se permite en la versión actual.

Mitigaciones a aplicar

• Almacenar la información sensible de forma segura (por ejemplo, utilizando gestores de contraseñas), evitando que esta pueda ser accedida por usuarios no autorizados.
• Ajustarse al principio de mínimo privilegio y centralizar la política de autorización por roles para evitar configuraciones inconsistentes o erroneas en recursos críticos de la aplicación.
• 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