Privilege Escalation in Heimdal #1

This blog post highlights bugs found in installed software during customer engagements. Vulnerabilities will be published, when the vendor has provided fixes, or our deadline for the vendor to take action expires. This process is aligned with the Improsec Responsible Disclosure Policy.

The vulnerability was disclosed to Heimdal Security on 10 January 2018. The public disclosure date of 12 March, was agreed with Heimdal Security on 17 January and by 2 March we received confirmation, that all running product versions are patched.

In these blog posts I tend to be a bit verbose and give some insights into the process. Concrete exploitation steps and code is listed at the bottom.

CVE-ID:CVE-2018-5349

Heimdal ticket: 24652

During a laptop review for a customer, I zoomed in on the security product Heimdal. Process Explorer (Procexp) showed me multiple processes belonging to the application, so I decided to let Procmon monitor across a reboot with at filter of “Process starting with Heimdal” to get an idea of the loading process.

The fact that a process called “Heimdal.MonitorServices.exe” was started from a subdirectory of “ProgramData” instead of “Program Files” looked pretty strange.

Figure 1: Application running out of ProgramData.

Figure 1: Application running out of ProgramData.

I looked at the security of this directory, and though I could not modify existing files, I could create new files.

Figure 2: Users are allowed to write new files to the folder.

Figure 2: Users are allowed to write new files to the folder.

This vulnerability is a classic case of faulty permissions on a folder containing executables. A script like Powerup will usually hint at these issues, but in this case, you will need an administrator account to see it, as the task responsible for starting the application is not readable by an unprivileged user.

Going back to the Procmon output, I filtered on that process and NAME NOT FOUND, and sure enough, a DLL was attempted loaded from this directory, leaving the application open to DLL Search Order Hijacking.

Figure 3: The process looks in the writable folder when loading VERSION.dll.

Figure 3: The process looks in the writable folder when loading VERSION.dll.

Recommendations

  • Make sure you are running the latest version of the product.

TL;DR

Exploitation steps:

  • Create malicious DLL (see former blogposts for a simple example).

  • Copy the malicious dll to “C:ProgramDataHeimdal SecurityHeimdal Agentversion.dll”

  • Reboot