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.

61dcfcd89c4066e602464887 figure 1
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.

61dcfcd8edd291365719941e code

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.

61dcfcd82c873c5553e15df9 figure 2 3
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.

61dcfcd8f3f1a897ad928292 figure 3
Figure 3 – DLL Called
61dcfcd8f0eb77677b65b0f3 figure 4 2
Figure 4 – Admin User Created
61dcfcd88480a1a24bfccaa3 figure 5
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.

61dcfcd80ec42008420dada8 figure 6


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 | Offensive Security

Quentin Rhoads-Herrera | Offensive Security Manager | Offensive Security