Cómo crear el Módulo Metasploit para el explotar el bug CVE-2013-5572 de Zabbix

El año pasado publicamos un CVE entre varios compañeros de la antigua Informática 64 que afectaba a Zabbix. La vulnerabilidad consistía en que se podía sacar la cuenta de dominio con la que Zabbix se conectaba al controlador de dominio, simplemente accediendo al recurso authentication.php. Claro, para ello primero debíamos estar autenticados de alguna manera para acceder a dicho recurso, aunque lo curioso es que Zabbix por defecto no tiene Https, por lo que es fácil capturar algún login - y usarlo si no tiene un Latch implementado - o una alguna cookie de sesión que vaya sin cifrar y montar un session hijacking.

Figura 1: Cómo crear el Módulo Metasploit para el explotar el bug CVE-2013-5572 de Zabbix

En CVE Details podemos ver la valoración, o el nivel de severidad, que se calculó sobre la vulnerabilidad. El valor final con CVSS es de 3.5, siendo una vulnerabilidad de severidad baja, debido a qué debemos estar autenticados de alguna manera.

Figura 2: Detalles del CVSS de CVE-2013-5572 en CVE Details

¿Qué es Zabbix? 

Zabbix es un software de monitorización para diversos parámetros de una red, como por ejemplo la integridad y salud de los servidores de una organización. Este software, desarrollado en modelo Open Source, tiene una parte dedicada a la integración con servidores LDAP, por lo que se puede utilizar un usuario de dominio para integrarlo en un Active Directory.

La versión que nosotros probamos, y era vulnerable, era la versión 2.0.5, pero como indicamos en Full Disclosure sospechábamos que podían existir más versiones vulnerables, sobretodo las anteriores a la 2.0.5. Existe más información del bug y de Zabbix en Seclists. Sobre esta información, vamos a construir un pequeño módulo para Metasploit que tener en el arsenal.

¿Cómo un pentester se puede aprovechar este bug Zabbix?

Existen diversas maneras por las que un pentester podría aprovecharse de este bug de Zabbix, como por ejemplo el no uso de una capa segura HTTPs por defecto. Cualquier técnica por la que se consiga colocar nuestro equipo en medio de una comunicación, haciendo un ataque de Man In The Middle, bastaría para lograr las credenciales o, en su defecto, una cookie. En algunas ocasiones también podemos encontrar situaciones extrañas en dispositivos de red, o comportamientos no deseados que puedan provocar que algunos switches se comporten como hubs por malas configuraciones de apilamiento. Sea como sea, y sobretodo hablando en una red interna, puede ser fácil conseguir un token que nos identifique ante Zabbix.

Figura 3: Clave de acceso al Active Directory en el código fuente de authentication.php

En este caso nos vamos a centrar en la cookie de sesión de Zabbix, indicando que solamente necesitaremos el valor de zbx_sessionid. Como se puede ver en la siguiente imagen, si disponemos de la cookie es trivial acceder al recurso authentication.php de Zabbix. Una vez allí, al visualizar el código fuente podremos obtener la contraseña del usuario de dominio con el que Zabbix se ha integrado.

El Módulo para Metasploit del CVE-2013-5572

Volviendo de una charla en Murcia en tren no había nada mejor que hacer que programar el módulo de esta vulnerabilidad. Es algo que tenía en mente mucho tiempo atrás, ya que al final es un CVE nuestro y siempre se le tiene cariño, aunque el CVSS sea un 3.5, y esté muy lejos del los valores que adquieren bugs como el de ShellShock o Heartbleed. Sobre las 19.00 de la tarde de un viernes, a dos horas de Madrid, comencé con el desarrollo del módulo con el objetivo de obtener las credenciales de la cuenta de dominio que utiliza un Zabbix, la dirección IP del host que tiene montado el servidor LDAP y el usuario de Zabbix del que se tiene la cookie de sesión.

Antes de ponerme a desarrollar monté un Zabbix y un Windows Server 2012 con un dominio de prueba. En la imagen siguiente superior se ve cómo se configura en Zabbix la integración en un árbol LDAP y cómo se ve en authentication.php los datos cuando la conexión a la consola de administración de Zabbix se ha hecho con un usuario normal.

Figura 4: Vista de authentication.php con una conexión de usuario

En esta otra imagen se puede ver cómo se visualiza authentication.php cuando en Zabbix se utiliza el usuario Administrador en la consola de administración. La recomendación, por supuesto, es utilizar un usuario sin demasiados privilegios, ya que al acceder a Zabbix se puede obtener la contraseña del usuario de dominio de manera sencilla, ya sea vía navegador, o con el módulo que se mostrará, pero para la demostración se ha elegido esa cuenta.

Figura 5: Vista de authentication.php con una conexión de administador

El módulo que hay que crear para explotar este fallo es de tipo auxiliary, ya que no se realiza una explotación con el fin de obtener el control de la máquina o ejecutar código en la víctima. Lo que conseguimos con este tipo de módulos son otras funcionalidades dentro de un proceso de pentesting que pueden ser interesantes en un momento dado. Para generar el módulo de Metasploit heredamos de la clase Msf::Auxiliary. Este tipo de módulos disponen de diversos atributos y métodos comunes, en el caso de los atributos nos encontramos con:

• RHOST: Host remoto sobre el que lanzaremos el módulo.
• RHOSTS: En el caso de los scanners se utilizará dicho atributo para especificar redes.
• RPORT: Puerto remoto sobre el que lanzaremos el módulo.
• PORTS. En el caso de scanners se especifica el rango de puertos sobre los que se escaneara.

Para el caso de los métodos, cuando desarrollamos un módulo de estas características tenemos lo siguiente:

• Initialize: Función que inicializa el módulo indicando información como la descripción, el autor, licencia, nuevos atributos del módulo, etcétera.
• Run: Esta función lanza el módulo ejecutando el código implementado.

Figura 6: Método initialize del módulo

La función initilize tiene una parte para registrar nuevas opciones o atributos. En este caso necesitamos algunos parámetros nuevos como son los siguientes:

• zbx_session: Este parámetro se debe configurar obligatoriamente y debe contener la cookie robada u obtenida. 

• TARGETURI: Este parámetro debe recibir el path dónde se encuentra la gestión de LDAP y usuarios. Por defecto en Zabbix es /zabbix/authentication.php, por ello en el módulo indicamos “[true, ‘Path Zabbix Authentication’, ‘/zabbix/authentication.php’]”. El primer valor indica que el atributo debe ser configurado de forma obligatoria, el segundo indica un texto descriptivo sobre la funcionalidad del parámetro, mientras que el tercero indica un valor por defecto, por lo que al cargar el módulo en Metasploit, el valor con el que aparecerá el atributo es el indicado. 

• TIMEOUT: Este parámetro indica el timeout configurado para realizar las peticiones HTTP.

Hay una línea que debemos tener en cuenta y es include Msf::Exploit::Remote::HttpClient. Con este include podemos utilizar las funciones de dicha clase, por ejemplo send_request_cgi de la cual hablamos más adelante.

Antes de hablar de la función run trataremos una serie de funciones que mostrarán por pantalla los valores buscados, los cuales son usuario y contraseña de dominio, usuario de Zabbix y dirección IP dónde se encuentra el LDAP.

Figura 7: Funciones de apoyo para el módulo

La función ldap_host recibe la respuesta de Zabbix, una vez que realizamos la petición y realizamos una búsqueda del patrón ldap_host value. Si esto se encuentra hemos encontrado el host al que se conecta Zabbix, y si esto ocurre es que estamos dentro de la sesión de usuario de Zabbix y podremos obtener más datos. Tanto la función user_passDomain como user_zabbix realizan una operativa similar, salvo que los patrones a buscar son diferentes. En el caso de la password del usuario de dominio se debe buscar ldap_bind_password.

La función run la he simplificado para que solo llame a una función que realiza peticiones utilizando la función send_request_cgi. La función req que se puede ver en la imagen, crea un paquete HTTP con las cabeceras host, method, uri, cookie o content-type. Una vez realizada la petición HTTP se almacena en la variable resp la respuesta, para posteriormente pasársela a las diferentes funciones creadas anteriormente. A continuación se explican los detalles a tener en cuenta:

• El header host se obtiene del RHOST configurado por el usuario en el módulo, para ello se utiliza la variable datastore[‘RHOST’].
• El header cookie se obtiene del atributo configurado por el usuario que denominamos zbx_session. Como se ve en la imagen ‘cookie’ => “zbx_sessionid=#{datastore[‘zbx_session’]}”.
• El timeout también debe obtenerse de datastore.

Figura 8: Función Run

Una prueba del módulo con la explotación del bug

Con el módulo ya creado vamos a probarlo con un Zabbix 2.0.5 montado en una máquina virtual y configurada correctamente, arrancamos Metasploit. Con el comando use accedemos al módulo que hemos generado y tras ejecutar show options y ver qué nos ofrece el módulo lo configuramos con la ejecución de dos comandos. Tenemos en cuenta que el atributo TARGETURI no lo configuramos porque el módulo nos proporciona la ruta por defecto de gestión con LDAP de Zabbix. Ejecutamos lo siguiente:

• set RHOST [IP Zabbix]
• set zbx_session [cookie obtenida]

Tras la ejecución podemos ver cómo, si todo va bien, obtenemos la dirección IP dónde se encuentra el Active Directory, en este caso la dirección IP 192.168.56.103. Zabbix se encuentra en la dirección IP 192.168.56.102. También obtenemos una línea que dice User Domain? Indicando que es un usuario de dominio. Lo mismo ocurre para la contraseña y para el usuario de Zabbix. Tenemos que tener en cuenta que el usuario de dominio que obtenemos puede ser más crítico de lo que a priori podríamos pensar, ya que en muchas ocasiones podemos encontrarnos con qué dicho usuario tiene ciertos privilegios, o todos si es el Administrador de Dominio.

Figura 9: Ejecución del módulo de Metasploit para el CVE-2014-5572 para Zabbix

Una manera sencilla de comprobar los privilegios sería utilizar el módulo exploit/windows/smb/psexec del propio Metasploit, el cual permite realizar pass the hash o autenticación con usuario y contraseña a través de SMB. Si quieres probarlo tú mismo, el módulo implementado en este artículo puede ser descargado desde Github: Módulo Metaploit CVE-2013-5572 para Zabbix. El software de Zabbix puede ser descargado desde su sitio web. Se guarda un histórico de versiones, por lo que si queréis probar versiones anteriores se puede.

Tenemos que tener en cuenta que un pequeño fallo en la configuración de un dispositivo de red, un ataque en una red local contra usuarios de Zabbix, un ataque dirigido al administrador de Zabbix puede desembocar en algo más “gordo” debido a pequeños fallos en el software. Estas pequeñas debilidad con un CVSS bajo, recordemos que solo tiene un valor de 3.5, pueden desembocar en una escalada de privilegios en un dominio de la organización pudiendo llegar incluso a ser administrador de dominio. Las pequeñas debilidades las cuales nadie tiene en cuenta pueden convertirse en un gran agujero por el que pwnear.

Si quieres crearte tus propios módulos o sacarle más provecho a Metasploit, además de leer este libro de Metaspoloit para Pentesters, puedes leer estos otros artículos con diversos ejemplos con diversas utilidades:

- Crear tu módulo de Metasploit para ShellShock
- Retromalware: Detecta y Controla NetBus con Metasploit
- Robar WhatsApp de Android con Meterpreter de Metasploit

Además, si vienes al Cybercamp este fin de semana te puedes inscribir en el Taller de Metasploit que daré.

Autor: Pablo González Pérez (@PabloGonzalezPe)
Escritor de los libros Metasploit para Pentesteres y Ethical Hacking