ManageEngine Privilege Escalation | Critical Start
Prepare your business with On-Demand Breach Response
Webinar Series | Once More unto the Breach | Lessons Learned from Billion Dollar Breaches

ManageEngine Privilege Escalation


Background:
After running into ManageEngine products on a number of penetration tests, we decided to take a closer look at their products and see if there were any vulnerabilities that we could take advantage of.


CVE Numbers:
CVE-2019-12876


Versions Tested:
DesktopCentral – 10.0.380
ADSelfService Plus – 5.7
ADManager Plus – 6.6.5


DLL Hijacking:
Multiple ManageEngine products run as System on startup and have bad file permissions. The services keep their data in C:\ManageEngine by default and any user can write to these folders. This makes the applications vulnerable to DLL hijacking allowing low-level users to escalate their privileges.

Figure 1 – Permissions

 

In order to take advantage of this, we just need to generate a DLL and rename it to any DLL that the binary loads when it runs. In this case, we will show how to take advantage of DesktopCentral loading Secur32.dll

To start, we needed a custom DLL that would execute what we wanted in order to prove privilege escalation. We wrote a simple DLL with the code below, which will create the user pwned and then add that user to the local administrator’s group.

 

We then compiled it as a 32bit DLL, renamed it to Secur32.dll and put it into the bin folder, which any user has access too as shown below.

 

Figure 2 – Permissions

 

Once the DLL is in place, you can restart the service either manually with an Admin account or by rebooting the machine. Once the service is restarted, the DLL will be loaded by the service and our code will execute giving us a new Admin user on the system.

Figure 3 – DLL Called

 

Figure 4 – Admin User Created

 

Figure 5 – New Admin User

 

Vendor Response:
ManageEngine has patched the issue in their DesktopCentral product but states that the issue is a feature in their other offerings and will provide guidance around it for their customers.


Disclosure Timeline:
2019-03-20 – Vulnerability Disclosed to Vendor
2019-04-10 – Vulnerability acknowledged and fix in the works
2019-06-18 – Vendor responds saying they have fixed it in some products


Credit:
Chase Dardaman | Adversarial Engineer | TEAMARES, CRITICALSTART
Quentin Rhoads-Herrera | Offensive Security Manager | TEAMARES, CRITICALSTART

Let's Talk

Get in Touch
PREVIOUS RESOURCE
NEXT RESOURCE

Related Content

Categories