Chat with us, powered by LiveChat ISOL534 Cumberlands Baby Monitor Exposures and Vulnerabilities Case Study Paper | All Paper

Read the attached article:Hacking IoT: Case Study on Baby Monitor Exposures and Vulnerabilities – Rapid7GUIDELINES FOR WRITING A CASE STUDYA case study analysis requires you to investigate a problem, examine the alternative solutions, and propose the most effective solution using supporting evidence. Your submission should be no more than 2 pages and needs to adhere to APA formatting for spacing and citations. Include a title page, your case study (1-2 pages), and reference page. For guidance on APA formatting check out this resource: the CaseBefore you begin writing, follow these guidelines to help you prepare and understand the case study:Read and examine the case thoroughlyTake notes, highlight relevant facts, underline key problems.Focus your analysisIdentify two to three key problemsWhy do they exist?How do they impact the information security field?Who is responsible for them?Uncover possible solutionsReview course readings, discussions, outside research, and your experience.Select the best solutionConsider strong supporting evidence, pros, and cons: is this solution realistic?Drafting the CaseOnce you have gathered the necessary information, a draft of your analysis should include these sections:IntroductionIdentify the key problems and issues in the case study.Formulate and include a thesis statement, summarizing the outcome of your analysis in 1–2 sentences.BackgroundSet the scene: background information, relevant facts, and the most important issues.AlternativesOutline possible alternatives (not necessarily all of them)Why are alternatives not possible at this time (if not possible)?Proposed SolutionProvide one specific and realistic solutionExplain why this solution was chosenSupport this solution with solid evidenceRecommendationsDetermine and discuss specific strategies for accomplishing the proposed solution.If applicable, recommend further action to resolve some of the issuesWhat should be done and who should do it?Finalizing the CaseAfter you have composed the first draft of your case study analysis, read through it to check for any gaps or inconsistencies in content or structure: Is your thesis statement clear and direct? Have you provided solid evidence? Is any component from the analysis missing?When you make the necessary revisions, proofread and edit your analysis before submitting the final draft.


Unformatted Attachment Preview

HACKING IoT: A Case Study
on Baby Monitor Exposures
and Vulnerabilities
Written by Mark Stanislav and Tod Beardsley | September 2015*
© Rapid7 2015
*Last updated September 29, 2015
HACKING IoT: A Case Study
on Baby Monitor Exposures
and Vulnerabilities
The Internet of Things
No Easy Fixes
Why Baby Monitors?
What is the Business Impact?
Common Vulnerabilities and Exposures for IoT Devices
Vulnerability Reporting and Handling
Working to Improve IoT Security
About Rapid7
Executive Summary
This is especially
relevant today,
as employees
increas­ingly blur
the lines between
home networks
and business
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 increasingly 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-20152889 (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 exploitable 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 personnel. 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.
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 general-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
The classic example of a manufacturer-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.
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
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.
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
Hacking IoT: A Case Study on Baby Monitor Exposures and Vulnerabilities
With traditional computers, we understand that access controls are required
in order to satisfy basic security requirements. 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
IoT devices, unlike traditional computers, 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 vulnerabilities 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 unsecurableafter-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, assembled, 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.
the supply chain, ultimately delaying
effective patching for the particular
device in which the vulnerability was
first discovered.
This patchwork of common components leads to confusing amalgamations
of interdependencies, and can leave
end-users exposed while the details of
remediating vulnerabilities are worked
out between vendors.
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-theshelf technologies is critical in keeping
costs of production low, it introduces an
ambiguity of ownership for developing
and deploying patches and other
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
Hacking IoT: A Case Study on Baby Monitor Exposures and Vulnerabilities
The research presented focuses on the
security of retail video baby monitors
for a number of reasons. Baby monitors 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 candidates 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.
Hacking IoT: A Case Study on Baby Monitor Exposures and Vulnerabilities
While video baby monitors are vastly
more commonplace in a home environment 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 workplace 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 computers 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
Hacking IoT: A Case Study on Baby Monitor Exposures and Vulnerabilities
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.
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
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 subcomponents 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
Hacking IoT: A Case Study on Baby Monitor Exposures and Vulnerabilities
Cleartext Local API
Remote Shell Access
UART Access
Devices built with commodity components 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.
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 developing and tinkering with hardware,
they should not be made available on
production systems where shell access
is never desired or required.
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 connection. 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.
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.
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.
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.
Predictable Information
iBaby M6
Local Net, Device
Backdoor Credentials
iBaby M3S
Local Net, Device
Backdoor Credentials
Philips In.Sight B120/37
Reflective, Stored XSS
Philips In.Sight B120/37
Direct Browsing
Philips In.Sight B120/37
Authentication Bypass
Summer Baby Zoom Wifi
Monitor & Internet Viewing
Privilege Escalation
Summer Baby Zoom Wifi
Monitor & Internet Viewing
Local Net, Device
Backdoor Credentials
Lens Peek-a-View
Local Net
Bac …
Purchase answer to see full