En este writeup vamos a resolver una de las máquinas de la plataforma Dockerlabs llamada FindYourStyle, con el nivel de dificultad «Fácil».
Al final del write up te cuento un resumen de toda la máquina. 🙂 Algunos conceptos trabajados:
| Reconocimiento y escaneo de puertos Explotación de vulnerabilidad conocida (RCE) Obtención de acceso remoto al sistema Pivoting entre usuarios mediante credenciales expuestas Escalada de privilegios por abuso de binarios |
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.
Estructura del contenido
RECONOCIMIENTO Y 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 sus servicios y versiones.
El TTL es de 64 por lo que estamos ante una máquina Linux y vemos que la máquina está activa por la respuesta «Host is up«.
Ahora que sabemos que la máquina víctima está activa, procedemos escanear la red lanzando un nmap para detectar qué puertos están abiertos con el siguiente comando:
nmap -p- --open -sS --min-rate 5000 -vvv -n -Pn 172.17.0.2 -oN Escaneo
Sabemos por tanto que está abierto el puerto 80 HTTP.
Ahora lo que vamos a hacer es analizar qué servicios y versiones corren por ese puerto con el objetivo de poder analizar a detalle posibles vulnerabilidades.
Para ello lanzamos el siguiente comando:
nmap -sCV -p80 172.17.0.2
En este caso descubrimos que la versión que corre para el CMS Drupal es la 8, que además de verlo a través de nmap, y de revisarlo desde el código fuente, también lo podemos ver a través de lanzarle un whatweb para ver las tecnologías que usa esa máquina.
Si analizamos con searchsploit si existen vulnerabilidad públicas ya reportadas por la base de datos exploit-db , podemos ver que para nuestra versión 8 hay reportada una vulnerabilidad llamada «Drupalgeddon2» que permite la ejecución remota de comandos.
De hecho si hacemos una búsqueda en internet sobre cuál es el CVE oficial reportado, vemos como el propio INCIBE la reporta con el CVE-2018-7600.
Conocido el CVE podremos más adelante analizarla a través de Metasploit y de poder comprometerla.
Antes, me gusta aplicar un escaneo o fuzzing de posibles directorios, carpetas y ficheros ocultos que no son visibles a través de una investigación de la web, etc.
En este caso aplico con gobuster fuzzing sobre la IP Victima, y nos reporta algunas rutas y ficheros que ayudaría a escalar privilegios una vez podamos conseguir acceso al servidor.
gobuster dir -u http://172.17.0.2/ -w /usr/share/wordlists/dirbuster/directory-list-lowercase-2.3-medium.txt -x php,html,txt
Por ahora sólo los anotamos como potencial que podremos probar ya que solo el de /core/install.php nos reporta la versión del CMS (versión instalada 8.5.0, muy vieja) e información que no debería ser accesible, ya que en un Drupal bien configurado el archivo install.php se elimina o se bloquea y solo se usa durante la instalación inicial.
Que siga accesible significa una mala configuración que podría dar lugar a una reinstalación forzada o ejecución de código vía parámetros, etc.
Además, aparece un mensaje que dice “Drupal already installed” que nos dice que existe una base de datos funcional, que ya hay un settings.php activo y que por tanto el sitio está en producción, no en desarrollo. Esto puede implicar dos vectores clásicos de ataque, RCE sin autenticación y/o extracción de credenciales (DB / usuarios).
EXPLOTACIÓN DE VULNERABILIDAD RCE
Vamos a continuar la intrusión mediante el uso de Metasploit para conseguir RCE y obtener una shell para la escalada de privilegios.
Una vez iniciado Metasploit, podemos buscar o bien el CVE reportado de la vulnerabilidad conocida para ese versión, o buscar por la versión de drupal 8 que sabemos:
En este caso, vamos a usar el primer exploit «cero 0» que nos indican con un ranking excelente y que explota la vulnerabilidad drupalgeddon2, por lo que continuamos con «use 0» para activarla.
Después, con show options vemos las opciones que se abren para configurar el ataque.
Entre las que tenemos que modificar estarían:
- RHOSTS : IP de la máquina víctima
- TARGETURI : aquí tendríamos que apuntar a la ruta donde estuviera instalado el Drupal. En este caso muestra la raíz por defecto porque se aloja en todo el site, pero si estuviera en un directorio interno como /drupal , tendríamos que cambiarlo.
El resto de valores LHOST y LPORT que son la IP nuestra atacante y el puerto local 4444 sobre el que se levanta para recibir la shell, se quedarían tal cual.
Por tanto, una vez hemos definido el RHOSTS, simplemente le damos a «run» para ejecutar el ataque y esperamos a que termine.
OBTENCIÓN DE ACCESO REMOTO AL SISTEMA
Una vez tenemos la sesión de meterpreter, lo que tenemos que hacer es escribir «shell» para que se nos abra una consola que nos permita ejecutar comandos.
Y vemos el listado de archivos y ficheros ocultos, somos www-data que pertenece a estos grupos:
Una vez dentro, lo que hacemos es investigar por potenciales directorios y archivos que nos permitan extraer credenciales.
Es habitual en sitios web con Drupal analizar el fichero settings.php si es que existe, ya que suele exponer usuarios y contraseñas en texto claro. La ruta donde está ubicado suele ser en /var/www/html/sites/default … pero podemos aplicar este comando desde la raíz para encontrarlo:
find / -name settings.php 2>/dev/null
Una vez lo encontramos, si cateamos ese fichero y lo analizamos vemos este usuario y contraseña: «ballenita» y «ballenitafeliz«.
Otra opción para detectar potenciales usuarios en el servidor es con el comando:
cat /etc/passwd | grep "/bin/bash"
Vistas estas credenciales, lo que haremos será iniciar sesión desde el panel de login.
Y estamos dentro del panel del CMS como el usuario ballenita:
Si analizamos el dashboard del usuario ballenita, vemos que en la parte de People, se nos permite subir un archivo de imagen, por lo que podemos probar a subir una archivo php malicioso y ejecutarlo.
Sin embargo parece no funcionarme, quizás algo esté haciendo mal…por lo que trato de forzar la terminal para poder navegar en ella.
Para hacer esto, lanzo este script:
script /dev/null -c bashPIVOTING ENTRE USUARIOS
y nos cambiamos al usuario ballenita con las credenciales que tenemos, y vemos qué permisos de usuario tiene, y parece que podemos ejecutar root sin contraseña abusando de binarios:
Si vamos a GTFObins, podemos ver cómo escalar privilegios abusando del binario grep:
ESCALADA DE PRIVILEGIOS
Si usamos el siguiente comando abusando del binario podemos ver todos los ficheros que como root podríamos leer:
sudo grep -R '' /root
Si ahora aplicamos este comando listamos los ficheros existentes donde se encuentra la flag:
sudo ls /root
Y si lo abrimos con este comando ya podemos visualizarla:
sudo grep -n '' /root/secretitomaximo.txt
RESUMEN DE LA MÁQUINA FINDYOURSTYLE
| Comenzamos desplegando la máquina FindYourStyle de Dockerlabs y realizando el reconocimiento inicial. Verificamos que la máquina estaba activa y, mediante un escaneo con nmap, detectamos que únicamente tenía expuesto el puerto 80. Al analizar el servicio web, identificamos que corría un Drupal 8.5.0, una versión muy antigua y vulnerable. Mediante fuzzing con gobuster descubrimos rutas interesantes como /core/install.php, que confirmaban una mala configuración del CMS y nos daban información crítica sobre la versión instalada y el estado del sistema, lo que nos llevó a investigar vulnerabilidades públicas asociadas a esa versión.A continuación, explotamos la vulnerabilidad Drupalgeddon2 (CVE-2018-7600) usando Metasploit, lo que nos permitió conseguir ejecución remota de comandos y una shell como el usuario www-data. Una vez dentro del sistema, realizamos tareas de enumeración y localizamos el archivo settings.php, donde encontramos credenciales en texto claro correspondientes al usuario ballenita. Con estas credenciales accedimos al panel de administración de Drupal y, posteriormente, forzamos una TTY desde la consola para poder cambiar correctamente de usuario y pivotar desde www-data a ballenita.Ya como el usuario ballenita, enumeramos sus privilegios con sudo -l y descubrimos una mala configuración que permitía ejecutar los binarios ls y grep como root sin contraseña. Aunque no era posible obtener una shell interactiva como root, abusamos del binario grep para leer archivos protegidos del sistema con privilegios elevados. De esta forma accedimos al directorio /root, listamos su contenido y finalmente leímos la flag almacenada en secretitomaximo.txt, completando así la máquina mediante una escalada de privilegios por abuso de binarios permitidos por sudo (GTFOBins). |
