En el año 2013 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, 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 un login o una cookie. Por lo general, es más sencillo capturar la sesión de un usuario que accede a Zabbix, ya que hay mayor probabilidad de que realice una petición a la aplicación.
En CVE Details podemos ver la valoración o el score de severidad que se calculó sobre la vulnerabilidad. El valor final o CVSS es de 3.5, siendo una vulnerabilidad de severidad baja, debido a qué debemos estar autenticados de alguna manera.
Vale, pero ¿Qué es 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 Open Source tiene una parte dedicada a la integración con LDAP, por lo que se puede utilizar un usuario de dominio para integrarlo en directorio activo. La versión que nosotros probamos y era vulnerable era la versión 2.0.5, pero como indicamos en Seclists 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.
¿Cómo puedo aprovecharme de Zabbix?
Existen diversas maneras por las que un pentester podría aprovecharse de Zabbix, como por ejemplo el no uso de capa segura por defecto, cualquier técnica por la que se consiga colocar nuestro equipo en medio de una comunicación, 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. Sea como sea, y sobretodo hablando en una red interna, puede ser fácil conseguir un elemento que nos identifique ante Zabbix.
En este caso nos vamos a centrar en la cookie 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 y al visualizar el código fuente podremos obtener la contraseña del usuario de dominio con el que Zabbix se ha integrado.
Módulo para Metasploit
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. 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 LDAP y el usuario de Zabbix del que se tiene la cookie.
Antes de ponerme a desarrollar monté un Zabbix y un Windows Server 2012 con un dominio de prueba. En la siguiente imagen se puede ver como se configura Zabbix con el LDAP. En la imagen de la izquierda se ve la conexión con un usuario normal, y en la imagen de la derecha como Zabbix utiliza el usuario Administrador del dominio para realizar la autenticación. La recomendación 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á.
El módulo 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 máquina. Lo que conseguimos con este tipo de módulos son otras funcionalidades dentro de un pentesting que pueden ser interesantes en un momento dado. Para generar el módulo 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:
Para el caso de los métodos, cuando desarrollamos un módulo de estas características tenemos lo siguiente:
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:
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.
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:
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:
Tras la ejecución podemos ver cómo, si todo va bien, obtenemos la dirección IP dónde se encuentra el directorio activo, 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.
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. El módulo implementado en este artículo puede ser descargado desde mi github, mientras que 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 el 3.5, pueden desembocar en una escalada de privilegio 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.
En CVE Details podemos ver la valoración o el score de severidad que se calculó sobre la vulnerabilidad. El valor final o CVSS es de 3.5, siendo una vulnerabilidad de severidad baja, debido a qué debemos estar autenticados de alguna manera.
Vale, pero ¿Qué es 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 Open Source tiene una parte dedicada a la integración con LDAP, por lo que se puede utilizar un usuario de dominio para integrarlo en directorio activo. La versión que nosotros probamos y era vulnerable era la versión 2.0.5, pero como indicamos en Seclists 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.
¿Cómo puedo aprovecharme de Zabbix?
Existen diversas maneras por las que un pentester podría aprovecharse de Zabbix, como por ejemplo el no uso de capa segura por defecto, cualquier técnica por la que se consiga colocar nuestro equipo en medio de una comunicación, 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. Sea como sea, y sobretodo hablando en una red interna, puede ser fácil conseguir un elemento que nos identifique ante Zabbix.
En este caso nos vamos a centrar en la cookie 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 y al visualizar el código fuente podremos obtener la contraseña del usuario de dominio con el que Zabbix se ha integrado.
Módulo para Metasploit
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. 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 LDAP y el usuario de Zabbix del que se tiene la cookie.
Antes de ponerme a desarrollar monté un Zabbix y un Windows Server 2012 con un dominio de prueba. En la siguiente imagen se puede ver como se configura Zabbix con el LDAP. En la imagen de la izquierda se ve la conexión con un usuario normal, y en la imagen de la derecha como Zabbix utiliza el usuario Administrador del dominio para realizar la autenticación. La recomendación 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á.
El módulo 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 máquina. Lo que conseguimos con este tipo de módulos son otras funcionalidades dentro de un pentesting que pueden ser interesantes en un momento dado. Para generar el módulo 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.
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.
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.
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.
- 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 directorio activo, 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.
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. El módulo implementado en este artículo puede ser descargado desde mi github, mientras que 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 el 3.5, pueden desembocar en una escalada de privilegio 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.
No hay comentarios:
Publicar un comentario