[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[FD] Intel PowerGadget 3.6 Local Privilege Escalation
- To: "fulldisclosure@xxxxxxxxxxxx" <fulldisclosure@xxxxxxxxxxxx>
- Subject: [FD] Intel PowerGadget 3.6 Local Privilege Escalation
- From: Julian Horoszkiewicz via Fulldisclosure <fulldisclosure@xxxxxxxxxxxx>
- 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/