Descubrir usuarios de Drupal con FOCA y ZAP Proxy

Drupal es un sistema de gestión de contenidos (CMS) de código abierto muy popular y ampliamente utilizado en Internet, debido a características tales como su facilidad de uso, flexibilidad gracias a la cantidad de módulos de los que dispone creados por una amplia comunidad de desarrolladores y a la escalabilidad que proporciona para sitios webs personales o empresariales. Hoy vamos a ver en este artículo cómo se puede sacar información de la plataforma para hacer un pentesting a un sistema Drupal configurado en el sitio web de una empresa.

Figura 1: Descubrir usuarios de Drupal con FOCA y ZAP Proxy

Cuando se realiza un ethical hacking, es importante conocer quiénes son los usuarios válidos que tienen acceso al sistema. De esta forma, en un ataque de fuerza bruta, el espacio de búsqueda se reduce a la mitad si el proceso de autenticación únicamente solicita usuario y contraseña y no hay un segundo factor de autenticación, como por ejemplo Latch para Drupal.


Figura 2: Cómo proteger Drupal con Latch
En esta PoC (Prueba de Concepto) se muestra cómo obtener usuarios válidos en sistemas de gestión de contenidos (CMS) basados en Drupal a través de los metadatos presentes en los documentos ofimáticos alojados en él. Latch, metadatos, MetaShield Protector, FOCA, hacking web... ¿cómo no le iba a gustar este artículo a Chema Alonso?

Drupal y el fichero robots.txt

Por defecto, Drupal incorpora un fichero robots.txt para tratar de evitar el rastreo e indexación en buscadores de ciertas partes del sitio web. Su contenido varía versión a versión y en la web de Drupal se puede acceder a la información del fichero robots.txt en cada una de las ramas. Así, si te encuentras un fichero robots.txt en su servidor podrás saber qué versión tienes en frente en función de su contenido. Un contenido tipo de robots.txt para un Drupal 6.x es como el que sigue.

Figura 3: Contenido de un fichero robots.txt para Durpal 6.x

Si tras la instalación del sitio basado en Drupal y su puesta en producción no ha sido modificado el fichero robots.txt, por ejemplo, podría realizarse un poco de fingerprinting para ver cuál es la versión actual del CMS y el número de veces que ha sido actualizado: tantas como líneas con el patrón “Drupal X.X.X, año-mes-día” aparezcan en el fichero CHANGELOG.txt cuya ruta proporciona el fichero robots.txt.

Figura 4: Changelog.txt de la propia web de Drupal

Esta información puede ser importante porque es posible conocer si el sitio web está actualizado a la última versión o no, o si existe algún exploit o vulnerabilidad conocida para la versión actual del CMS que corre en el servidor web.

Figura 5: Algunos exploits y vulnerabilidades para diferentes versiones de Drupal

El fichero robots.txt también proporciona una ruta importante para intentar realizar el descubrimiento de usuarios: /?q=user/password/ ¿Para que utilizar Drupal esta URL en su sistema?

Solicitar una nueva contraseña por correo electrónico

Drupal permite, por defecto, solicitar una nueva contraseña por correo electrónico. Para ello, únicamente hay que realizar una petición como la siguiente:

http: //www.sitioweb.com?q=user/password

De esta forma, el sistema solicitará el nombre de usuario o la cuenta de correo electrónico del usuario que desea solicitar una nueva contraseña.

Figura 6: Solicitud de una nueva clave por correo electrónico en una web con Drupal

En caso de introducir un nombre de usuario o dirección de correo electrónico de un usuario presente en el sistema, la respuesta por defecto será: “Se le han enviado más instrucciones a su dirección de correo-e.”

Figura 7: Respuesta frente a un usuario o cuenta de e-mail presente en el sistema

Si el nombre de usuario o la cuenta de correo electrónico no pertenece a ningún usuario presente en el sistema, el sistema por defecto responderá: “Lo siento, XXX no se reconoce como nombre de usuario o dirección de correo electrónico”.

Figura 8: Respuesta frente a un usuario o cuenta de e-mail incorrecta

Es decir, por defecto, Drupal “proporciona” un mecanismo que permite descubrir qué nombres de usuario están en el sistema y cuáles no, debido a las dos respuesta anteriores.

Obtención de nombres de usuarios de documentos ofimáticos

Los sitios web basados en Drupal de organismos públicos, como por ejemplo ayuntamientos, suelen tener muchos documentos ofimáticos con metadatos asociados. Haciendo un poco de Hacking con buscadores es fácil localizarlos:

Figura 9: Dorking para la búsqueda de sitios web de ayuntamientos hechos con Drupal

La idea es extraer el nombre de todos los usuarios presentes en los documentos ofimáticos y ver con cuáles de ellos pueden solicitar a Drupal una nueva contraseña por correo electrónico. Esos serán usuarios válidos presentes en el sistema.

Para ello, seleccionamos a uno de los ayuntamientos devueltos en los resultados de la Figura 9 y utilizamos la FOCA para la extracción de los usuarios presentes en los metadatos de los documentos ofimáticos alojados en la web.

Figura 10: Usuarios extraídos con FOCA de los documentos de un ayuntamiento

Almacenamos en un fichero de texto los usuarios encontrados por FOCA en los documentos ofimáticos, ya que será el payload que utilizaremos en el proceso de automatización para el descubrimiento de usuarios válidos.

Fuerza bruta basada en diccionario de usuarios de metadatos

Una vez que tenemos el fichero con los usuarios presentes en los documentos ofimáticos, lo único que tenemos que hacer es automatizar el proceso “de probar uno por uno” para ver, con cuál de ellos, el sistema es capaz de generar una nueva contraseña y enviarla por correo electrónico. Serán los nombres de usuarios válidos en el proceso de autenticación.

Para ello, mediante un Proxy HTTP/S como ZAP, tal y como explico en el capítulo de nuestro libro de Hacking Web Technologies, capturamos la petición HTTP de solicitud de cambio de contraseña con un usuario cualquiera:

Figura 11: Captura de petición HTTP para el cambio de contraseña

Tras capturar la petición HTTP, la reenviamos modificando el valor del parámetro name. Utilizamos para ello el Fuzzer que proporciona ZAP. Como payload usaremos el fichero con los usuarios descubiertos por la FOCA para que ZAP realice fuerza bruta basada en diccionario con todos ellos. Drupal por defecto no restringe este tipo de ataque.

Figura 12: Fuzzer preparado con el payload de usuarios

Tras esta primera prueba, ZAP Proxy arroja un resultado positivo con dos usuarios: Administrador y ADMIN.

Figura 13: Usuarios descubiertos en esta instalación de Drupal con el diccionario

Además, si analizamos las respuestas devueltas por el servidor web, puede observarse que el tiempo de respuesta con esos dos usuarios es menos al del resto de respuestas, el código HTTP también varía: 302 frente a 200 para el resto de usuarios. El tamaño de la cabecera HTTP también es diferente para estos dos usuarios: pasa de 391 bytes a 472 bytes y 473 bytes. El fuzzer de ZAP indica también, a través del TASK ID, el orden de los usuarios encontrados en el fichero generado con FOCA: el 2 y 23.

Figura 14: Orden de los dos usuarios descubiertos por ZAP y FOCA

Probando con uno de ellos vemos como efectivamente se trata del user de uno de los usuarios almacenados en Drupal.

Figura 15: Usuario ADMIN presente en el sistema

Conclusiones sobre esta PoC

A parte de eliminar los metadatos de los documentos ofimáticos antes de que estos sean colgados en Internet para que ningún usuario pueda quedar expuesto, tal y como indica el Esquema Nacional de Seguridad utilizando herramientas como las de MetaShield Protector, también es recomendable eliminar toda la información del fichero robots.txt que pudiera facilitar el descubrimiento de rutas y recursos de autenticación o de cambio de contraseñas, como de todas las actualizaciones y de la versión actual de Drupal que corre en el servidor web.

Figura 16: MetaShield Protector Client para Windows

Parece también una buena idea restringir la autenticación y la solicitud de nuevas contraseñas únicamente a ciertas direcciones IP utilizando el módulo de seguridad.

Figura 17: Módulo de Login Security para Drupal

Para ello, Drupal ofrece el módulo login security que, aparte de permitir o denegar (de manera temporal o permanente) el acceso por dirección IP a ciertas partes de Drupal, también permite limitar el número de intentos fallidos de autenticación antes de bloquear una cuenta de usuario, o avisar al administrador por correo electrónico o vía Nagios cuando se hayan adivinado cuentas o realizado realizado ataques de fuerza bruta. Por supuesto, no olvides poner un segundo factor de autenticación a todas las cuentas de tu Drupal por si alguien es capaz de conseguir la password de uno de esos usuarios.

Autor: Amador Aparicio de la Fuente (@amadapa) escritor de libro "Hacking Web Technologies"