What is the Business Impact? 5

Written by Mark Stanislav and Tod Beardsley | September 2015* © Rapid7 2015

HACKING IoT: A Case Study on Baby Monitor Exposures and Vulnerabilities

IoTsec *Last updated September 29, 2015

HACKING IoT: A Case Study on Baby Monitor Exposures and Vulnerabilities

01

02

03

04

05

06

07

08

The Internet of Things 2

No Easy Fixes 3

Why Baby Monitors? 4

What is the Business Impact? 5

Common Vulnerabilities and Exposures for IoT Devices 6

Vulnerability Reporting and Handling 8

Disclosures 9

Working to Improve IoT Security 14

About Rapid7 15

Contents

09

Executive Summary

The term “Internet of Things” (IoT) is used to describe a galaxy of wildly different devices, from twenty dollar children’s toys to airliners that cost hundreds of millions of dollars. While this paper focuses on the consumer end of the IoT spectrum, we believe that the findings can inform how security researchers look at undiscovered vulnerabilities affecting expensive, industrial devices as well.

While Rapid7 is not aware of specific campaigns of mass exploitation of consumer-grade IoT devices, this paper should serve as an advisory on the growing risk that businesses face as their employees accumulate more of these interconnected devices on their home networks. This is especially relevant today, as employees increas- ingly blur the lines between home networks and business networks through routine telecommuting and data storage on cloud resources shared between both contexts.

Several video baby monitors from a cross-section of manufacturers were subjected to in-depth security testing, and all of the devices under test exhibited several of these common security issues.

This paper focuses specifically on ten new vulnerabilities which were disclosed to the individual vendors, to CERT, and to the public, in accordance with Rapid7’s Disclosure Policy1. CVE-2015-2880 through CVE-2015- 2889 (inclusive) were assigned by CERT. Typically, these newly disclosed vulnerabilities are only effectively mitigated by disabling the device and

applying a firmware update when one becomes available, or with updates to centralized vendor cloud services.

The vulnerabilities explored and dis closed in this paper are broken down according to the “reach” of the attack, that is, if the issues are exploit- able only with physical access to the device; if they are exploitable via the local network; or if they are exploitable from the Internet.

It is important to stress that most of the vulnerabilities and exposures discussed in this paper are trivial to exploit by a reasonably competent attacker, especially in the context of a focused campaign against company officers or other key business person- nel. If those key personnel are operating IoT devices on networks that are routinely exposed to business assets, a compromise on an otherwise relatively low-value target – like the video baby monitors covered in this paper – can quickly provide a path to compromise of the larger, nominally external, organizational network.

Finally, this paper also discusses the insecure-by-default problems inherent in the design of IoT devices, the diffi- culty for vendors to develop and deliver patches, the difficulties end-users face in learning about, acquiring, and applying patches once developed, and the friction involved in reporting issues to vendors in a way that is beneficial to end-users. Only one vendor cited in this report, Philips N.V., responded with an expected timeline for producing fixes for the issues described.

This is especially

relevant today,

as employees

increas ingly blur

the lines between

home networks

and business

networks.

1 https://www.rapid7.com/disclosure.jsp

| Rapid7.com Hacking IoT: A Case Study on Baby Monitor Exposures and Vulnerabilities 2

For our purposes, we can think of a “Thing” with “Internet” as simply any device, regardless of size, use, or form factor, that contains a CPU and memory, runs software, and has a network interface which allows it to communicate to other devices, usually as a client, sometimes as a server. In addition, these Things tend not to resemble traditional computers. They lack a typical keyboard and mouse interface, and they often have a user interface not centered around a monitor or other text-filled screen. Finally, these devices are marketed and treated as if they are single purpose devices, rather than the general purpose computers they actually are.

This last distinction is often the most dangerous one to make when it comes to deploying IoT devices. In his keynote address to the Chaos Computer Club, Lockdown: the coming war on gener- al-purpose computing2, Cory Doctorow makes the case that with today’s technology and current computer science thinking, we cannot yet create a computer that is anything other than a general purpose computer. End users may have devices that are nominally prohibited from performing certain actions according to the manufacturer, and those manufacturers sometimes go to great lengths to foil modification efforts. In the end, though, it is not possible to build and sell a computing device that cannot be coerced into rebelling against a manufacturer’s intentions.

The classic example of a manufactur- er-imposed prohibited action is media playback restrictions based on a digital rights management (DRM) system. The strategies employed for blocking some kinds of media, while allowing others, are proven to be fundamentally flawed, time and time again.

Self-identified hackers and tinkerers have been compromising DRM systems for decades, coercing media data files and media playback devices into a form more useful for the end-user. Such efforts merely require time, materials, and ingenuity, and are based on a foundational realization that there is truly no such thing as a single-purpose computer. Efforts to evade DRM may ultimately be too costly in terms of time and materials, and may require expertise beyond that of the end-user. While such DRM-evading efforts tend to violate local intellectual property laws, they do not violate the principles of computer science or engineering.

Security systems, like DRM, are for controlling access. Users rely on these systems to prevent unauthorized adversaries from viewing, altering, or destroying data on the secured system. Also like DRM, such systems are not foolproof, since again, the barriers to defeating security systems are time, materials, and expertise, and not the fundamental design of the computing platform. Because IoT devices do not normally appear to be, or behave like, the traditional computers we are familiar with, it is easy for the

designers and vendors of these systems to forget this general-purpose property. As a result of this oversight, basic precautions to thwart even casual attackers can fail to make it into production.

IoT devices are actually general purpose, networked computers in disguise, running reasonably complex network-capable software. In the field of software engineering, it is generally believed that such complex software is going to ship with exploitable bugs and implementation-based exposures. Add in external components and dependencies, such as cloud-based controllers and programming inter- faces, the surrounding network, and other externalities, and it is clear that vulnerabilities and exposures are all but guaranteed.

THE INTERNET OF THINGS 01

2 https://boingboing.net/2012/01/10/ lockdown.html

https://boingboing.net/2012/01/10/ lockdown.html
https://boingboing.net/2012/01/10/ lockdown.html
| Rapid7.com Hacking IoT: A Case Study on Baby Monitor Exposures and Vulnerabilities 3

With traditional computers, we under- stand that access controls are required in order to satisfy basic security require- ments. We also know that these con trols will contain bugs, or may simply be rendered obsolete in the face of a novel new attack. Such circumstances are inevitable, and require a configuration change, a patch, or an entirely new design.

IoT devices, unlike traditional comput- ers, often lack a reasonable update and upgrade path once the devices leave the manufacturer’s warehouse. Despite the fact that the network is what makes the Internet of Things so interesting and useful, that network is rarely, if ever, used to deliver patches in a safe and reasonably secure way.

The absence of a fast, reliable, and safe patch pipeline is a serious and ongoing deployment failure for the IoT. A sub-one hundred dollar video baby monitor, a five hundred dollar smart phone, a thirty-five thousand dollar connected car, and a four hundred million dollar jet airliner are all difficult to patch, even when vulner- abilities are identified, known, and a fix is in hand. This situation is due to a confluence of factors, ranging from the design of these devices, through the regulatory environment (or lack thereof) in which these components and devices exist. Today, a commonly accepted (or truly acceptable) way to effect a rapid rollout of patches simply does not exist.

Unpatchable devices are coming online at an unprecedented rate, and represent a tsunami of unsecurable- after-the-fact devices. According to a 2014 Gartner report3, the IoT space will be crowded with over 25 billion devices in five years, by 2020. The devices being built and shipped today are establishing the status quo of how these Things will be designed, assem- bled, commoditized, and supported, so we must take the opportunity, now, to both learn the details of the supply chain that goes into producing and shipping IoT devices, the vulnerabilities and exposures most common to these computers in disguise, and how we can work across the entire manufacturing space to avoid an Internet-wide disaster caused by the presence of these devices on the nervous system of Planet Earth.

Compounding these patching problems is the fact that the use of commodity, third-party hardware, software, and cloud-based resources is prevalent in the IoT industry. While reusing off-the- shelf technologies is critical in keeping costs of production low, it introduces an ambiguity of ownership for developing and deploying patches and other upgrades.

If a vulnerability’s root cause is traced to a third-party software library, for example, the more correct fix would be to patch that library. However, this decision can lead to a “pass the buck” mentality for the vendors involved in

the supply chain, ultimately delaying effective patching for the particular device in which the vulnerability was first discovered.

This patchwork of common compo- nents leads to confusing amalgamations of interdependencies, and can leave end-users exposed while the details of remediating vulnerabilities are worked out between vendors.

NO EASY FIXES 02

3 https://www.gartner.com/newsroom/ id/2905717

Tue, Jul 01, 2015: Confirmed receipt by the vendor

https://www.gartner.com/newsroom/id/2905717
https://www.gartner.com/newsroom/id/2905717
| Rapid7.com Hacking IoT: A Case Study on Baby Monitor Exposures and Vulnerabilities 4

The research presented focuses on the security of retail video baby monitors for a number of reasons. Baby moni- tors fulfill an intensely personal use case for IoT. They are usually placed near infants and toddlers, are intended to bring peace of mind to new parents, and are marketed as safety devices. By being Internet accessible, they also help connect distant family members with their newest nieces, nephews, and grandchildren, as well as allow parents to check in on their kids when away

from home. They are also largely commodity devices, built from general purpose components, using chipsets, firmware, and software found in many other IoT devices.

Video baby monitors make ideal candi- dates for security exploration; not only are they positioned as safety and security devices (and therefore, should be held to a reasonably high standard for security), but the techniques used in discovering these findings are easily

transferable to plenty of other areas of interest. Other products of direct interest to commercial and industrial consumers and security researchers (commercial security systems, home automation systems, on-premise climate control systems) share many of the insecure design and deployment issues found in video baby monitors.

WHY BABY MONITORS? 03

| Rapid7.com Hacking IoT: A Case Study on Baby Monitor Exposures and Vulnerabilities 5

While video baby monitors are vastly more commonplace in a home environ- ment and uncommon in an office environment, office environments and home environments are, increasingly, literally the same environment.

The percentage of employees and contractors who are working from home on at least a part time basis continues to rise across every modern economy. New parents are traditionally at the core of this trend, though it is increasingly common across all genders, ages, and family statuses4. These employees are, as a matter of necessity, connecting to their work- place virtually, either through VPN connections or through the use of cloud services shared by colleagues.

The presence of devices that are insecure by default, difficult to patch, and impossible to directly monitor by today’s standard corporate IT security practices constitutes not only a threat to the IoT device and its data, but also

to the network to which it’s connected. As the IoT is made up of general purpose computers, attackers may be able to leverage an exposure or vulnerability to gain and maintain persistent access to an IoT device. That device can then be used to pivot to other devices and traditional com- puters by taking advantage of the unsegmented, fully trusted nature of a typical home network.

Today, employees’ home networks are rarely, if ever, “in scope” for organizational penetration testing exercises, nor are they subject to centralized vulnerability scanners.

Another concern is the raw computing power available to attackers in the form of millions to billions of IoT devices. In total, the teraflops of processing power may be effectively harnessed by malicious actors to launch powerful distributed denial of service (DDoS) attacks against arbitrary Internet targets.

Given the lack of home network and on-board monitoring, remediating such attacks may prove extremely difficult once underway, and short-term solutions will tend to deny service to large chunks of residential network space. This, in turn, can knock sizable percentages of the aforementioned stay-at-home workforce offline, with little recourse for employers not prepared to offer alternative workplace accommodations.

WHAT IS THE BUSINESS IMPACT?

04

4 http://www.nytimes.com/2014/03/08/ your-money/when-working-in-your-pa- jamas-is-more-productive.html

| Rapid7.com Hacking IoT: A Case Study on Baby Monitor Exposures and Vulnerabilities 6

Known Vulnerabilities Brand-name manufacturers of IoT devices tend to implement much of the technology used by their products as embedded systems subcomponents, sourced from third party suppliers.

The upstream vendors of these sub- components tend to run extremely large operations, producing millions of units in a given year, and any change in this supply chain is both time consuming and expensive. Due to the nature of this time-lagged supply

chain, individual software components may be months to years old before being assembled into the final product, bringing old and commonly known software vulnerabilities along with them.

COMMON VULNERABILITIES AND EXPOSURES FOR IoT DEVICES

05

The items below describe the common vulnerabilities and exposures for IoT devices. Not all IoT devices suffer from all of these software, firmware, and hardware issues, but it is rare to find an IoT device that doesn’t exhibit at least one critical failing. Of the devices under test, all exhibited several common vulnerabilities and exposures.

KNOWN VULNERABILITIES OLD VULNERABILITIES THAT SHIP WITH NEW DEVICES

Cleartext Local API Local communications are not encrypted

Cleartext Cloud API Remote communications are not encrypted

Unencrypted Storage Data collected is stored on disk in the clear

Remote Shell Access A command-line interface is available on a network port

Backdoor Accounts Local accounts have easily guessed passwords

UART Access Physically local attackers can alter the device

Table 1, Common Vulnerabilities and Exposures

| Rapid7.com Hacking IoT: A Case Study on Baby Monitor Exposures and Vulnerabilities 7

Cleartext Local API Devices built with commodity compo- nents and software often fail to use modern cryptographic standards for LAN-local communications. While it is “only the LAN,” there are many passive and active network attacks which can be defeated simply by using common encrypted protocols, such as HTTPS and SSH.

Cleartext Cloud API Major Internet brands, such as Facebook, Google, Twitter, and other household names are adopting en – cryption across the board in order to ensure the privacy and authenticity of communications routed over the public (and eavesdroppable) Internet. However, services connected with IoT devices often fail to adhere to this increasingly common standard.

Unencrypted Storage In addition to the cleartext implement- ations described above, an ideal IoT recording device such as a video baby monitor should store all recordings in industry standard, encrypted formats, where only authorized users have access to the recorded data.

Remote Shell Access IoT devices often ship with default or otherwise unconfigured portable operating systems, and are often host to a Linux or other POSIX kernel with a set of stock utilities, such as BusyBox. While these are quite useful for devel- oping and tinkering with hardware, they should not be made available on production systems where shell access is never desired or required.

Backdoor Accounts As these devices are developed, manufacturers occasionally include either default accounts or service accounts, which are either difficult or impossible to disable under normal usage. Furthermore, these accounts often use default or easily guessable passwords, and tend to share the same unchangeable password, SSH key, or other secret-but-universally-shared token. Finally, these accounts may be protected by a password unique to the device, but the password generating algorithm is easily deduced and the passwords for all devices can be guessed with low attacker effort.

UART Access Universal Asynchronous Receiver/ Transmitter (UART) interfaces often enable a physically close attacker to access and alter IoT devices in ways that bypass the normal authentication mechanisms via a serial cable connec- tion. In addition, UART interfaces tend to grant root access, far exceeding the permissions of regular users. UART access is both a useful diagnostic tool and an excellent means of “rooting” or “jailbreaking” consumer devices. Such activities on a device specifically made for safety and security can lead to some very sneaky persistent attacks. IoT devices such as these should at least be tamper-evident, and give the owner or investigator some obvious indication that it has been altered, if UART access is intended at all.

Newly Discovered Vulnerabilities and Exposure Summary This report is primarily focused on newly discovered vulnerabilities, rather than exhaustively detailing the expected and typical vulnerabilities found across the IoT space. Table 2 summarizes the new vulnerabilities discovered and disclosed to the vendors and CERT.

CVE-2015-2886 Remote R7-2015-11.1 Predictable Information Leak iBaby M6

CVE-2015-2887 Local Net, Device R7-2015-11.2 Backdoor Credentials iBaby M3S

CVE-2015-2882 Local Net, Device R7-2015-12.1 Backdoor Credentials Philips In.Sight B120/37

CVE-2015-2883 Remote R7-2015-12.2 Reflective, Stored XSS Philips In.Sight B120/37

CVE-2015-2884 Remote R7-2015-12.3 Direct Browsing Philips In.Sight B120/37

CVE-2015-2888 Remote R7-2015-13.1 Authentication Bypass Summer Baby Zoom Wifi Monitor & Internet Viewing System

CVE-2015-2889 Remote R7-2015-13.2 Privilege Escalation Summer Baby Zoom Wifi Monitor & Internet Viewing System

CVE-2015-2885 Local Net, Device R7-2015-14 Backdoor Credentials Lens Peek-a-View

CVE-2015-2881 Local Net R7-2015-15 Backdoor Credentials Gynoii

CVE-2015-2880 Device R7-2015-16 Backdoor Credentials TRENDnet WiFi Baby Cam TV-IP743SIC

Table 2, Newly Identified Vulnerabilities

| Rapid7.com Hacking IoT: A Case Study on Baby Monitor Exposures and Vulnerabilities 8

One of the goals of this research is to practice reasonable, coordinated disclosures with vendors of IoT equip- ment. So, as a matter of course, the vulnerabilities discovered as part of this research were reported in accor- dance to Rapid7’s Vulnerability Disclosure Policy. According to this policy, vendors are contacted once the findings are verified, then after 15 days, CERT is contacted. 45 days after that (60 days after the initial disclosure attempt), the findings are published.

During the course of the vulnerability disclosure process, we saw vendors exhibit the entire range of possible responses. One vendor was impossible to contact, having no domain or any

other obvious Internet presence beyond an Amazon store listing. Some vendors did not respond to the reported findings at all. Others responded with concerns about the motives behind the research, and were wondering why they should be alerted or why they should respond at all.

On the exemplary side, one vendor, Philips N.V., had an established protocol for handling incoming product vulnerabilities, which included using a documented PGP key to encrypt communications around this sensitive material. Philips was also able to involve upstream vendors in pursuing solutions to those technologies provided by others. Weaved, a provider of an

IoT-in-the-cloud framework for Philips, was especially open with and responsive to the authors of this paper.

The range of responses itself is worrying, and representative of the IoT industry as a whole. While it is possible for an organization to maintain a flexible, mature process for handling unsolicited vulnerability reports, it is far from the norm. It is hoped that the publication of these findings will help IoT vendors establish reasonable, effective vulnerability handling practices.

VULNERABILITY REPORTING AND HANDLING

06

| Rapid7.com Hacking IoT: A Case Study on Baby Monitor Exposures and Vulnerabilities 9

Vendor: iBaby Labs, Inc. The issues for the iBaby devices were disclosed to CERT under vulnerability note VU#745448.

Device: iBaby M6 The vendor’s product site for the device assessed is https://ibabylabs. com/ibaby-monitor-m6

Vulnerability R7-2015-11.1: Predictable public information leak (CVE-2015-2886)

The web site ibabycloud.com has a vulnerability by which any authenticated user to the ibabycloud.com service is able to view camera details for any other user, including video recording details, due to a direct object reference vulnerability.

The object ID parameter is eight hexadecimal characters, correspond- ing with the serial number for the device. This small object ID space enables a trivial enumeration attack, where attackers can quickly brute force the object IDs of all cameras.

Once an attacker is able to view an account’s details, broken links provide a filename that is intended to show available “alert” videos that the camera recorded. Using a generic AWS Cloud- Front endpoint found via sniffing iOS app functionality, this URL can have the harvested filename appended and data accessed from th

The post What is the Business Impact? 5 appeared first on superioressaypapers.

 

Looking for a Similar Assignment? Order now and Get 10% Discount! Use Coupon Code "Newclient"