When investigating my laptop, I stumbled upon something interesting that resulted in privilege escalation. I use a Lenovo ThinkPad X1 Extreme Gen 1, which has an installed software named Glance, for my day-to-day work. The purpose of this software is to use the advanced web camera to figure out if you are speaking when the microphone is muted or to allow you to use gestures to perform actions. I made this discovery on the Glance Mirametrix version 4.5.16.39967 installed on my device. While I was testing this, I made sure that the installed version was the latest version available from Lenovo’s support homepage for my device.

Discovery

When looking for access permissions to services, I found that the service MaseService by Mirametrix allowed the built-in group Users to Change Config, meaning that all users could manipulate the service configuration. To check this, I used the tool accesschk.exe (https://docs.microsoft.com/en-us/sysinternals/downloads/accesschk) from Microsoft.

Exploitation

Looking at the current configuration, we can see that the default location for the service binary is C:\Program Files\Mirametrix\MaseService\bin\MaseService.exe.This can easily be checked with the command reg query:

"HKLM\System\CurrentControlSet\Services\maseservice” /v “ImagePath"

The MaseService is configured to be running as the Local Service account, and in this proof-of-concept, I am escalating from Local Service to SYSTEM using the known technique of creating a fake WinRM Server that you can read more about here: https://decoder.cloud/2019/12/06/we-thought-they-were-potatoes-but-they-were-beans/. Summarized, by creating a fake WinRM server, you can escalate to SYSTEM by coercing the system to connect to the fake WinRM Server and using that token. In my proof-of-concept, I have downloaded the RogueWinRM from https://github.com/antonioCoco/RogueWinRM to D:\Exploit-Dev\RogueWinRm\RogueWinRm.exe. Next, I changed the service to run the RogueWinRM.exe in order to escalate to SYSTEM and then started a .BAT file created under D:\Exploit-Dev called batfile.bat. The .BAT file has commands in it to create a new file under C:\Windows\System32 called file_created_from_batfile.txt.

Content of the .BAT file:

echo "Creating a file as system" > c:\windows\system32\file_created_from_batfile.txt

Stopping and starting the service ensured that the binary file was executed as Local Service and that the binary RogueWinRm.exe handled the escalation to SYSTEM and created the file under c:\windows\system32 by running the .BAT file.

The service fails to start because this is not a service binary, but the .BAT file gets executed, and the .txt file was created as expected, resulting in running code as SYSTEM.

The example in this blog post is a very simple proof-of-concept, and it should not be hard to take the RogueWinRm source code to create a custom exploit code. I will, however, leave that as an exercise to the reader.

Mitigation

When I sent this discovery to Lenovo’s Product Security Incident Response Team (PSIRT), I suggested changing the service’s access control lists so that users cannot change the service binary path. However, the fix was to remove the existing version of Glance and install a new one from the Microsoft Store (ms-windows-store://pdp/?productid=9MTVPHTPWQXG). I went through the mitigation steps and tried to reproduce the issue with the updated Microsoft Store app in cooperation with the PSIRT, but the problem was not present in the new Microsoft Store-based application.

Final Thoughts

Working with the PSIRT has been a pleasure—they respond fast and are polite and forthcoming in communications. They also sent me information during the process without me having to ask multiple times. The only thing I still see as an issue is that in order to mitigate, you have to manually remove the old Glance software. We all know how often mitigations like that are forgotten and ultimately missed. Fortunately, I received feedback from Lenovo when they reviewed this blog post that they are working on getting their system health application Vantage (default installed on Lenovo machines) to guide the user into removing the old versions of Glance and that this effort from them is almost complete.
Quote: “Soon, Vantage will be looking for the older Glance and leading users through the update process. ”

Timeline

January 21, 2022 - Initial discovery
January 24, 2022 - First email sent to PSIRT about the discovery
January 24, 2022 - Automatic reply from PSIRT
January 26, 2022 - Confirmation from PSIRT that the issue is being tracked and reviewed by the Development team
February 01, 2022 - Confirmation from PSIRT about the CVE number being obtained and communication between us surrounding the public disclosure, release date set to March 08, 2022
February 10, 2022 - Email from PSIRT that a fixed version is available in the Microsoft Store and questioning if I could verify that the issue is gone
February 11, 2022 - Mail from me confirming that the issue is fixed in the updated version, but the old version requires manual removal
March 01, 2022 - Mail from me asking if they had gotten a CVE number yet
March 01, 2022 - Answer from PSIRT confirming CVE-2022-24696
March 08, 2022 - Mail with details about the advisory being published at: https://support.lenovo.com/us/en/product_security/LEN-78115
March 09, 2022 – Thanked for the information and asked if PSIRT wanted to review my blog post before publishing
March 09, 2022 – Confirmation from PSIRT that they would love to review the blog post
March 11, 2022 – Blog post sent to PSIRT for review
March 11, 2022 – Feedback on blog post from Lenovo