Bucket

Acerca de Bucket

Es una máquina Linux de dificultad media que cuenta con LocalStack que simula un entorno AWS local. La aplicación web se ejecuta en un servidor Apache y los archivos están alojados en un bucket S3 abierto que nos permite soltar un archivo PHP malicioso y así obtener una shell inversa. En el directorio personal del usuario podemos encontrar un proyecto inacabado que utiliza DynamoDB como base de datos. La enumeración de DynamoDB revela credenciales que pueden reutilizarse para moverse lateralmente. Se ha encontrado una aplicación interna que se ejecuta como root, lo que se aprovecha para obtener acceso de root.

Matriz de la máquina.

Características de explotación de la máquina.

*Sin actualizaciones.

Comienzo enumerando los puertos, servicios y versiones.

rustscan -a 10.10.10.212 -- -sCV -oN scan.txt

1) Superior a la version 6.9 que permite enumerar usuarios. apartir de la version 7.0 se implemento la opcion UsePAM, que permite utilizar el ‘Pluggable Authentication Module (PAM)’ para manejar la autenticación.

2) Apache 2.4.41.

3) Nombre de dominio.

4) Los metodos que podriamos utilizar por medio de curl, burpsuite y automatizar por medio de bash y python.

Agrego el dominio bucket.htb

echo "10.10.10.212 bucket.htb" | sudo tee -a /etc/hosts

Encuentro el subdominio s3., que carga las imágenes desde adserver.

Fuzzeo rutas ocultas sobre el subdominio. Encontrando “/shell”.

El servidor redirige a un nombre de host Docker interno (444af250749d) en el puerto 4566, es el puerto por defecto de LocalStack (emulador de servicios AWS) es como un mega almacén de archivos en la nube. Lo típico es usarlo para guardar archivos estáticos: las imágenes, CSS y JavaScript de una web, documentos, backups…., También la cabecera access-control-expose-headers: x-amz-version-id para controlar versiones de archivos. Básicamente, está emulando S3 localmente.”

La CLI de AWS busca automáticamente las credenciales en ~/.aws/credentials para acceder a servicios como S3, EC2, etc. Pero en este caso no tengo credenciales válidas ni acceso legítimo, el servidor s3., es una implementación custom de aws (LocalStack). Como es un CTF no válida las claves de aws reales, basta con generar los archivos de configuración y credenciales aleatorias.

Interfaz web de un intérprete de DynamoDB (AWS).

Genero un archivo php y lo subo para comprobar si el servidor lo ejecuta, resulta que el bucket no solo guardaba archivos, sino que Apache los ejecutaba como PHP.

A raíz de servirme el phpinfo, me centro en generar una revshell en php, subirlo y dirigirme al archivo para que se ejecute. Logrando así obtener acceso al servidor como usuario (www-data).

Estabilizo la terminal.

Encuentro interesante el archivo /project/db.php.

El código PHP que encontramos está intentando hablar con DynamoDB, lo más importante acá es la sección endpoint' => 'http://localhohst:4566', claramente está pensado como una sandbox.

Encuentro varias credenciales y las uso en los usuarios existentes, esto es parecido a encontrar credenciales en un excel o en un bloc de notas. seria el colmo que use como credenciales ‘Password123[]!'.

Efectivamente logro escalar al usuario roy reutilizando la contraseña: n2vM-<_K_Q:.Aa2.

El servicio no solo está mal configurado, sino que se ejecuta como root!,

“Esto ya no es ‘ojito, hay un fallito’, es ‘señores, tenemos un pánico en el servidor’. Ves ese archivo? Podría borrar toda la empresa en 3 segundos.”

Solo escucha en localhost:8000, asique realizo un portforwarding funciona como un espejo en mi entorno.

PD4ML es una librería para convertir HTML a PDF sospechosa en este contexto!.

Al final este portforward podria llamarlo acceso VIP. Ahora puedo chusmear la app con calma… y si puedo meter un PDF para Inyectar una revershell, obtener el id_rsa, buscar en /etc/shadow con el hash de root… ?

La aplicación espera una tabla llamada alerts en DynamoDB para generar reportes de ransomware… pero la tabla no existe!, creo la tabla “alerts”, para probar si la aplicación generaba PDFs sin filtrar, ingreso datos test con HTML inside.

Descargo el pdf o tambien puedo verlo por el puerto 8000 que me pase a mi maquina.

La app pide los datos de ‘ransomware’, le metí un HTML cualquiera… y lo convirtió en PDF sin filtrar.

Vuelvo a generar la tabla alerts. Esta vez apunto al /etc/passwd sin problema.

Obtengo el id_rsa de root, al no restringir el esquema file://, permite obtener cualquier dato del sistema.

Gano una sesión de root y obtengo su flag.

PD4ML confiaba ciegamente en el input HTML (nunca validó file://).

El servicio corría como root, cualquier lectura de archivos era game over.

DynamoDB (LocalStack), Permitía inyectar datos maliciosos sin restricciones.

pwned!.

quantumtandorisa Avatar

Posted by