Red Team Tales 0x02: from SQLi to Domain Admin

One of the activities included in the operation of the Tarlogic Red Team is the search for vulnerabilities in the software used by our clients. Sometimes this activity involves the discovery of 0-days as we have verified in articles previously published in the blog (OCS Inventory, Cobian Backup, OpenText TempoBox…). In other cases, the vulnerability is well known and public so it is only necessary to make effective its exploitation.

In this article we will talk about an exercise where a well-known vulnerability (with CVE assigned) has been exploited, but for which however there are no public details of its exploitation. The reverse engineering process followed to achieve a functional exploit will be described. As a final result, the exploitation of this vulnerability led to the obtaining of domain administrator credentials, as will be seen at the end of the article.

0x01 – Preamble

An exhaustive scan of the different blocks of IP addresses belonging to a client reveals an exposed web service that corresponds to the ManageEngine Applications Manager application. This application allows the administration and monitoring of the IT infrastructure, which makes it a critical asset and therefore a priority objective for the Red Team.

Doing a trivial search with the version of the application (12900), it is verified that there are a series of vulnerabilities reported in April 2017. Among these, a SQL injection (CVE-2016-9488) stands out, which is very interesting within the Red Team exercise because of its criticality since it does not require authentication. However, the details of the vulnerable parameters as well as their exploitation at that time are not public, knowing only the component of the application that is 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 – Identifying SQL Injection

In the absence of information, the Red Team proceeds to analyze the application through reverse engineering, in order to identify the vulnerable parameter and discover how to exploit it. This is achieved using the demo that the manufacturer offers on its website, which despite being the latest version and not being vulnerable, allows exploring the parameters received by the affected component.

In order to locate the injection point, the .jar file containing the MenuHandlerServlet class (name of the vulnerable resource) is decompressed. This class is decompiled, in this case using the jad utility, to find the existing HTTP parameters by searching the ServletRequest.getParameter() method.

After performing several tests to the different HTTP parameters located, it is identified that the config_id parameter is the one affected by SQL injection, as shown below.

0x03 – Data extraction

Once the vulnerable parameter is confirmed and taking advantage of the demo version installed, an analysis of the database structure (PostgreSQL) is carried out to facilitate the extraction of the data. The objective at this point is to obtain administration credentials that bring access to the platform.

In this way, the am_userpasswordtable table is firstly located, from which the list of users of the application is obtained (more than 120 users in this case) together with the passwords hashed in MD5 without salt.

Parallel to the hashes cracking process, the credentials (many of them from the domain) used by the application to monitor the different services (Tomcat Servers, Apache, databases…) are obtained from the credentialdetails table.

In this case, the passwords are encoded with a proprietary algorithm that prevents their direct reading in plain text. However, it is verified that there is a function inside the application that performs the decoding (convertFromBase(String paramString)), which is used to obtain the plaintext credentials.

Although these are valuable credentials that can be used in later phases of the exercise, none of them allowed us to access the application.

0x04 – Final access to the application

During this reverse engineering process and before the hashes cracking process obtained satisfactory results, it is discovered that the default administration account specified by the manufacturer (admin/admin), initially tried to access the panel, can take a different value if the application is integrated with another of their products (OpManager).

It is effectively verified that these credentials (admin/admin@opm) are valid, and therefore that both applications are integrated. Making use of this finding, access to the application is finally obtained with administrative role.

0x05 – Obtaining domain administrator credentials

Once inside the application, it is verified that there is a component (Actions) inside the administration panel that allows to execute commands both locally and remotely. Although this component does not return the output of the executed commands, it is possible to dump the output to a file and then use the log viewer of the application to read it. It is identified that the commands are executed as NT AUTHORITYSYSTEM.

On the other hand, the administration panel allows to upload files to the server. This functionality is used to host on the server (Windows) the sysinternals ProcDump utility. This tool is used to dump the memory of the LSASS process to a file, made possible due to the absence of a security restriction for access to memory.

procdump.exe -accepteula -ma lsass.exe out

This file is exfiltered to a Red Team local machine to later extract the user passwords in plaintext, obtaining this way access to an account of a domain administrator.

0x06 – Conclusions

It has been proven how a vulnerability in a web applications exposed to the Internet can lead to the total commitment of the company’s infrastructure. For this reason, it is important to consider the need to avoid exposing critical platforms, such as the one shown in this article.

If necessary, an application updates procedure, implementation of perimeter defenses and server bastioning, as well as periodic penetration tests  and web security audits should be considered.

Discover our work and cybersecurity services at www.tarlogic.com