In our Labs Approach to Testing IoT Devices we have described strategies to analyse devices embedded into the Internet of Things (IoT). In this article, we tackle the communications analysis of an IOT device and its surrounding systems such as apps and server infrastructure. We chose to have a look at the Belkin WeMo Switch. The product has been proven to have various vulnerabilities such as privilege Escalation (VulDB 12452), information disclosure (VulDB 12451 and 12453), buffer overflow (VulDB 12454) and weak authentication (VulDB 12455). Belkin has removed these vulnerabilities. During this communications analysis we want to investigate if we can remote control one or several devices using new vulnerabilities in the exchange between app, WeMo Switch and Belkin’s infrastructure.

Belkin’s WeMo Switch is a power plug insert that allows users to turn on and off any device plugged into it. From everywhere. A WeMo Switch is being set up in a pre-existing Wireless LAN (WLAN) and controlled using an App (iOS or Android). If the app and the switch are connected to the same network, then they communicate directly. Direct communication relies on Universal Plug and Play (UPnP) and a simple REST-API. Remote communication is handled using HTTP and the same REST-API that is used with UPnP.

WeMo Switch Setup

During the initialization phase, WeMo Switch generates its own WLAN as an access point (AP). The SSID of the WLAN is assigned using the scheme WeMo.Switch.XXX whereas XXX is the last three digits of the serial number. The AP is – additionally – being used for DHCP servers and uses IP addresses in the range 10.22.22.0/24. A webserver on port tcp/49152 is used for device administration. The WeMo App uses this service to transfer WLAN access data to the WeMo Switch. This access data is being transferred as an XML Request as follows:

POST /upnp/control/WiFiSetup1 HTTP/1.1
Content-Type: text/xml; charset="utf-8"
SOAPACTION: "urn:Belkin:service:WiFiSetup:1#ConnectHomeNetwork"
Content-Length: 444
HOST: 10.22.22.1:49152
User-Agent: CyberGarage-HTTP/1.0

<?xml version="1.0" encoding="utf-8"?>
<s:Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/" s:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
  <s:Body>
    <u:ConnectHomeNetwork xmlns:u="urn:Belkin:service:WiFiSetup:1">
      <ssid>WeMoTest</ssid>
      <auth>WPA2PSK</auth>
      <password>edTQ/hzPJ7MpPeL/qBA5gseNRZWdNdPR5dUu9v8Br40=2d1a</password>
      <encrypt>TKIP</encrypt>
      <channel>7</channel>
    </u:ConnectHomeNetwork>
  </s:Body>
</s:Envelope>

The password is being transferred in an encoded form. The last four digits, in our case 2d1a, are Hex values and give away the length of the entire password string. 2d equals 45 characters. The actual length of the password equals the value 1a, 26 characters. We could not determine which encoding for the password is being used. WeMo Switch uses this access data in order to connect to and communicate with the WLAN and Belkin’s servers.

Subsequently, the remote access is being established. The app sends a request to the WeMo Switch, identifying an app by its unique DeviceId. Under iOS, the UniqueDeviceIdentifier (UDID) is being used as DeviceId. Android uses the International Mobile Equipment Identity (IMEI).

POST /upnp/control/remoteaccess1 HTTP/1.1
Content-Type: text/xml; charset="utf-8"
SOAPACTION: "urn:Belkin:service:remoteaccess:1#RemoteAccess"
Content-Length: 603
HOST: 10.22.22.1:49152
User-Agent: CyberGarage-HTTP/1.0

<?xml version="1.0" encoding="utf-8"?>
<s:Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/" s:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
  <s:Body>
    <u:RemoteAccess xmlns:u="urn:Belkin:service:remoteaccess:1">
      <DeviceId>9jiusa7pp00n3uzdbwfv2ulat5yy34x26ou1wgo2</DeviceId>
      <dst>0</dst>
      <HomeId></HomeId>
      <DeviceName>TestDevice23</DeviceName>
      <MacAddr></MacAddr>
      <pluginprivateKey></pluginprivateKey>
      <smartprivateKey></smartprivateKey>
      <smartUniqueId></smartUniqueId>
      <numSmartDev></numSmartDev>
    </u:RemoteAccess>
  </s:Body>
</s:Envelope>

WeMo Switch’s reply contains HomeId and two keys: pluginprivateKey and smartprivateKey. These keys are presumably being used for encryption and signing purposes during further communication. HomeId is made up of seven digits and maybe tied to the SSID or the MAC-address of the WLAN. In our test network, two devices were used independently from each other and they both used the same HomeId.

HTTP/1.1 200 OK
CONTENT-LENGTH: 632
CONTENT-TYPE: text/xml; charset="utf-8"
DATE: Fri, 24 Jul 2015 11:12:08 GMT
EXT:
SERVER: Linux/2.6.21, UPnP/1.0, Portable SDK for UPnP devices/1.6.18
X-User-Agent: redsonic

<s:Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/" s:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
  <s:Body>
    <u:RemoteAccessResponse xmlns:u="urn:Belkin:service:remoteaccess:1">
      <homeId>0000000</homeId>
      <pluginprivateKey>xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx</pluginprivateKey>
      <smartprivateKey>yyyyyyyy-yyyy-yyyy-yyyy-yyyyyyyyyyyy</smartprivateKey>
      <resultCode>PLGN_200</resultCode>
      <description>Successful</description>
      <statusCode>S</statusCode>
      <smartUniqueId>9jiusa7pp00n3uzdbwfv2ulat5yy34x26ou1wgo2</smartUniqueId>
      <numSmartDev>1</numSmartDev>
    </u:RemoteAccessResponse>
  </s:Body>
</s:Envelope>

Communication between WeMo App and Belkin’s Infrastructure

Communication between WeMo App and Belkin’s infrastructure can be divided into registration, enabling and disabling and firmware update.

Registration

During all requests related to registrations, the app uses a Basic Access Authentication Header that is formed following this scheme:

Authorization: SDU 9jiusa7pp00n3uzdbwfv2ulat5yy34x26ou1wgo2:gclbqUYLczNi+cJf+MJ5W/cmCeo=:1440403670@

In patent US9021139 B1 the building of the header is described. The SDU String from DeviceID, Signature and an expiration time are being combined. The field Signature could, according to the patent, be generated as follows: Signature=Base64(HMAC-SHA1(PrivateKey, StringToSign)). The key used in this is most likely one of the two keys used during initial registration.

The first request to the relay api.xbcs.net queries a list of registered devices assigned to a HomeId. During this, the DeviceID that is used as an authenticator is tied to the HomeId. In our tests, we did not succeed in accessing a different HomeId using a DeviceId. These requests are being blocked by the server with an error message. During successful requests, the server outputs a list of registered devices assigned to a HomeId.

HTTP/1.1 200 OK
asyncServiceInvoke: false
Content-Type: application/xml;charset=ISO-8859-1
Date: Mon, 24 Aug 2015 08:05:51 GMT
Server: Apache-Coyote/1.1
X-Powered-By: Servlet/3.0; JBossAS-6
Content-Length: 1242
Connection: keep-alive

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<devices xmlns:modelns="http://datamodel.components.cs.belkin.com/" success="S" fail="F" partial_success="P">
  <statusCode>S</statusCode>
  <resultCode>
    <code>PLGN_200</code>
    <description>Successful</description>
  </resultCode>
  <message>Device list retrieved successfully</message>
  <home>
    <homeId>0000000</homeId>
    <description>this is first plugin initialization</description>
    <firmwareId>0</firmwareId>
  </home>
  <device>
    <pluginId>1111111</pluginId>
    <macAddress>00005E005300</macAddress>
    <serialNumber>22222222222Z00</serialNumber>
    <uniqueId>uuid:Socket-1_0-22222222222Z00</uniqueId>
    <modelCode>Socket</modelCode>
    <productType>Socket</productType>
    <status>3</status>
    <notificationType>0</notificationType>
    <firmwareVersion>WeMo_WW_2.00.2176.PVT</firmwareVersion>
    <hwVersion>v1</hwVersion>
    <fwUpgradeStatus>4</fwUpgradeStatus>
    <signalStrength>29</signalStrength>
    <friendlyName>WeMo Switch 5</friendlyName>
    <dbVersion>0</dbVersion>
    <customizedState>1</customizedState>
    <attributeLists action="GetAttributes">
      <attribute>
        <name>hardResetTS</name>
        <value>1438939404278</value>
      </attribute>
    </attributeLists>
  </device>
  <groupSSIDs>
    <ssid>WeMoTest</ssid>
  </groupSSIDs>
  <groupArpMacs>
    <arpMac>00005E005301</arpMac>
  </groupArpMacs>
</devices>

The list contains further, hitherto unknown markers of a device. Among them are PluginId (also used as RecipientId in some cases), the macAddress as well as the firmware version of the WeMo Switch. These markers are being used for further actions such as the enabling and disabling of the WeMo Switch. In addition to that, the SSID of the WLAN as well as the MAC address of the AP are being stored at Belkin’s.

Turning it off and on

The command to turn the device on or off is being sent to the host api.xbcs.net. In order to send this message, an authentication using the Basic Access Authentication Header is necessary. The WeMo Switch is being addressed using the fields PluginId and RecipientId or the macAddress. The status of the device is being controlled using the values 0 and 1.

POST /apis/http/plugin/message HTTP/1.1
Host: api.xbcs.net:8443
<redacted by scip AG>

<plugins>
  <plugin>
    <recipientId>1111111</recipientId>
    <macAddress>00005E005300</macAddress>
    <content>
      <![CDATA[
      <pluginSetDeviceStatus>
        <plugin>
          <pluginId>1111111</pluginId>
          <macAddress>00005E005300</macAddress>
          <status>1</status>
          <friendlyName></friendlyName>
          <eventDuration>(null)</eventDuration>
          <cookedTime>(null)</cookedTime>
        </plugin>
      </pluginSetDeviceStatus>
      ]]>
    </content>
  </plugin>
</plugins>

Firmware Update

The WeMo app can also be used to update the firmware of the WeMo Switch. In the reply to the initial request that – in turn – contains the Basic Access Authentication Header the app receives a link to a site that lists all available firmware versions. The access to the firmware uses unencrypted connections, even though the server would be available per HTTPS.

HTTP/1.1 200 OK
asyncServiceInvoke: false
Content-Type: application/json;charset=ISO-8859-1
Date: Thu, 10 Sep 2015 12:35:43 GMT
Server: Apache-Coyote/1.1
X-Powered-By: Servlet/3.0; JBossAS-6
Content-Length: 133
Connection: keep-alive

{"fwUpgradeInfo":{"firmwareId":0,"description":"Default firmware file","fwUpgradeURL":"http:\/\/fw.xbcs.net\/wemo\/NewFirmware.txt"}}

The firmware binary itself is encrypted using GPG and is being extracted on the WeMo Switch itself. The use of GPG to distribute firmware is basically a good idea, only that Belkin made a grave mistake when implementing it. Security researcher Mike Davis of IOActive discovered in 2013 that Belkin had integrated the GPG Signing Key into the WeMo firmware image. An attacker could extract this key and sign his own firmware version with it, which he would be able to transfer to the device. The firmware update dated 24 January 2014 fixed this vulnerability.

Information About Belkin’s Infrastructure

Belkin runs its infrastructure on Amazon EC2 Cloud. The infrastructure includes the systems ota.xbcs.net, api.xbcs.net and fw.xbcs.net. We were able to identify Red Hat Linux, Apache 2.2.15 and JBoss 6.

When starting the WeMo Switch, log data is being sent to a system with the IP address 184.73.191.189. The MAC-Address 00005E005300 that belongs to the WeMo Switch is being used as ID during the POST request. There is no further authentication necessary and there are no further checks that investigate the content. This means that arbitrary content using arbitrary MAC-Addresses can be submitted to Belkin’s servers. It was, however, impossible to access already submitted content as well as stored data.

PUT /ToolService/log/uploadWdLogFile/00005E005300 HTTP/1.1
Host: 184.73.191.189:8899
Content-Type: multipart/octet-stream
Accept: application/xml
Content-Length: 301
Expect: 100-continue

[2015-08-07][08:33:35]|RT|Internet is connected
[2015-08-07][08:33:39]|PLUGINREMOTEREGISTER|Plugin App Remote ReRegister
[2015-08-07][08:33:37]|SIG|Connection signal strength: 55
[2015-08-07][08:33:40]|Plugin App Remote ReRegister failure|
[2015-08-07][08:33:40]|Plugin App Remote ReRegister failure|


HTTP/1.1 200 OK
Server: Apache-Coyote/1.1
Content-Type: application/xml
Content-Length: 67
Date: Fri, 07 Aug 2015 06:33:58 GMT

/opt/deviceLogs2/20150807/wdLogFile_00005E005300_20150807063358.log

Lesson Learned

When the WeMo Switch was first published, it wasn’t long before several vulnerabilities had been discovered. In the area of communication between application, WeMo Switch and server infrastructure Belkin has learned from this and remote communication has been secured to the point where devices can not be remote controlled without prior authentication. In addition to that, the devices and local networks are being tied to one another and it’s not possible without further attacks to find other local networks and their devices using a trial and error enumeration method. Therefore, it’s not easy for a remote attacker to carry out a successful attack. It remains to hope that other IoT manufacturers learn a lesson from this and implement security features mitigating these issues from the first version onwards.

About the Authors

Michael Schneider has been in IT since 2000. Since 2010 he is focused on information security. He is an expert at penetration testing, hardening and the detection of vulnerabilities in operating systems. He is well-known for a variety of tools written in PowerShell to find, exploit, and mitigate weaknesses. (ORCID 0000-0003-0772-9761)

Veit Hailperin has been working in information security since 2010. His research focuses on network and application layer security and the protection of privacy. He presents his findings at conferences.

Links

• http://developers.belkin.com/wemo/sdk
• http://www.belkin.com/us/p/P-F7C027
• http://www.belkin.com/us/support-article?articleNum=80322
• http://www.ioactive.com/pdfs/IOActive_Belkin-advisory-lite.pdf
• https://fw.xbcs.net/wemo/switchsensor
• https://vuldb.com/?id.12451
• https://vuldb.com/?id.12452
• https://vuldb.com/?id.12453
• https://vuldb.com/?id.12454
• https://vuldb.com/?id.12455
• https://www.google.com/patents/US9021139