In this post, we will cover a privilege escalation that I found in the Intel Trusted Connect Service Client. The Connect Service Client is part of Intel Management Engine Components and is designed to permit a non-privileged user to become system. After communicating with Intel about the vulnerability, it was discovered that this was already fixed in an up to date version of the software, and therefor, this discovery would not get a CVE (Not that it matters ????). I want to point out that this discovery was heavily inspired by @sandboxescaper’s blogpost http://sandboxescaper.blogspot.com/2019/12/chasing-polar-bears-part-one.html.

The vulnerable software version I was testing against was Intel Management Engine Components 1822.12.0.1132.

The vulnerability described in this article was already fixed in the version 1909.12.0.1236 release in March 2019 - https://downloadcenter.intel.com/download/28679/Intel-Management-Engine-Driver-for-Windows-8-1-and-Windows-10

It’s currently unknown if versions before 1822.12.0.1132, and between 1822.12.0.1132 and 1909.12.0.1236 are also vulnerable.

Discovery

After the x64 or x86 version of Intel Trusted Connect Service Client is installed on Windows, an msi file is added to the “c:\windows\installer” directory. During testing it was observed that the x64 version of this msi file was named b2af.msi. This, of course, is normal behavior and is how the Windows installer engine works, but due to how the Intel msi is built, it is possible to use this to perform a privilege escalation from a standard user and run binaries under the system account. Observing the behavior with Procmon while running “msiexec /fa b2af.msi” from “c:\windows\installer” reveals that the installer is changing or resetting the access control list of all the files under “C:\ProgramData\Intel\iCLS Client\log”. The /fa parameter supplied to the msiexec command is used to repair the installation and can be executed as a normal user. I will not list out all the filters I used in Procmon, but including only the process msiexec.exe and operation that begins with “Set” is a good start.

These were the files files found on my system under “C:\ProgramData\Intel\iCLS Client\log”:

• iclsClient.log
• iclsProxy.log
• IntelPTTEKRecertification.log
• socketheciserver.log
• TPMProvisioningService.log

As you can see in Figure 1, when the msiexec command is executed, you can find an operation called SetSecurityFile that is executed as “NT AUTHORITY\SYSTEM”. SetSecurityFile is normally the operation performed when access Control Lists (ACLs) are changed on an object - in this case, it was performed on files.

The main problem with this is that EVERYONE has full access to these files, meaning this is exploitable in a way that makes it possible for a normal user to change the ACL on any file on the computer by redirecting the SetSecurityFile operation to somewhere else.

Exploit

There are many ways one could exploit this. When I sent this to Intel, I did not want to spend a lot of time writing a lot of proof-of-concept code, so I decided that I would just overwrite a binary file for a running service with a payload that creates a new administrator user. I will leave other exploit ideas up to the reader, but there are many far more exciting ways than the one I am writing about here.

To exploit this, we are going to use tools from the symlink testing repo created by James Foreshaw @tiraniddo (https://github.com/googleprojectzero/symboliclink-testing-tools). It is possible as a normal user to create a hardlink, using the CreateHardlink.exe. In this post, I will be overwriting the binary to an Intel Service that I will subsequently abuse to perform the privilege escalation, but any service could be targeted.

As seen in Figure 3, we are targeting the Intel SUR QC Software Asset Manager service, with the goal to first overwrite the ACL for the IntelSoftwareAssetManagerService.exe (Used by the service) and then replace the binary with our exploit, creating a new administrator user on the computer.

First, we need to create a hardlink using the symlink testing repo toolkit, shown in Figure 4. Basically, we are first deleting the iclsClient.log file and then creating a hardlink using the name of the deleted file and pointing it towards the service binary.

After the hardlink is created, we can re-issue the “msiexec /fa b2af.msi” command to trigger the setting of ACLs toward the IntelSoftwareAssetManagerService.exe and then verify that the ACL was set by viewing the security tab on the file properties. As seen in Figure 5, this was a success.

A payload from MSFVENOM is used to create new user as a proof of concept. The command issued in msfvenom is: msfvenom -p windows/adduser USER=intelPOC PASS=intelP0C! -f exe-service -o /mnt/c/temp2/IntelSoftwareAssetManagerService.exe -e x86/shikata_ga_nai -i 3

Next, we copy the file over to the IntelSoftwareAssetManagerService.exe residing in the “C:\Program Files\Intel\SUR\QUEENCREEK\Updater\bin” folder, overwriting the legitimate service binary.

Now we can start the service and the user is magically created.

The exploit is now complete and local admin access was obtained from a standard user in Windows.  

Timeline

December 23, 2019 - Initial discovery

December 30, 2019 - Report sent to [email protected]

December 30, 2019 - Case created

December 31, 2019 - Response received from the Product Team stating that this was previously known and already fixed. Case closed.

Conclusion

Despite a patch having been released to address this vulnerability, I’d imagine the list of companies patching Intel Management Engine is pretty short. It's important to patch not only the operating system and commonly used software, but also lesser used software such as driver utilities. And I must admit, I have seen older versions on engagements