There is a privilege escalation vulnerability in the Windows Certificate Dialog box allowing an attacker to easily elevate privileges to NT AUTHORITY\SYSTEM; it is documented as CVE-2019–1388. The bug is found in the UAC (User Account Control) mechanism.
This post will cover the following:
- Official CVE Description
- Affected Systems
- Expected Final Outcome
- Steps to Reproduce Attack
- Video Demonstration
- HHUPD.EXE Reference File to Perform Attack
- Final Thoughts
Please note, I will be using hhupd.exe to perform the attack. Of course you do not need hhupd.exe to exploit this specific vulnerability in you’re next red team engagement; it was just easier at the time.
Vulnerability Information
Official CVE Description
An elevation of privilege vulnerability exists in the Windows Certificate Dialog when it does not properly enforce user privileges, aka ‘Windows Certificate Dialog Elevation of Privilege Vulnerability’.
Affected Systems
SERVER
Windows 2008r2 7601 ** link OPENED AS SYSTEM **
Windows 2012r2 9600 ** link OPENED AS SYSTEM **
Windows 2016 14393 ** link OPENED AS SYSTEM **
Windows 2019 1773 ** link NOT opened **
WORKSTATION
Windows 7 SP1 7601 ** link OPENED AS SYSTEM **
Windows 8 9200 ** link OPENED AS SYSTEM **
Windows 8.1 9600 ** link OPENED AS SYSTEM **
Windows 10 1511 10240 ** link OPENED AS SYSTEM **
Windows 10 1607 14393 ** link OPENED AS SYSTEM **
Windows 10 1703 15063 ** link NOT opened **
Windows 10 1709 16299 ** link NOT opened **
Expected Final Outcome
Steps to Reproduce
- Prepare a Windows 10 machine in Virtual Machine. I will be using Windows 10 build 1607.
- Created a low level privilege user named “Visitor” using the command “net user Visitor /add /active:yes” via the Command Prompt and logged in under the user.
- Copy hhupd.exe to the desktop. The file can be downloaded at https://github.com/suprise4u/CVE-2019-1388. This is an old ancient copy of a Microsoft-signed executable that has a certificate with a clickable hyperlink that opens up a browser as system that Microsoft forgot to disable. Please see the below HHUPD.EXE Reference section for more details regarding the file.
3. Right click the HHUPD.EXE file and Run as administrator. You will be prompted with a UAC dialog box and then click on Show more Details.
4. Click Show information about the publisher’s certificate.
5. Click VeriSign Commercial Software Publishers CA, Ok and No.
6. A browser is now launched as System with a 404 Verisign website being displayed. Save the webpage by clicking on the gear, File, Save as… You will be prompted with and error “Location is not available.” Click OK.
7. In the File name field, input c:\windows\system32\*.* and hit enter.
8. Scroll through and find cmd, right click and hit open.
9. Producing a command prompt as system.
Demonstration
HHUPD.EXE Reference
There is an obscure Microsoft-specific object identifier (OID) defined, having the numeric value 1.3.6.1.4.1.311.2.1.10. The WinTrust.h header defines this as SPC_SP_AGENCY_INFO_OBJID, and, if present, it will be displayed in the Details tab as SpcSpAgencyInfo. The semantics of this OID are poorly documented. It appears, however, that the certificate dialog parses the value of this OID, and if it finds valid and properly-formatted data, it will use it to render the “Issued by” field on the General tab as a hyperlink! And when it comes to the UAC version of the certificate dialog, Microsoft forgot to disable this hyperlink. Clicking on the hyperlink will launch a browser from consent.exe, and the browser will run as NT AUTHORITY\SYSTEM in a normal desktop as opposed to the Secure Desktop. Hence it will only become visible once the user has exited all the UAC dialogs (from Zero Day Initiative blog post located here).
Final Thoughts
Microsoft patched this vulnerability in November 2019 as CVE-2019–1388. The hhupd.exe file used to performed the attack was harder to obtain then I originally planned so I uploaded it to github once I got my hands on it. I also used Powershell and Windows SDK to create a custom binary instead of hhupd.exe as another file option to perform the the attack as provided by “pwndad” here. A big thank you to pwndad and Simon Zuckerbraun with Zero Day Initiative in providing insight to making this writeup possible. This was a classic one for sure.
