ManageEngine deep exploitation

During a recent pure black-box pentesting for a client, we found several products from ManageEngine Editor which were accessible without any restriction over the internet. Vulnerabilities exploited and found were interesting, showing how dangerous publishing this kind of product could be.

The first one we found is ServiceDesk Plus, a common IT help desk Software.

Local File Inclusion (LFI) CVE-2017-11511 Exploit and bonus

Of course, and like any good pentester, the first reflex is to check which version of the product is deployed and if any vulnerabilities have been already published.

Getting version of the product is easy and can be retrieve by reading html source code (and sometimes even a red warning told you that your version is outdated). Luckily for us, the version presented was an old one and many exploit codes are even public. This one looks very promising:

An unauthenticated Local File Inclusion allows us to get any file we want from the server hosting the application (limited of course to the ISS service rights running the ServiceDesk Plus process).
Example of exploitation by grabbing win.ini file from the server:



You can quickly understand how bad this is, especially when your application is reachable without any filtering. That’s why we immediately contact our client to warn him of our funding. But, and it is rare enough to underline it, our client gave us extra time to go further and see what we can do with these exploitation: challenge accepted.

LFI is always a very interesting vulnerably for a pentester. Grabbing any files from a server could very quickly leads to privilege escalations or pivoting. The only constraint is to find interesting filenames and locations, and when your LFI do not allow directory listing, guessing is not always so easy (even all your training during bizarre CTF Challenges 😉).

All common Windows and IIS files gave us nothing interesting. Let’s take a look at the application itself : a « community » version of the product is available to download for free :

Installing the application on our labs gave us many precious information including the fact that product is using by default a PostgreSQL database: let’s try to dump it from our LFI.

Once installed, the location of this database is easy to find, and as hardly all PostegreSQL configuration, database is splited in many files and directories:


Getting all these files from the LFI could be done by a bruteforce attack (only few changes in filenames and directories are made from one instance to another). But imagine how long it would be, and no doubt we will miss one or two files leading to a reconstruction fail.

By looking through different services, we found out that the application scheduled full database backup in a single archive and save it in a folder and a filename that could be predicted:



  • 05_05_2018_12_30: is the date and the hour of the backup;
  • 1: is an incremental number;
  • 9406: is an ID rarely changing;
  • Rest of the path is invariable.

Once again, date and ID could be found using a bruteforce attack, but we had no time to do that. Simple grep through all files allows us to find out that the backup is logged in the file C:\ManageEngine\ServiceDesk\bin\SDPbackup.log (which do not change from an instance to another). This log file contains the path we are looking for:


Now we just have to get the log file from the client instance, grab the path from the last backup in the logfile and the full database is now ours:


This database is a goldmine:

  • Hash (bcrypt) of all users of the platform;
  • Critical information on the client’s employees (phone number, mail or postal addresses);
  • Content of all tickets opened on the platform (containing of course clear-text passwords, admin URL, information on migration, information on employees etc);
  • Licence key, Client’s Active Directory configurations;
  • Etc.

From that, we were able to evaluate the real impact of the vulnerability. We of course warn the client and advise him to check if this vulnerability has not been already exploited on his instance. But this small example shows you how a very simple LFI could lead to a potential massive leak of critical information on your company and your employee (not really GDPR compliant).

Moreover, for these vulnerability, a patch was available. Once again, patch management must consider not only system patches but also all legacy or open source applications, especially of course when they are exposed over the Internet.

After that, the client patched immediately his Service Desk instance, but also all instances published over the internet. Let’s now find some 0 Day now.

From misconfiguration to domain admin on Central Desktop

In fact, our client also used another product of ManageEngine, Desktop Central, just take a quick look on their website:


"Put an end to endless cyberattacks", that seems very promising. The product aims to provide a sort of extended MDM solution, which allows you to manage all your devices (servers, laptops, desktops, smartphones, and tablets) and automate some « regular desktop management routine » like patch installation, software distributions and so on.

By just reading the small description on their website, you can quickly realise that the product will probably deal with some very critical information regarding many part of the concern network (probably AD passwords, information on devices, users, servers, laptops and so on), in a few words: a goldmine for a Hacker.

The list of CVE already published ( let us think that a quick look will worth it.

Once again, a community version is available. By default, the product listens with an Apache server on port 8020. Analysing configuration files shows that an alias to the logs directory is by default configured but restricted from localhost:


Probably for debugging purpose but why not. Port 8443, 8444 and 8022 are also by default opened, but these ones are directly served by a Tomcat service:


No doubt access to “logs” directory will be also configured, let’s look:


Bingo. And oh, nice, this time, no restriction on Source IP, which means if these ports are exposed on the Internet, we are able to access all log file of the solution just by requesting it. All you need to know are logfiles’ filenames, which of course could be retrieve from the downloadable community version (filenames do not change from an instance to another), as example:


By reading the documentation of the product, it seems that these ports are needed for the product to work correctly:


A simple google dork shows us many potential vulnerable instances:


Fun fact, Manage Engine kindly inform us when the appliance is vulnerable:


Okay, now we know that logs are accessible from everywhere, let’s observe what we can get from that. There are many logfiles accessible:


Opening them give us way more than we expected. Quick overview of information that we were able to get:

  • Devices’ enrolment log which include UUID, serial numbers, mail addresses of enrolled devices, but also auth_session_token which, we think, could be used to spoof enrolled devices and potentially access internal assets.
  • Clear text password of recover password of Android devices
  • Clear Text Password Username and mail of EAS account in (it is often an AD account used to send mail, for our client, Exchange Administration account 😉);
  • Clear text password of recovery_password of Android devices;
  • Clear text password of account "set" (it seems to be a bug but could be great to delete it);
  • Location of devices enrolled in the platform with UUID and information that easily allow to find out the name of the person concern by the location. Quite critical, you can track each employee of a company without any authentication, hello from Germany 😉:


  • And, the last but not least, we found out that base64 encoded Domain admin passwords are also leaked in some log files:


The amount of critical data that could be retrieve from a simple misconfiguration is scary. From a single web interface exposed over the internet, we were able to get Domain Admin account and password and use it for example on exposed VPN or OWA interfaces. The impact for the company is huge.

This two 0 Days (Unauthorized access to all logs files in Desktop Central and Sensitive and critical data in logs files) have been reported through their bug bounty platform and fully patched in version 10.0.254 (teams were quite reactive), advisory has been made and CVE were published.


  • 16/04/2018: Vulnerabilities discovered and POC available
  • 17/04/2018: Vulnerabilities reported through BugBounty plateform
  • 17/04/2018: Acknowledgement from Zohoo security team
  • 03/05/2018: First patch (100230), fix unauthorized access to log files
  • 04/06/2018: CVE reservation (CVE-2018-11716, CVE-2018-11717)
  • 19/06/2018: Second patch (100251), fix sensitive information in log files
  • 20/06/2018: Public announcement from ManageEngine (
  • 12/07/2018: Reference and CVE Filled.