TIMELINE:
October 7, 2019: We reported the vulnerability to Pronestor
October 7, 2019: Immediate dialogue with Pronestor
October 10, 2019: Pronestor confirmed our finding and worked on a fix
October 29, 2019: Pronestor had a new version ready for internal testing
November 27, 2019: New version released and presented in Pronestors release notes (PNB-2359)
January 23, 2020: Public disclosure
CVE’S REGISTERED:
CVE: CVE-2019-17390
BACKGROUND:
A customer asked us to check the security level of their standard Windows 10 client.
Among other vulnerabilities and misconfigurations, we found the following critical vulnerability in Pronestor HealthMonitor (part of the “Outlook add-in for Pronestor” product) and agreed with the customer in question, that we (Improsec) should handle this under our normal Responsible Disclosure policy and process.
DESCRIPTION:
A local user, without any kind of administrative permission on the Windows client, can execute code in ”NT Authority\SYSTEM” context by replacing a single file on disk.
This local privilege escalation (LPE) vulnerability is caused by incorrect Access Control of the Pronestor HealthMonitor (PNHM) service binary, version 6.0.42 and earlier (fixed in version 8.1.77).
ATTACK VECTOR AND EXPLOITATION STEPS:
A regular user can replace a binary file and restart the service (or client computer).
This vulnerability can easily be exploited by a malicious user or automated by malware.
Replace the binary file in question, e.g. with a malicious binary
Restart the machine or await PNHM service restart
WALK-THROUGH:
The Pronestor HealthMonitor (PNHM) runs as local SYSTEM:
Full path to the binary file: "C:\Program Files\proNestor\Outlook add-in for Pronestor\PronestorHealthMonitor.NET40.exe".
NTFS permissions on the parent folder where the binary files are placed explicitly allow “Full Control” for local users:
Rename the real Pronestor binary file and replace with another (while the service is running):
As regular users do not have permissions to start/stop the particular service, an attacker will have to wait for service restart in some other manner. Most of you can just restart the machine or force another triggering mechanism, e.g. Social Engineering of help desk personnel during a ”troubleshooting” call.
Researcher: Jakob H. Heidelberg, Improsec A/S