Red Team Tales 0x02: De SQLi a Domain Admin
Tabla de contenidos
Una de las actividades incluidas en la operativa del servicio de Red Team de Tarlogic es la búsqueda de vulnerabilidades en el software utilizado por nuestros clientes. En ocasiones esta actividad conlleva al descubrimiento de 0-days como hemos comprobado en artículos publicados anteriormente en el blog (OCS Inventory, Cobian Backup, OpenText TempoBox…). En otros casos, la vulnerabilidad es conocida y de dominio público por lo que solo es necesario hacer efectiva su explotación.
En este artículo se hablará de un ejercicio donde se ha explotado una vulnerabilidad ya conocida (es decir, con CVE asignado) pero de la que sin embargo no hay detalles públicos de su explotación. Se describirá el proceso de ingeniería inversa que se ha seguido hasta conseguir un exploit funcional. Como resultado final, la explotación de esta vulnerabilidad derivó en la obtención de credenciales de administrador del dominio, como se verá al final del artículo.
0x01 – Preámbulo
Realizando un exhaustivo escaneo de los distintos bloques de direcciones IP pertenecientes a un cliente se descubre un servicio web expuesto que se corresponde con el aplicativo ManageEngine Applications Manager. Esta aplicación permite la administración y monitorización de la infraestructura IT, lo que la convierte en un activo crítico y por tanto objetivo prioritario para el Red Team.
Portal de login de la aplicación Applications Manager
Haciendo una búsqueda trivial con la versión del aplicativo (12900), se comprueba que existen una serie de vulnerabilidades reportadas en abril de 2017. Entre estas, destaca una inyección SQL (CVE-2016-9488) muy interesante dentro del ejercicio de Red Team por su criticidad ya que no requiere de autenticación. No obstante, los detalles de los parámetros vulnerables así como de su explotación en ese momento no son de dominio público, conociéndose únicamente el componente del aplicativo que es vulnerable (/servlet/MenuHandlerServlet).
## SQL Injection (CVE-2016-9488)
An unauthenticated user is able to access the URL /servlet/MenuHandlerServlet, which is vulnerable to SQL injection. Note that among others, an attacker is able to extract users’ password hashes, which are MD5 hashes without salt. Depending on used database type and its configuration, an adversary can also execute operating system commands using SQL queries.
0x02 – Identificando la inyección SQL
Ante la ausencia de información, el Red Team procede a analizar la aplicación mediante ingeniería inversa, con objeto de identificar el parámetro vulnerable y descubrir cómo explotarlo. Para ello se utiliza la demo que el propio fabricante ofrece en su web, que pese a ser la última versión y no ser vulnerable, permite explorar los parámetros que recibe el componente afectado.
Para localizar el punto de inyección, se descomprime el fichero .jar que contiene la clase MenuHandlerServlet (nombre del recurso vulnerable). Esta clase es decompilada, en este caso utilizando la utilidad jad, para hallar los parámetros HTTP existentes realizando una búsqueda por el método ServletRequest.getParameter().
Búsqueda de los parámetros HTTP en la clase MenuHandlerServlet
Tras realizar diversas pruebas a los distintos parámetros localizados, se identifica que el parámetro config_id es el afectado por la inyección SQL, tal y como se muestra a continuación.
Consulta SQL verdadera que devuelve resultados
Consulta SQL falsa que no devuelve ningún resultado
0x03 – Extracción de datos
Una vez confirmado el parámetro vulnerable y aprovechando que se dispone de la versión demo de la aplicación, se realiza un análisis de la estructura de la base de datos (PostgreSQL) para facilitar la extracción de los mismos. El objetivo en este punto es obtener credenciales de administración que permitan acceder a la plataforma.
De este modo, se localiza en primer lugar la tabla am_userpasswordtable, de la cual se obtiene la lista de usuarios de la aplicación (más de 120 usuarios en este caso) junto a las contraseñas hasheadas en MD5 sin salt.
Petición POST para la extracción de usuario y hash de la tabla am_userpasswordtable
En paralelo al proceso de crackeo de los hashes, de la tabla credentialdetails se obtienen las credenciales (muchas de ellas del dominio) utilizadas por la aplicación para monitorizar los diferentes servicios (Servidores Tomcat, Apache, bases de datos…).
Petición POST para la extracción de credenciales de la tabla credentialdetails
En este caso las contraseñas se encuentran codificadas con un algoritmo propio que impide su lectura directa en texto claro. No obstante, se comprueba que existe una función dentro de la aplicación que realiza la decodificación (convertFromBase(String paramString)), la cual es aprovechada para obtener las credenciales en claro.
Método utilizado por la aplicación para la decodificación de contraseñas
Aunque se tratan de credenciales de valor que pueden ser utilizadas en fases posteriores del ejercicio, ninguna de ellas nos permite acceder a la aplicación.
0x04 – Acceso final a la aplicación
Durante este proceso de ingeniería inversa y antes de que el proceso de cracking de hashes tuviera resultados satisfactorios, se descubre que la cuenta de administración por defecto especificada por el fabricante (admin/admin), con la que inicialmente se intentó acceder al panel, puede tomar un valor distinto en caso de que la propia aplicación se encuentre integrada con otro de sus productos (OpManager).
Porción de código donde comprueba la integración para asignar la contraseña por defecto
Se comprueba efectivamente que estas credenciales (admin/admin@opm) son válidas, y por tanto que ambas aplicaciones se encuentran integradas. Haciendo uso de este hallazgo, finalmente se consigue acceso al aplicativo con permisos de administración.
0x05 – Obtención de credenciales de administrador del dominio
Una vez dentro de la aplicación, se comprueba que existe un componente (Actions) dentro del panel de administración que permite ejecutar comandos tanto local como remotamente. Aunque este componente no devuelve la salida de los comandos ejecutados, es posible volcar la salida a un fichero y utilizar el visor de logs de la propia aplicación. Se identifica que los comandos son ejecutados como NT AUTHORITY\SYSTEM.
Ejecución del comando ipconfig en el servidor
Por otro lado, el panel de administración permite subir ficheros al servidor. Esta funcionalidad es utilizada para alojar en el servidor (Windows) la utilidad ProcDump de sysinternals. Dicha utilidad es usada para el volcado de la memoria del proceso LSASS a un fichero, posible debido a la inexistencia de una restricción de seguridad para el acceso a memoria.
procdump.exe -accepteula -ma lsass.exe out
Este fichero es exfiltrado a una máquina local del Red Team para posteriormente extraer las contraseñas en claro de los usuarios del dominio, obteniéndose de esta forma acceso a una cuenta de administrador del dominio.
0x06 – Conclusiones
Se ha comprobado cómo una vulnerabilidad en una aplicación web insegura expuesta a Internet puede conducir al compromiso total de la infraestructura de la empresa. Por este motivo, es importante plantearse la necesidad de evitar exponer plataformas críticas como la mostrada en este artículo.
En caso de que sea necesario, se debe plantear un proceso de control de actualizaciones del aplicativo, de implementación de defensas perimetrales y de bastionado del servidor, así como la realización periódica de tests de intrusión.
Descubre nuestro trabajo y nuestros servicios de ciberseguridad en www.tarlogic.com/es/
En TarlogicTeo y en TarlogicMadrid.