Microsoft Wireless Display Adapter 2 Command Injection / Broken Access Control Vulnerability

ID: 98803
CVE: None
Download vulnerable application: None
Command Injection, Broken Access Control and Evil-Twin-Attack in Microsoft Wireless Display Adapter V2 - CVE-2018-8306
 Affected Products:
Microsoft Wireless Display Adapter V2:
  - Microsoft Wireless Display Adapter V2 Softwareversion 2.0.8350 to 2.0.8372 have been tested and are affected by the Command Injection Vulnerability
  - Microsoft Wireless Display Adapter V2 Softwareversion 2.0.8350 has been tested and is affected by the Broken Access Control Vulnerability
  - Microsoft Wireless Display Adapter V2 Softwareversion 2.0.8350 has been tested and is affected by the Evil-Twin-Attack Vulnerability
  Other releases have not been tested. 
  - (Command Injection)
  - (Command Injection)
  Microsoft Wireless Display Adapter (MsWDA ) is a hardware device to
  "Share whatas on your tablet, laptop, or smartphone. All 
  MiracastA(r) enabled Windows 10 phones, tablets and laptops, 
  including the Surface line up. Stream movies, view personal 
  photos, or display a presentation on a big screen a all 
  wirelessly." [1]
     During our research we found a command-injection, broken 
  access control and an "evil-twin" attack.
  MsWDA uses Wifi-Direct for the Connection and Miracast for 
  transmitting Video- and Audiodata. The Wifi-Connection 
  between MsWDA and the Client is alwasy WPA2 encrypted. To 
  setup the connection, MsWDA provides a well-known mechanism: 
  Wi-Fi Protected Setup (WPS). MsWDA implements both push 
  button configuration (PBC) and PIN configuration. Despite the
  original design and name, MsWDA offers PBC with the button 
  virtually "pressed". A user simply connects. Regardless the 
  authentication method used (PBC or PIN), a client is assigned
  to a so called "persistent group". A client in a persistent 
  group does not have to re-authenticate on a new connection. 
  Command injection:
     The attacker has to be connected to the MsWDA.Using the 
  Webservice the Name of the MsWDA could be set in the 
  parameter "NewDeviceName". Appending characters 
  to escape command line scripts, the device gets into a 
  boot loop. Therefore the conclusion is legit, there is 
  a command injection. After several bricked MsWDAs we gave
     Broken Access Control:
  a) PBC is implemented against Wifi Alliance Best Practices [2]
  No Button has to be pressed, therefore the attacker has 
  just to be in network range to authenticate. Physical access
  to the device is not required.
     b) If an attacker has formed a persistent group with Push 
  Button Configuration, he can authenticate with the persistent 
  group, even if the configuration method is changed to PIN 
     c) A persistent group does not expire, so the access right 
  longs forever. The WPA2 key of the connection does not change 
  for a persistent group.
  To perform an Evil-Twin Attack, the Attacker has to be connected
  to the MsWDA attacked. He then offers an own Display Adapter Service
  with the same name like the MsWDA attacked. The user will only find 
  the attackers name in the available connections and connect to the 
  attackers Evil Twin. A replication service will stream the users data 
  from the attackers device to the MsWDA attacked. Therefore the user 
  will not be able to recognize the attack.
  Besides the ability to view streaming data, the attacker can use 
  the established connection to access other services on the victims
  device, e. g. files if shared to trusted networks by the user.
   Vulnerable Script for the command injection:
  /cgi-bin/, Parameter NewDeviceName
   Example for command injection:
  #show a device name with leading adapter_name=
  #bring Display Adapter into a bootloop
  Always use PIN method for authentication. This does not require 
  the attacker to have physical access, at least he nees the screen visible.
  According to the vendor, the command injection has been fixed in 
  the firmware update July 2018.  
         Disclosure Timeline:
  2018/03/21 vendor contacted
  2018/03/21 initial vendor response
  2018/04/06 vendor confirmation 
  2018/04/20 vendor informs about fixes planned
  2018/04/21 feedback to the vendor on the fixes
  2018/05/17 vendor provides timeline for the firmware fixes for July 10th
  2018/06/19 vendor provides assigend CVE number
  2018/07/10 vendor publishes Advisory and Firmware-Updates 
  2018/07/30 coordinated public disclosure
         External References:
1-4-2 (www01)