CTF Morpheus: 1 – Parte 4: Análisis de Riesgo y Bastionado Web

Evaluación de fallos en el manejo de archivos en Morpheus: 1 y directrices de auditoría para el bastionado defensivo de servidores web.

CTF - Matrix Breakout 04

Introducción: En esta cuarta entrega sobre el entorno pedagógico Matrix BreakOut (Morpheus: 1), analizamos desde una perspectiva defensiva qué ocurre a nivel de sistema operativo cuando una aplicación web permite la modificación de rutas en disco y cuáles son las fases obligatorias de bastionado web que debe aplicar un auditor.

📺 Serie de videos de referencia: Playlist CTF – Matrix BreakOut

🔗 Videos de contexto analítico:
– Matrix18 a Matrix20 – Inspección del flujo de procesamiento e I/O

CTF - Matrix Breakout 04
ALT-TEXT: Máquina Matrix BreakOut – Parte 04.

Por qué es importante

En la administración de sistemas y desarrollo seguro, el principio de defensa en profundidad establece que la seguridad no debe depender únicamente de que el código no falle. Cuando una aplicación comete el error de aceptar nombres de archivo controlados por el cliente, el sistema operativo y el servidor web (Apache/Nginx) deben poseer restricciones suficientes para contener el impacto:

  1. Evitar la ejecución arbitraria: Un archivo almacenado por usuarios jamás debería interpretarse como código ejecutable por el motor PHP.
  2. Contención del contexto de ejecución: El usuario de servicio (www-data) debe operar bajo el principio de mínimos privilegios, impidiendo que una falla en una aplicación exponga configuraciones globales del sistema.

Desarrollo

Módulo 1: Anatomía de la Falla: Confianza Ciega en Parámetros del Cliente

1. Análisis del comportamiento defectuoso en la aplicación

  • Qué ocurre a nivel de sistema: La rutina del backend recibe el contenido del mensaje y el nombre del archivo de destino desde la petición HTTP. Al no existir validación en el servidor, este delega una operación de apertura y escritura (fopen, file_put_contents) con la ruta provista directamente por el navegador.
  • Por qué representa un riesgo crítico: Permite la sobrescritura de archivos estáticos existentes o la creación de nuevos archivos con extensiones interpretables por el servidor web (como .php). Esto convierte un almacenamiento inocuo de texto plano en un canal de procesamiento de instrucciones en el contexto del usuario del servidor web.
  • Qué evaluar como auditores: Verificar que toda entrada destinada al sistema de archivos sea tratada como no confiable. Ningún valor originado en un <input type="hidden"> debe considerarse seguro.

Módulo 2: Directrices de Hardening para el Servidor Web (Apache)

2. Restricción de ejecución por directorio

  • Qué se debe configurar: Desactivar la capacidad del servidor web de interpretar scripts dentro de directorios de subida o contenido dinámico de usuarios (como carpetas de logs o cargas de texto).
  • Implementación conceptual en configuración (/etc/apache2/sites-available/):
  • Eliminar la directiva ExecCGI en las carpetas de almacenamiento.
  • Anular la interpretación de extensiones ejecutables mediante directivas directas de Apache:
    apache
    <Directory "/var/www/html/uploads">
    php_admin_flag engine off
    Options -ExecCGI -Indexes
    AllowOverride None
    </Directory>
  • Por qué se hace: Aunque la aplicación permita guardar accidentalmente un archivo con extensión .php, el servidor web lo entregará como texto sin procesar o denegará su acceso, neutralizando por completo el vector de ejecución remota.

Módulo 3: Principio de Mínimos Privilegios en el Sistema de Archivos

3. Auditoría de permisos de usuario y grupo (Discretionary Access Control)

  • Qué se debe auditar: La propiedad (owner:group) y los permisos POSIX de los archivos en la raíz del documento web (/var/www/html/).
  • Regla de oro de administración:
  • El usuario que ejecuta el demonio web (www-data) no debe ser el dueño del código fuente.
  • Los archivos estáticos y scripts .php deben pertenecer a un usuario administrador (por ejemplo, deployer:www-data) con permisos de solo lectura (644 para archivos, 755 para directorios).
  • Solo aquellos directorios estrictamente necesarios para almacenar datos persistentes deben contar con permisos de escritura para el grupo www-data, combinados con las restricciones de ejecución vistas en el Módulo 2.

Módulo 4: Hardening en el Motor PHP (php.ini)

4. Confinamiento de funciones y rutas

  • Qué se debe implementar: Reducir la superficie de ataque mediante directivas globales en la configuración de PHP:
    1. open_basedir: Limita las operaciones de entrada/salida de PHP exclusivamente a directorios autorizados, evitando lecturas fuera del árbol web.
    2. disable_functions: Deshabilitar la ejecución de llamadas al sistema operativo desde scripts de aplicación que no las requieran:
    ini
    disable_functions = exec,passthru,shell_exec,system,proc_open,popen
  • Por qué se hace: En caso de que se logre escribir un script no autorizado, el intérprete de PHP bloqueará las llamadas a binarios del sistema, impidiendo la generación de procesos secundarios.

Conclusión

El análisis de Morpheus: 1 demuestra que una aplicación vulnerable es el catalizador, pero la ausencia de bastionado en el sistema operativo y el servidor web es lo que permite que una falla de validación escale a un compromiso del host. La labor de un auditor no termina al señalar el error en el formulario; culmina al diseñar las capas defensivas que mitiguen el impacto residual.

💡 Próximos pasos: En la siguiente entrega abordaremos la auditoría de post-compromiso: cómo auditar las configuraciones internas de Linux para prevenir movimientos laterales o escalamiento de privilegios indebido.

Recursos útiles

Enlaces del curso y laboratorio:
– Playlist completa en YouTube
– Parte 2: Fuzzing Web y Análisis del Vector
– Parte 3: Auditoría NSE y Servicios Auxiliares

Guías de referencia defensiva:
– CIS Apache HTTP Server Benchmark
– OWASP Secure Coding Practices – Quick Reference Guide
– PHP Security Manual: File System Security