Intel PowerGadget 3.6 Local Privilege Escalation
2024-3-29 03:7:55 Author: seclists.org(查看原文) 阅读量:14 收藏

fulldisclosure logo

Full Disclosure mailing list archives


From: Julian Horoszkiewicz via Fulldisclosure <fulldisclosure () seclists org>
Date: Thu, 28 Mar 2024 04:32:26 +0000

Vulnerability summary: Local Privilege Escalation from regular user to SYSTEM, via conhost.exe hijacking triggered by 
MSI installer in repair mode
Affected Products: Intel PowerGadget
Affected Versions: tested on PowerGadget_3.6.msi (a3834b2559c18e6797ba945d685bf174), file signed on ‎Monday, ‎February 
‎1, ‎2021 9:43:20 PM (this seems to be the latest version), earlier versions might be affected as well.
Affected Platforms: Windows
Common Vulnerability Scoring System (CVSS) Base Score (CVSSv3): 7.8 HIGH
Risk score (CVSSv3): 7.8 HIGH AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H 
(https://nvd.nist.gov/vuln-metrics/cvss/v3-calculator?vector=AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H&version=3.1)

I have reported this issue to Intel, but since the product has been marked End of Life since October 2023, it is not 
going to receive a security update nor a security advisory. Intel said that they are OK with me making this finding 
public, under the condition that I would emphasize that the product is EOL.

Description and steps to replicate:
On systems where Intel PowerGadget is installed from an MSI package, a local interactive regular user is able to run 
the MSI installer file in the "repair" mode and hijack the conhost.exe process (which is created by an instance of 
sc.exe the installer calls during the process) by quickly left-clicking on the console window that pops up for a split 
second in the late stage of the process. Left-clicking on the conhost.exe console window area freezes the console 
(meaning it prevents the sc.exe process from exiting). That process is running as NT AUTHORITY/SYSTEM. From there, it 
is possible to run a web browser by clicking on one of the links in the small GUI window that can be called by 
right-clicking on the console window bar and entering "properties". Once a web browser is spawn, attacker can call up 
the "Open" dialog and in that way get a fully working escape to explorer. From there they can, for example, browse 
through C:\Windows\System32 and right-click on cmd.exe and run it, obtaining as SYSTEM shell.

Now - an important detail - on most recent builds of Windows neither Edge nor Internet Explorer will spawn as SYSTEM 
(this is a mitigation from Microsoft); thus for successful exploitation another browser has to already be present in 
the system. As you can see I pick Chrome and then spawn an instance of cmd.exe, which turns out to be running as 
SYSTEM. Also, when doing this, DO NOT check "always use this app" in that dialog, as if you pick the wrong one (e.g. 
Edge or IE), it will be saved as the default http/https handler for SYSTEM and from then further attacks like this 
won't work if you want to repeat the POC - unless you reverse that change somewhere in the registry.

This class of Local Privilege Escalations is described by Mandiant in this article: 
https://www.mandiant.com/resources/blog/privileges-third-party-windows-installers.

To run the installer in repair mode, one needs to identify the proper MSI file. After normal installation, it is by 
default present in C:\Windows\Installer directory, under a random name. The proper file can be identified by attributes 
like control sum, size or "author" information.
The exploitation process is illustrated in the screenshots below, reflecting the the steps taken to attain a SYSTEM 
shell (no exploit development is required, the issue can be exploited using GUI).

Recommendation:
Technically, as per the reference, it is recommended to change the way the sc.exe is called, using the WixQuietExec() 
method (see the second reference). In such case the conhost.exe window will not be visible to the user, thus making it 
impossible to perform any GUI interaction and an escape.
I am, however, aware that this product is no longer maintained since October 2023 
(https://www.intel.com/content/www/us/en/developer/articles/tool/power-gadget.html) and that includes security updates. 
Still, I believe a security advisory and CVE should be released just to make users and administrators aware why they 
need to replace PowerGadget with Intel Performance Counter Monitor.
Another possible (short-term) mitigation is to disable MSI 
(https://learn.microsoft.com/en-us/windows/win32/msi/disablemsi).

References:
https://hackingiscool.pl/intel-powergadget-3-6-local-privilege-escalation/
https://www.mandiant.com/resources/blog/privileges-third-party-windows-installers
https://wixtoolset.org/docs/v3/customactions/qtexec/
https://www.intel.com/content/www/us/en/developer/articles/tool/power-gadget.html)https://learn.microsoft.com/en-us/windows/win32/msi/disablemsi
_______________________________________________
Sent through the Full Disclosure mailing list
https://nmap.org/mailman/listinfo/fulldisclosure
Web Archives & RSS: https://seclists.org/fulldisclosure/

Current thread:

  • Intel PowerGadget 3.6 Local Privilege Escalation Julian Horoszkiewicz via Fulldisclosure (Mar 28)

文章来源: https://seclists.org/fulldisclosure/2024/Mar/43
如有侵权请联系:admin#unsafe.sh