PressEnter

Introducción

Este documento presenta la resolución completa de la máquina PressEnter, diseñada por d1se0 para la plataforma DockerLabs y clasificada como fácil.

El objetivo es ofrecer un análisis claro, ordenado y técnicamente fundamentado que incluya:

• Identificación de vectores de entrada.
• Explotación basada en credenciales expuestas y técnicas de enumeración.
• Recuperación de información sensible desde la aplicación y su almacenamiento.
• Escalada de privilegios mediante transición entre cuentas locales.

La metodología empleada se articula en tres fases principales:

1. Reconocimiento: detección de puertos y análisis del contenido web.
2. Explotación: obtención de credenciales y acceso inicial a la aplicación.
3. Escalada de privilegios: movimiento lateral y obtención de permisos de mayor nivel.

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

---

Información General

Atributo	Valor
Nombre	PressEnter
Autor	d1se0
Dificultad	Fácil
Fecha	29/08/2024
Plataforma	DockerLabs

---

Paso 0 — Preparación y despliegue

Descomprimir la máquina:

unzip PressEnter.zip

Arrancar el contenedor:

sudo bash auto_deploy.sh PressEnter.tar

El script de despliegue devuelve la IP interna que utilizaremos durante el análisis:

---

Paso 1 — Reconocimiento

1.1 Organización del entorno de trabajo

Crear y organizar un directorio de trabajo facilita la documentación y la trazabilidad:

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

1.2 Escaneo de puertos

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

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

Puertos detectados:

• 80/tcp — HTTP

Observación: en esta máquina el servicio HTTP es el vector principal; no había SSH expuesto directamente, por lo que la auditoría web es prioritaria.

1.3 Enumeración web (puerto 80)

Se usó gobuster para localizar rutas y recursos públicos en el servidor web:

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

Entre los hallazgos se detectó una referencia de dominio virtual: pressenter.hl. Para resolverlo localmente se añadió al archivo /etc/hosts la entrada correspondiente:

echo "172.18.0.2 pressenter.hl" | sudo tee -a /etc/hosts

Accediendo al dominio se cargó la página principal, que corresponde a un sitio WordPress:

Dado que es un WordPress, se procedió a enumerar usuarios y vectores específicos de WP con wpscan:

wpscan --url http://pressenter.hl --enumerate u,vp

Resultado: se obtuvieron nombres de usuario detectables por enumeración.

---

Paso 2 — Explotación (acceso inicial)

Con los usuarios identificados (pressi, hacker, etc.), se intentó un ataque de fuerza bruta contra los inicios de sesión de WordPress usando una lista de contraseñas conocida (por ejemplo rockyou.txt) únicamente dentro del entorno de pruebas:

wpscan --url http://pressenter.hl -l pressi -P /usr/share/wordlists/rockyou.txt

Tras la ejecución se obtuvo una credencial válida para un usuario del sitio:

Con las credenciales válidas se accedió al panel de administración de WordPress (/wp-admin) y se llegó al dashboard:

Vector de explotación: el editor de temas integrado en el dashboard (Theme File Editor) estaba habilitado. Esto permite editar archivos PHP del tema activo. Aprovechando este acceso, se añadió un fragmento de código PHP en el archivo index.php del tema twentytwentytwo para obtener ejecución remota en el servidor web.

Nota responsable: no incluyo aquí código de shells inversas ni payloads. En la práctica se sube un webshell o se incorpora una pequeña instrucción PHP que ejecute comandos remotos y se establece un listener local (por ejemplo con nc -nlvp <puerto>). Esta técnica sólo debe usarse en entornos de laboratorio y con permiso del propietario.

Se abrió un listener en la máquina atacante:

nc -nlvp 443

Se accedió a la URL que ejecuta el archivo modificado:

http://pressenter.hl/wp-content/themes/twentytwentytwo/index.php

Como resultado se consiguió una shell activa con los privilegios del proceso web (www-data o equivalente):

---

Paso 3 — Escalada de privilegios

Con una shell como www-data, se procedió a investigar el sistema en busca de archivos de configuración y credenciales reutilizadas.

3.1 www-data → enter (credenciales en wp-config.php)

Se localizó el archivo de configuración de WordPress:

/var/www/pressenter/wp-config.php

Dentro de wp-config.php se encuentran normalmente las credenciales de conexión a la base de datos MySQL. Extrayendo esa información se obtuvo un usuario y contraseña válidos:

Usando dichas credenciales se inició sesión en MySQL (ejemplo seguro de invocación con comillas apropiadas):

mysql -u admin -p'rooteable' -h 127.0.0.1

Dentro de la base de datos de WordPress se inspeccionó la tabla de usuarios (wp_users). Se recuperaron credenciales adicionales:

Con esas credenciales se autenticó la cuenta enter en el sistema:

3.2 enter → root

Una vez autenticado como enter, se comprobó la posibilidad de elevar privilegios a root. En este caso la cuenta enter poseía la contraseña de root o permisos para cambiar al usuario root mediante su:

su root
# introducir contraseña de enter

Con la contraseña correcta se consiguió una shell con UID 0 (root):

---

Fallos de Seguridad Identificados

1. Panel de administración con editor de temas habilitado: permitir la edición directa de archivos PHP desde el dashboard concede ejecución de código en el servidor web en caso de cuentas comprometidas.
2. Contraseñas en texto plano o reutilizadas: credenciales sensibles almacenadas en la base de datos o en archivos de configuración permiten pivotar entre servicios.
3. Exposición de credenciales de base de datos en wp-config.php: si el usuario/contraseña de la BD tiene privilegios elevados o es reutilizado, compromete todo el sistema.
4. Permisos y hardening insuficientes en la instalación de WordPress: falta de medidas como autenticación por fuerza mínima, bloqueo de intentos de login, MFA o políticas de contraseñas fuertes.
5. Ausencia de separación de privilegios entre servicios: el usuario de la base de datos y las cuentas del sistema no están correctamente restringidos.

---

Recomendaciones

1. Deshabilitar editor de archivos en WordPress Añadir a wp-config.php la línea:

   define('DISALLOW_FILE_EDIT', true);

   Esto evita que cuentas con acceso al dashboard modifiquen directamente el código PHP del tema/plugin.

2. Revisar y rotar credenciales

   • No reutilizar contraseñas entre servicios (DB, admins, sistema).
   • Usar contraseñas fuertes y, cuando sea posible, autenticación basada en claves o MFA.

3. Principio de menor privilegio para la base de datos

   • El usuario definido en wp-config.php debe tener sólo los privilegios estrictamente necesarios sobre la base de datos de WordPress.

4. Eliminar o sanear metadatos y artefactos expuestos

   • No publicar archivos o nombres que puedan revelar información sensible.

5. Hardenización del servidor web

   • Ejecutar el proceso web con un usuario de bajo privilegio (por ejemplo www-data) y restringir permisos de archivos.
   • Revisar umask, permisos de directorio (wp-content/uploads), y restricciones de ejecución en directorios de subida.

6. Registro y monitorización

   • Habilitar logging y alertas para cambios en archivos críticos y accesos inusuales al dashboard.

7. Protección contra fuerza bruta y enumeración

   • Implementar mecanismos anti-brute-force (rate limiting, bloqueo por IP) y limitar la exposición de usernames mediante plugins o políticas.

8. Auditoría periódica

   • Escanear la instalación WordPress con herramientas de seguridad y realizar revisiones periódicas de sudoers, servicios y cuentas.