One of the many ways to install third-party applications on workstations and servers in corporate environments is to push MSI-installation packages using GPO’s. However, the use of MSI-packages can, if not created securely, leave systems vulnerable to various privilege escalation vulnerabilities. Even Microsoft’s own MSI-parser, MSIEXEC, can in certain situation leave a Windows system vulnerable to privilege escalation.
This blog post details how I found a vulnerability in Windows 7/8.1/10/Server 2008/2012/2016/2019, which affected a range of different third-party products. I have furthermore documented a privilege escalation vulnerability in Netop Remote Control unrelated to the Windows vulnerability.
CVE
CVE-2021-1661 – Privilege Escalation in Microsoft Windows 7/8.1/10, Windows Server 2008/2012/2016/2019
CVE-2020-(Awaiting assignment) – Privilege Escalation in Intel Computing Improvement Program 2.4.05982
CVE-2020-(Awaiting assignment) – Privilege Escalation in Netop Remote Control 12.83.20175
Timeline
Microsoft:
o 02/10/20 – Microsoft Security Response Center e-mailed with detailed description of vulnerability
o 09/10/20 – MSRC confirms vulnerability and will perform further investigation into the issue
o 21/10/20 – MSRC officially confirms vulnerability for case 61370, severity “Important”.
o 12/01/21 – Microsoft releases patch for vulnerability.
Intel
o 22/10/20 – Intel Product Security Incident Response Team e-mailed with detailed description of vulnerability
o 22/10/20 – Intel PSIRT confirms receiving report. Investigates issue.
o 04/12/20 – Intel PSIRT e-mailed about update
o 04/12/20 – Intel PSIRT confirms vulnerability, time of mitigation fix unknown.
Netop Remote Control
o 22/10/20 – Netop e-mailed contacted.
o 23/10/20 – Netop e-mailed with detailed description about vulnerability.
o 15/12/20 – Netop informed that a patch was to be released in next release.
o 13/01/21 – Netop forwarded a patched version for testing to Improsec.
o 18/01/21 – Improsec confirmed that vulnerability was no longer present in Netop Remote Control version 12.83.21006.
o 28/01/21 – Netop releases Netop Remote Control version 12.83.20274
MSIEXEC repair description
First a short introduction to the MSIEXEC repair function:
During installation of MSI-packages, a copy of the MSI-package will be placed in the protected and hidden directory “C:\Windows\Installer” with a short auto-generated filename. Any user on the system can (in most cases) trigger a reinstallation of the package by calling “msiexec /fa c:\Windows\Installer\[name of file].msi” or by calling the related API/COM functions directly. Depending on the package, a typical reinstallation will spawn a new MSIEXEC process in user context of “NT Authority/SYSTEM” that will perform various file and registry operations and will in some cases execute various applications.
Privilege escalation vulnerability in Windows 7/8.1/10/Server:
During a server assessment and hardening analysis on a Windows Server for a customer, I was looking for ways to perform privilege escalation by reinstalling MSI-packages. This section of the blogpost details a vulnerability I found that affected Windows MSIEXEC which left multiple third-party products vulnerable.
While triggering a reinstallation of a installed third-party application I noticed that “cmd.exe” was called (in the user context of “NT Authority/SYSTEM”) during the reinstallation. During the execution I also noticed that the environment variables belonging to the low privilege user was applied to the process running as “NT Authority/SYSTEM”.
This inspired me to try if a modification of user environment variables would affect the executed process, namely the variable “ComSpec” which by default is set to “C:\Windows\System32\cmd.exe”.
In the tested case the variable was reused, and a user specified application was executed in the user context of “NT Authority/SYSTEM”.
During testing, I found a range of different third-party products that were affected by the vulnerability. These ranged from SIEM-agents, remote desktop applications, drivers for hardware, UI utilities, games, RMM-applications and more.
I have illustrated the vulnerability using the above method against Intel Computing Improvement Program v2.4.05982 (in which I previously found another privilege escalation vulnerability as documented previously on this blog), which is installed during the installation of Intel Driver & Support Assistant.
First, I needed to locate the right MSI-package in “C:\Windows\Installer”.
Next up I configured the “ComSpec” variable to “C:\Windows\System32\calc.exe” or any other application I wanted to execute in the user context of “NT Authority/SYSTEM”. Then I simply called MSIEXEC’s repair function pointing at the specific MSI-package.
During the repair process “calc.exe” is executed in the user context of “NT AUTHORITY/SYSTEM”, in this case called by the Intel service application “SurSvc.exe” which is called by an elevated MSIEXEC.
Checking the “calc.exe” application’s loaded environment variables shows that our user configured “ComSpec” is executed as “NT Authority/SYSTEM” with no low privilege user impersonation.
During research, I found multiple environment variables that could be passed on to high privilege processes and affected this in some way. However, “ComSpec” was the most effective for privilege escalation. However, multiple factors needs to present in order to perform a successfully privilege escalation:
The MSI-package needs to execute “cmd.exe” at some point using the “ComSpec” variable (presumed)
If the Windows Installer service is already running, the method will not work. The service will run if Windows or other users have used MSI. A reboot or service stop will enable the method again. Often MSIEXEC will terminate after a few minutes of idle.
Other unknown factors can prevent the method.
Privilege escalation in Netop Remote Control
The patching of the above described Windows vulnerability does not mitigate all vulnerable MSI-packages. Doing our daily research, penetration tests and assessments, we occasionally see MSI-packages which perform insecure file operations in low privilege users home directory, the “ProgramData” directory or the Windows temp directory. The vulnerability below is just one example of this.
During an assume breach penetration test using a customer’s workstation, I found that triggering the MSIEXEC repair of the remote management and helpdesk application Netop Remote Controls MSI-package, would result in the execution of various temporary executables from the low privilege user’s AppData directory structure.
The executables would during the repair process be placed in a subdirectory to the executing low privilege user’s “AppData\Local\Temp\Danware Data\Install\” directory. As the executing low privilege user had full control of this directory, a privilege escalation to “NT Authority/SYSTEM” could be performed using a simple race condition attack.
The timeline of a successfully escalation of privileges would be:
1. Low privilege user starts MSIEXEC repair of Netop Remote Control MSI-package
2. Low privilege user constantly queries “C:\Users\[username]\AppData\Local\Temp\Danware Data\Install” for new directories.
3. MSIEXEC creates a sub directory in “\Install” and writes multiple executables to the directory
4. In the time between file creation and execution, a low privilege user can replace the file with a malicious executable.
5. MSIEXEC executes the malicious executables in the user context of “NT Authority/SYSTEM”.