ManageEngine User Enumeration | Critical Start
Learn real world attack and defense strategies with Adversarial Emulation and Active Defense training from TEAMARES
TEAMARES launches Breach Attack as a Service for quick testing whenever your environment changes.
Webinar Series | Once More unto the Breach | Lessons Learned from Billion Dollar Breaches

ManageEngine User Enumeration


Background:
While conducting a penetration test of a client’s external network, I discovered a way to enumerate users’ in ManageEngine’s ADSelfService Plus application. This allows an attacker to determine the system Admin username.

Product: ManageEngine ADSelfService Plus

Software Version: 5.7, build 5704

Issue:
The login page is vulnerable to account enumeration.

The admin login page is accessed through the web UI at the following URI:

  • http://<HOST>/adminLogin.cc
  • http://<HOST>/authorization.do
  • http://<HOST>/j_security_check
Figure 1 – Screenshot of adminLogin.cc


Proof of Concept:
Attempt to login with an account that doesn’t exist, and you receive a unique error message.

Figure 2 – Screenshot of an attempted login with an incorrect username

If you then attempt to login to an account that does exist, then you will not receive the “No such user account configured”.

Figure 3 – Screenshot of an attempted login of an existing account

In order to prove this, I have written a POC script that you can find here that automates the enumeration based on a list of users.

Vendor Response:
After reaching out to the vendor they decided that this was not an issue and responded with the following statement:

“We’ve investigated this report. The mentioned ‘adminLogin.cc’ request is protected with the Threshold. So, user enumeration is not easy to perform. Additionally, these messages could be customized in the customer environment. Hence, closing this report as N/A.”

The ”Threshold” that they are alluding to is that by default, the application will show a CAPTCHA after 3 invalid login attempts in order to slow brute forcing down, but this does not remedy the concern with disclosing which accounts exist.

Figure 4 – CAPTCHA settings

 

Disclosure Timeline:
2019-02-18 – Vulnerability Disclosed to Vendor
2019-02-18 – Vendor Replied and Started Investigating
2019-03-20 – Vendor Closed as Non-Issue

 

by Chase Dardaman | TEAMARES, CRITICALSTART
March 26, 2019

Let's Talk

Get in Touch
PREVIOUS RESOURCE
Path 11 Copy 2 Created with Sketch.

Related Content

Categories