Red Team Tales 0x02: from SQLi to Domain Admin

//Red Team Tales 0x02: from SQLi to Domain Admin

Red Team Tales 0x02: from SQLi to Domain Admin

Una de las actividades incluidas en la operativa del 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/[email protected]) 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 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 auditorías de vulnerabilidades.

By |2018-11-02T13:41:14+00:002 Nov. 2018|0 Comments

Deja un comentario