CTF Morpheus: 1 – Parte 5: Auditoría Local y Hardening en Linux

Metodología de auditoría interna de permisos, análisis de límites de privilegios y hardening del sistema operativo Linux tras un incidente.

CTF - Matrix Breakout 05

Introducción: En esta quinta entrega sobre el entorno Matrix BreakOut (Morpheus: 1), abordamos la fase de auditoría linux interna y revisión de límites de privilegios, examinando cómo evaluar configuraciones locales erróneas y cómo aplicar bastionado a nivel de sistema operativo para neutralizar vectores de escalada no autorizada.

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

🔗 Videos de contexto analítico:

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

Por qué es importante

En un modelo de defensa en profundidad (Defense in Depth), se asume que cualquier servicio perimetral o aplicación web puede verse comprometido eventualmente. Si una cuenta de servicio sin privilegios (como www-data) es vulnerada, el sistema operativo debe actuar como una barrera estricta que impida el control total del host.

Los fallos de diseño más comunes en servidores Linux evaluados en auditorías incluyen:
1. Delegación de permisos excesivos: Asignación descuidada de capacidades sudo para binarios que permiten interactuar con el entorno del sistema.
2. Archivos y ejecutables con bits SUID mal gestionados: Binarios con privilegios elevados ubicados en rutas de escritura común o configurados sin necesidad operativa.
3. Tareas programadas desprotegidas: Scripts en cron ejecutados como root cuyos permisos permiten modificación por usuarios comunes.

Desarrollo

Módulo 1: Auditoría de la Configuración de Sudo (/etc/sudoers)

1. Evaluación de políticas de delegación de comandos

  • Qué se evalúa en el sistema: La directiva sudo -l para verificar qué comandos puede ejecutar la cuenta local sin requerir credenciales administrativas (NOPASSWD).
  • Por qué ocurre la falla: Es habitual que los administradores concedan permisos sudo sobre herramientas operativas (editores de texto, visualizadores como less o herramientas de red) para resolver problemas puntuales de despliegue, olvidando que estos programas cuentan con funcionalidades nativas de escape de shell o ejecución de comandos secundarios.
  • Acción de bastionado requerida:
  • Aplicar el principio de menor privilegio utilizando visudo para validar la sintaxis.
  • Restringir el uso de comodines (*) y evitar delegar permisos sudo sobre utilidades interactivas.
  • Si un servicio automatizado requiere permisos puntuales, restringirlo a parámetros fijos y scripts inmutables con permisos de solo lectura para el administrador.

Módulo 2: Inspección y Control de Binarios SUID/SGID

2. Revisión de permisos especiales en el árbol de directorios

  • Qué se evalúa en el sistema: Búsqueda y catalogación de binarios con el bit setuid activo en el almacenamiento:
    bash
    find / -perm -4000 -type f 2>/dev/null
  • Por qué ocurre la falla: Cuando un binario propio o una utilidad administrativa posee el bit SUID (chmod u+s), se ejecuta con los permisos del propietario (frecuentemente root). Si el binario cuenta con fallos de control de rutas (path traversal), llamadas no calificadas a dependencias o bibliotecas compartidas inseguras, permite ejecutar código en un contexto privilegiado.
  • Acción de bastionado requerida:
  • Realizar un inventario estricto de binarios SUID y retirar el bit a cualquier ejecutable que no lo requiera de forma crítica (chmod u-s /ruta/binario).
  • Montar particiones de escritura de usuario (/tmp, /var/tmp, /home) con la bandera nosuid en /etc/fstab para evitar la colocación de binarios especiales en zonas compartidas.

Módulo 3: Análisis de Tareas Programadas y Automatización (Cron Jobs)

3. Revisión de integridad en rutinas de mantenimiento

  • Qué se evalúa en el sistema: Inspección de tablas de cron del sistema (/etc/crontab, /etc/cron.*) y tareas configuradas por usuarios del sistema.
  • Por qué ocurre la falla: Frecuentemente se configuran tareas de mantenimiento periódico ejecutadas por root que llaman a scripts ubicados en carpetas con permisos de escritura permisivos (777 o propiedad de usuarios estándar). Un atacante con acceso inicial solo necesita modificar el contenido de ese script para que sea ejecutado con máximos privilegios en la siguiente iteración.
  • Acción de bastionado requerida:
  • Asegurar que todo script invocado por tareas de root pertenezca a root:root con permisos estrictos (700 o 750).
  • Utilizar rutas absolutas para todos los binarios y comandos definidos dentro del script para evitar secuestro de la variable PATH.

Módulo 4: Restricción de Kernel y Monitoreo con Auditd

4. Supervisión de integridad y restricciones de llamadas al sistema

  • Qué se evalúa en el sistema: Capacidad del sistema operativo para registrar intentos de elevación de privilegios anómalos o modificación de archivos críticos (/etc/passwd, /etc/shadow).
  • Acción de bastionado requerida:
  • Configuración de Auditd: Implementar reglas de auditoría para registrar invocaciones sospechosas de comandos administrativos y accesos a credenciales locales.
  • Parámetros del Kernel (sysctl.conf): Restringir el rastreo entre procesos por usuarios no privilegiados configurando kernel.yama.ptrace_scope = 2 o 3, reduciendo la superficie para inspeccionar memoria de otros procesos del sistema.

Conclusión

El cierre del análisis sobre Morpheus: 1 subraya una lección esencial para los estudiantes de seguridad: el acceso inicial a través de una aplicación web vulnerable solo resulta crítico si las defensas internas del sistema operativo fallan en contenerlo. El bastionado sistemático de sudoers, la eliminación de bits SUID innecesarios y la correcta asignación de permisos POSIX garantizan que un incidente perimetral quede confinado y no derive en un control total del sistema.

💡 Próximos pasos: Implementa un script de auditoría defensiva basado en las directrices CIS Benchmark para verificar el estado de los permisos de tu propio servidor de prácticas.

Recursos útiles

Guías oficiales de bastionado y estándares:
– CIS Distribution Independent Linux Benchmark
– Manual de administración segura de Sudo (Sudo Project)
– Linux Audit Daemon Documentation (Red Hat / Debian Docs)

Entregas anteriores del Writeup:
– Parte 1: Reconocimiento y Fuzzing
– Parte 2: Fuzzing Web y Análisis del Vector
– Parte 3: Auditoría NSE y Servicios Auxiliares
– Parte 4: Análisis de Riesgo y Bastionado Web