Beware of the App!

On the Vulnerability Surface of

Smart Devices through their Companion Apps
Davino Mauro Junior Luis Melo Harvey Lu Marcelo d’Amorim Atul Prakash
Federal University of Federal University of University of Federal University of University of
Pernambuco, Brazil Pernambuco, Brazil Michigan, USA Pernambuco, Brazil Michigan, USA
dmtsj@cin.ufpe.br lhsm@cin.ufpe.br harveylu@umich.edu damorim@cin.ufpe.br aprakashu@umich.edu

Abstract—Internet of Things (IoT) devices are becoming in- example, a white paper by Veracode describes vulnerabilities
arXiv:1901.10062v1 [cs.CR] 29 Jan 2019

creasingly important. These devices are often resource-limited, in 6 IoT devices, including SmartThings Hub, Wink Hub,
hindering rigorous enforcement of security policies. Assessing Wink Relay, and MyQ Garage, but not how to analyze such
the vulnerability of IoT devices is an important problem, but
analyzing their firmware is difficult for a variety of reasons, vulnerabilities in a systematic way. One solution would be
including requiring the purchase of devices. This paper finds that for a security analyst to inspect the firmware binary on the
analyzing companion apps to these devices for clues to security device, but that is often hard to access [8] and challenging to
vulnerabilities can be an effective strategy. Compared to device analyze [9].
hardware and firmware, these apps are easy to download and This paper proposes an indirect and simpler way of assessing
analyze. A key finding of this study is that the communication
between an IoT device and its app is often not properly encrypted the security of IoT devices by analyzing their companion apps
and authenticated and these issues enable the construction of and the interaction with the device’s firmware. Our intuition is
exploits to remotely control the devices. To confirm the vulnera- that if this interaction between the companion app and device
bilities found, we created exploits against five popular IoT devices firmware is not implemented with good security principles,
from Amazon by using a combination of static and dynamic the device’s firmware is potentially insecure and vulnerable
analyses. We also did a larger study, finding that analyzing 96
popular IoT devices only required analyzing 32 companion apps. to attacks. In our experience, most IoT devices on the market
Among the conservative findings, 50% of the apps corresponding today are released with companion apps for both Android and
to 38% of the devices did not use proper encryption techniques iOS so that users could control these devices directly from
to secure device to companion app communication. Finally, we their smartphone, thus permitting such analysis.
discuss defense strategies that developers can adapt to address Our hypothesis is that the analysis of these apps can throw
the lessons from our work.
Index Terms—Security; Internet of Things; Android Apps; substantial light on potential vulnerabilities in devices and
Companion Apps even help security analysts develop proof-of-concept exploits
to induce the device manufacturers to verify the vulnerabilities
I. I NTRODUCTION and fix them. To validate the hypothesis, we analyze multiple
1 smartphone apps to discover potential vulnerabilities and, from
The number of Internet of Things (IoT) devices worldwide
that, create proof-of-concept attacks that could allow either
is predicted to reach 20 billion by 2020 [1]. Designing
a local or remote attacker to completely compromise the
secure solutions in this domain is challenging as devices
device, including issuing arbitrary commands to them or update
are typically limited in resources. Consequently, security is
their firmware without ever touching the device physically.
a permanent concern. As a concrete example, in October
These apps play an important role in the secure operation of
2016, the Mirai malware compromised millions of IoT devices
smart devices. In particular, they are responsible for the initial
around the world and used them to launch the largest DDoS
device configuration, i.e., these apps set up the communication
attack ever recorded [2]. In the smart-home scenario, security
channel with the device with supposedly proper encryption
vulnerabilities in IoT devices could compromise safety at
and authentication. Because of this important role, IoT apps
home [3].
need to encode sensitive communication data, such as the
IoT devices are compatible with multiple cloud-based
type of encryption being used, and even encryption keys. This
software stacks (e.g., SmartApps in the SmartThings cloud [4],
information can be valuable for an attacker who wants to gain
Alexa Skills [5], etc.). Prior work has found security vulnerabil-
control of the device. Moreover, in contrast to physical devices,
ities introduced by some of these stacks [6], [7]. Unfortunately,
these apps are accessible to the general public through market
a gap remains in that the device may have vulnerabilities out-of-
places (e.g., Google Play). It is, therefore, a sweet spot for
the-box that are independent of security of high-level software
hackers to focus their efforts on.
stacks. Unfortunately, techniques for security analysis of device
In the security analysis of the smartphone apps, we par-
software itself remains an art and poorly understood. For
ticularly focus on the security of communication between an
1 We may refer to IoT devices as smart devices (or just devices) and the IoT device and its app. Any flaws could enable a range of
apps that control these devices as companion apps (or just app). attacks that can result in complete control of the IoT device.

1
We analyzed smartphone apps for 96 of top-selling WiFi
and Bluetooth-enabled devices on Amazon. There were 32
unique apps for these devices (e.g., devices were from the
same vendor and sometimes different vendors shared apps) and
then developed proof-of-concept attacks on 5 of the devices.
For example, we find that an Amazon top-seller smart plug
from TP-Link [10] shares the same hard-coded encryption
key for all the devices of a given product line and that the
initial configuration of the device is established through the app
without proper authentication. Using this information, we were
able to create a spoofing attack to gain control of this device2 . Figure 1: Example of IoT setup.
Note that this issue can be replicated in all other TP-Link
devices that use the same app.
II. C ONTEXT, G OAL , AND Q UESTIONS
This paper makes the following contributions:
A. Context
Empirical Study. We show the value of analyzing compan- Most manufacturers of IoT devices provide a smartphone
ion apps as a useful vulnerability analysis technique for devices application and cloud services to monitor and control their
by conducting two studies to assess the security of app-device devices. Communication between the device and its companion
communication by analyzing companion apps corresponding app is often established over the local network using some
to the device. These studies consider key security aspects in wireless protocol such as Zigbee and Z-Wave [11]. When
this context, namely, encryption, authentication, and network the device and the smartphone are in distinct networks or
protocols. The first study involved a detailed analysis of four the IoT setup does not support local network connectivity3 ,
different apps (for five devices, with two devices sharing an app) the cloud server acts as a proxy for communication. An IoT
and then creating concrete exploits. A second study analyzed app sends the message intended for a device to the cloud
32 apps for 96 devices to find extent of similar features that server and the cloud server relays the message to the device.
could potentially enable an exploit. Similarly, a message from a device can be relayed to the
IoT app through the cloud. Figure 1 illustrates an example
Efficiency. We found that we only had to analyze 4 apps setup with a router/hub and with the cloud. Setups without
for the 5 devices actually purchased and 32 apps for 96 one or both of these elements are possible. For example, it
devices overall. There was extensive sharing of apps among is possible that only local communication is allowed (i.e., no
devices. Thus, it can be significantly more efficient to analyze cloud) and that the app and the device communicate directly
companion apps as compared to device firmware. (i.e., through the router). Hubs are especially useful to enable
communication with resource-constrained devices that do not
Findings and Lessons. We found lack of encryption in 31% need to fully implement a network stack.
of the apps analyzed and use of hardcoded keys in 19% of all In this context, pairing is the process of establishing a
the apps—thus, at least 50% of the apps were potentially seri- communication channel between an app and a device. A
ously vulnerable to exploits (these apps corresponded to 37 out prevalent hypothesis made by users is that, once established,
of 96 devices considered). Many of these apps controlled their this channel is secure. The goal of this paper is to assess this
devices via local communication or via broadcast messages, hypothesis, i.e., this study evaluates whether the app-device
including UDP messages. Based on our in-depth analysis of channel is properly secured. To achieve this goal we analyze
4 of the apps, we found that leveraging these weaknesses to companion apps for vulnerabilities and then confirm them by
create actual exploits is not challenging. A remote attacker creating exploits. We make the following assumptions on these
simply has to find a way of getting the exploit either on the exploits:
user’s smartphone in the form of an unprivileged app or a • that an adversary has access to the local network;
script on the local network. We then discuss potential defense • that an adversary uses a rogue app or script to control the
strategies. device without user knowledge.
To illustrate a potential use case for such exploits, consider,
Spoofing Attacks. We provide detailed evidence of the for instance, the scenario of a burglar trying to break into
importance of our findings by building proof-of-concept attacks your smart home. The first step is to gain access to your WiFi
on randomly selected, from a list of popular IoT devices on network using some public technique [13]. The burglar does
Amazon, five IoT devices. We purchased these devices prior not need to succeed in all attempts. The next step is to detect
to the analysis. We were successful in creating attack apps (or
2 A video illustrating a counterfeit app in action can be found at https:
scripts) that could execute arbitrary commands on the device.
//figshare.com/s/d5bc439a7527df358f5f
The attacks were successful even if the device had previously 3 Tuya Smart [12] is an example framework where the companion app can
been paired with a legitimate app. only communicate with the device through the cloud.

2
periods of time when the house would be empty. For that, the Table I: CVE vulnerabilities in major IoT protocols.
burglar could monitor the network and find use-patterns to Protocol # Vulnerabilities Example
identify periods of occupation. Finally, the burglar would use
MQTT 13 CVE-2017-9868
a rogue app or script to control a door handle and invade the SIP 59 CVE-2018-0332
house. This scenario illustrates the importance of assessing UPnP 346 CVE-2016-6255
whether the IoT device is susceptible to adversaries leveraging SSDP 17 CVE-2017-5042
information obtained by analyzing the companion app.

B. Goal and Questions IoT deployments [15]. Using the Common Vulnerabilities and
The goal of this study is to assess whether the app-device Exposures (CVE) database [16], we find vulnerability reports
communication is secure. We assume this communication in four of these IoT protocols, namely, MQTT [17], SIP [18],
occurs through the local network; remote communication UPnP [19] and SSDP [20]. Table I shows the number of
through the cloud is out of the scope for this work. We also reported issues and the ID of an example issue. For instance,
assume that an adversary targeting the IoT device would use the UPnP vulnerability CVE-2016-6255 allows remote attackers
either a rogue app or script to control the device without user to write arbitrary files to the device file system [21]. Note that
knowledge. We propose a non-comprehensive list of questions UPnP is the protocol with the largest number of reported issues.
to determine the attack surface on the apps. These questions
are related to encryption, authentication, and communication, III. F INDING AND C ONFIRMING V ULNERABILITIES
which is where vulnerabilities typically manifest.
Q1) Is the key hardcoded? A malicious developer could This section presents details of how we carried out a
counterfeit messages if she has access to secret keys. Hard- vulnerability assessment by analyzing the companion apps and
coded keys are problematic as they are encoded literally in then confirming the assessment by crafting proof-of-concept
code. Intuitively, hardcoded keys could be mined by reverse- exploits for a selection of IoT devices. It describes the criterion
engineering the app, even when the code is obfuscated. For for selecting apps to analyze (III-A), discusses the analysis
example, if a crypto API is used, one could find the key by used to answer the questions posed on Sections II-B and III-B,
monitoring the actual parameters of crypto library functions, and describes each exploit in detail (III-C).
whose names cannot be obfuscated and whose intent can be
found from public documentation. In other cases, the developer A. App Selection Criterion
may have chosen to implement a custom crypto function, but
one could discover these functions by the ratio of mathematical To select apps for this part of our study, we examined the 96
instructions in the function body, as Caballero and colleagues top-selling WiFi and Bluetooth devices on the Amazon website
did [14], and then use a similar method to mine the key. by popularity. We then restricted the resulting set to devices
Q2) Does the app use local communication? When the from the categories smart plugs, bulbs, or IR controllers that
IoT app and the corresponding device are in the same use Wi-Fi—largely for affordability and form-factor reasons
network, local communication may be used. Unfortunately, and because Wi-Fi is popular and provides a potential attack
local communication protocols do not enforce the same security surface if an attacker can execute code anywhere on the same
guarantees compared to remote communication. For example, it network (e.g., via an app, malicious email, malicious device,
is uncommon to check identities with HTTPS/SSL certificates or downloaded executable code on a computer on the same
in local communication. In contrast, in the scenario where network). A total of 54 devices satisfied this criterion. From
local communication is forbidden (i.e., cloud relays messages these 54 devices, we randomly selected (and purchased) 5
to apps and devices), an attacker would have to make a bigger devices to run our analysis. Somewhat to our surprise, we
effort to forge HTTPS/SSL certificates of the parties involved. found that two of the devices we selected use the same app
Q3) Does the app send broadcast messages? Broadcast (as they belong to the same manufacturer). Consequently, this
messages are frequently used in IoT setups to discover devices section focuses on these four companion apps. For each of the
and to enable direct app-device communication when there apps, we did a detailed vulnerability analysis and then also
is no hub/gateway in the setup. Their use, unfortunately, can developed exploits.
put a smart home at risk. Adversaries can, for instance, sniff4
the response of devices to broadcast messages, which often B. Vulnerability Analysis
include sensitive data such as the internal state of the device.
Q4) Does the app use any well-known protocol with This section details the tools we used to determine app-device
vulnerabilities? Different protocols tailored to IoT deployments protocol features that could permit remote or local attacks on
exist and some of these protocols are known to be vulnerable the device. We analyzed each companion app with respect to
to attacks. According to Al-Fuqaha and colleagues, a total the questions from Section II-B. We then identified a potential
of seven application protocols are more frequently used in attack path in each app and confirmed the path by creating a
proof-of-concept exploit. We describe the methodology used
4 This ability to sniff WiFi messages depends on the distance to the router. to answer the questions and their use to find an exploit.

3
 1) Basic toolset functionality: We implemented a toolset device is done by inspecting the classes responsible for making
to help us do semi-automated analysis to answer the questions. network calls and looking for well-known broadcast addresses,
We found relying on just automated analysis to be error-prone. e.g., 255.255.255.255.
For example, one of our tools looked for use of constant keys Q4) Does the app use any well-known protocol with
in calls to encryption functions. But, we found that some of vulnerabilities? With the protocol discovery component, we
the calls were not used on the communication paths between can identify transport, network, and application layer protocols
the device and the app. Thus, for all of our analysis, we used on the app. After identifying these protocols, we look for
used the tools as an aid to manual analysis. We also used the documented vulnerabilities for each protocol in the Common
JADX decompiler library [22] as well as some static analysis Vulnerabilities and Exposures (CVE) database [16].
tools [23]. Results. Table II shows the answer to these questions for the
Encryption Discovery. The encryption discovery component four selected apps. For each question, we used the labels yes
looks for functions in the app that likely encrypt and decrypt or no to indicate a positive answer or a negative answer, and
the data exchanged with the smart device. Those functions are no encryption for the first question when the app uses no
the first line of attack for adversaries [24]. With those functions, encryption. The label yes indicate good practice whereas the
one could, for example, eavesdrop on official communication labels no and no encryption indicates a potential vulnerability
and infer the layout of messages and gain access to sensitive or an interesting attack surface for a potential exploit.
data. The toolset uses two complementary heuristics to discover All four apps are found to use local communication with
these encryption functions. The first heuristic applies to the the device and three of the apps also using broadcast commu-
case where developers use existing Java encryption APIs. The nication, providing us with a potential attack surface to exploit
second heuristic covers the case where developers implement the devices. Three out of four apps do not use any encryption
custom crypto functions instead of building on existing ones. to secure their communication with the device, providing us
The toolset detects these functions by computing, for every with a compelling attack vector. Only one of the selected apps
function declared in the app, the ratio between the number (WeMo) uses an insecure version of a protocol. But WeMo
of arithmetic and bitwise operations over the total number of also does not use any encryption, thus providing a simpler
instructions. This heuristic has been previously used in prior attack vector to exploit the device.
work [14], [25], [26]. 3) Finding Vulnerable Paths: After answering the posed
Network Protocol Discovery. This component extracts infor- questions, we proceed to locate vulnerable paths in the given
mation about the communication protocol used between the app. We define a vulnerable path to be a sequence of function
smart device and the companion app. More precisely, it looks calls that connect a source (e.g., a function that is called from
for calls to functions (in the app) from classes related to known external input such as the user interface (UI)) to a sink (e.g., a
communication protocols. For example, for UDP, it looks for network method call) that an exploit may wish to compromise.
calls to functions from java.net.DatagramSocket and, for Analyzing the classes and functions in this path involved in the
TCP, it looks for calls to functions from java.net.Socket. preparation of a message to a sink helps the security analyst
This component reports a mapping from classes in the app generate an abstraction of the application behavior, an important
to communication protocols (e.g., TCP, UDP, HTTP, UPnP). step to creating an exploit.
Note that there is no fundamental limitation that prevents our
infrastructure supporting other languages and protocols. UI

2) Answering the questions: We describe below the methodo- call

c.a()
logy we used to answer each of the questions from Section II-B
and then elaborate results.
Q1) Is the key hardcoded? The search for hardcoded keys AbsSmartDevice.invoke()
initiates from the output of the encryption discovery component,
which reports function likely related to encryption. When using
standard encryption libraries, we are able to automate the search Encryption

for secret keys by looking for javax.crypto.SecretKey, call TPUDPClient.a() ... Network
call
which is the class denoting a key in the Java standard API. For
custom encryption, however, we manually inspect each method
returned by the encryption discovery, checking if the key is TPClientUtils.encode() UDPClient.b() Datagram.send()
present inside the method body or in usages of the method.
Q2) Does the app use local communication? The protocol Figure 2: Path (simplified) from UI function to a network call.
discovery component acts as guidance for the manual analysis.
Based on the function calls and protocol report, we manually Figure 2 illustrates a vulnerable path for the Kasa app. To
analyze the classes responsible for network calls and identify find this vulnerable path, we start by analyzing the output of
whether the app uses local communication. our toolset, i.e., classes and functions related to encryption,
Q3) Does the app send broadcast messages? Identifying authentication and network protocols. These elements are
whether broadcast messages are sent from the app to the smart potential sources of vulnerabilities. Considering the Kasa app,

4
 Table II: Potential Threats to Selected Apps.

App Avoid Hardcoded Avoid Local Avoid Broadcast Safe

Keys? Communication? Messages? Protocol?
Kasa for Mobile no no no yes
LIFX no encryption no no yes
WeMo no encryption no yes no
e-Control no encryption no no yes

for example, we start by inspecting the classes containing 1 public static byte[] encode(byte[] data) {
usages of the UDP protocol (related to Q3). We discover that the 2 byte seed = (byte) -85;
3 for (int i = 0; i < data.length; i++) {
UDPClient class declares the network-related method b, which 4 data[i] = (byte) (data[i] ^ seed);
calls datagramPacket.send(), a method from the standard 5 seed = data[i];
6 }
Java API to send UDP packets. As the method b includes a net- 7 return data;
work call, it could be flagged as a sink. Our analysis shows that 8 }

this class contains usages of broadcast addresses, representing Listing 1: TP-Link Kasa encryption function.
a potential attack surface. Then, we analyze backward the call
chain leading to this function looking for a UI method. While
doing it, we find another method present in the output of our
toolset (related to Q1), TPClientUtils.encode, contains Q1) Is the key hardcoded? The Kasa app uses a custom
hardcoded keys that could also be exploited. We also identify encryption function, Caesar cipher [31], that is known to be
the function TPUDPCLient.a, responsible for building the easy to break. Listing 1 shows this function as it appears in
UDP packet. This function, while not showing a vulnerability the app. Line 2 shows the hardcoded seed to encrypt the data.
by itself, is responsible for building the UDP packet to be sent Identifying the encryption function and its hardcoded seed gave
and reveals the structure of the message. Finally, we discover us hope of replicating the function in a rogue app on the same
the calls to the UI obfuscated method c.a, which is the starting network to control the device arbitrarily.
point of this path. That is possible because of the programming Q2) Does the app use local communication? By using the
conventions of Android. More specifically, class c declares network discovery component and manually inspecting the
several (button-related) event callback methods. code, we identified classes containing calls to UDP-related
methods. After inspecting these classes, we confirmed that
C. Exploits these methods are involved in the discovery and control of the
Based on the vulnerable paths found, we created exploits TP-Link devices on the local network. For instance, Listing 2
for each selected app. In the following, we describe in detail exhibits the function that discovers TP-Link devices in the
the steps we took to create each exploit. Although this work local network.
does not assume that an adversary would have physical access 1 public static final String UDP_ADDRESS="255.255.255.255";
to the device, we used physical devices in this experiment 2 public void discoverLocal() {
3 String requestId = DiscoveryUtils.a();
to demonstrate our findings. The assumption we made on 4 tpDiscovery.broadcastDiscovery(...,UDP_ADDRESS,...);
the adversary is that she understands Java and she is able to 5 ...
6 }
reverse engineer the Android application files (.apks). Also,
when cryptographic functions and keys are encountered, we do Listing 2: TP-Link Kasa function (simplified) used to
not assume the adversary has enough computational power to discover devices on the local network.
break the key by brute force. We believe that these assumptions
are similar to what a real-world attacker would deal with and Q3) Does the app send broadcast messages? During our
similar to the assumptions made in other studies [27], [28]. analysis, we found the Kasa app uses broadcast messages to
1) Finding an exploit for Kasa for Mobile: TP-Link Kasa is discover and control the TP-Link devices. Line 1 from Listing 2
the official app for controlling TP-Link-manufactured devices declares a constant variable holding a well-known broadcast
from the smart home product line Kasa [29]. The exploit we IPv4 address. This variable is then used in Line 4 to discover
created consists of a rogue app that mimics the official TP-Link TP-Link devices on the network.
app and takes control of a TP-Link smart plug. It is worth Q4) Does the app use any well-known protocol with
noting that in principle, this app could run as code anywhere on vulnerabilities? Our analysis did not find usage of protocols
the same network, e.g., running as a script instead of app. At with documented vulnerabilities.
the time of this writing, TP-Link’s smart plug was a top-seller To confirm the vulnerabilities, we designed a proof-of-
with over 12.000 customer reviews on the Amazon website [30] concept exploit. The exploit consists of a rogue app on the
showing an average rating of 4.4 out of 5 stars. We give an same network. We use both static analysis (i.e., inspection of
analysis of its companion app below. the decompiled code) and dynamic analysis (i.e., inspection

5
of the network traffic). The list below shows the keys steps to The proof-of-concept exploit we developed is a script that takes
create the exploit. control of a light bulb. To develop the script, we first started
1) find a vulnerable path and encryption function; with finding answers to the four questions in Section II-B.
2) discover the structure of exchanged messages; Q1) Is the key hardcoded? We found that no encryption or
3) discover what protocol is used to exchange messages; authentication is used in the LIFX app.
4) implement pairing. Q2) Does the app use local communication? The LIFX app
uses UDP to communicate with the smart lights. As in the Kasa
From one vulnerable path for the Kasa app (see Sec-
case, we used the output of the protocol discovery component
tion III-B3), we obtain access to the app’s encryption function
to find that.
(step 1). With that function at hand, it is possible to monitor
Q3) Does the app send broadcast messages? The app uses
the network traffic and read the contents of messages as to
broadcast messages. Listing 3 shows the class responsible
understand their structure (step 2) and the IP addresses used
for sending these messages. Lines 5 and 6 refer to a fixed
(step 3), which are critical for replication. Recall that the Caesar
broadcast address. We also found that the broadcast IP address
cipher [31] is a symmetric (/invertible) encryption function. In
was identical to that present in the Kasa app. During our
that case, we found that only broadcasting was used through
analysis of the apps (discussed in Section IV), we noticed that
a single address. Finally, it is necessary to replicate pairing
this broadcast address is commonly used in an IoT setup, as
(step 4). To our surprise, we found by inspection that a pairing
it represents a special broadcast address that is used when a
process was not needed to control the device. Pairing was used
device needs to send a broadcast packet to the network without
to maintain the profile of users on TP-Link devices, but not
caring about a recipient’s address.
for its control.
Monitoring the Network. We used the popular traffic analyzer 12 public final class UdpTransport ... { ...
static {
Wireshark [32] to monitor the packets exchanged between 3 Object bn = InetAddress.getByName("255.255.255.255");
Intrinsics.a(bn,...);
the Kasa app and the device. As the traffic was encrypted 45 ...
we needed to implement a script to decrypt the monitored 6 }
messages; the script uses the symmetric cipher function from 78 } ...
Listing 1. This monitoring tool was used in two important
stages: (i) during the app-device pairing process and (ii) Listing 3: Function (simplified) used by the LIFX app
while the app interacted with the device, e.g., turning the showing usage of a broadcast address.
plug “on” and “off”. During the pairing process, we found
that broadcast messages were exchanged while the app was Q4) Does the app use any well-known protocol with
connected to the hotspot created by the device. We also vulnerabilities? During our analysis, we did not find any usages
monitored the network when interacting with the device through of protocols with known vulnerabilities in the LIFX app.
the app’s UI. Specifically, we repeated the “Turn Off” and
“Turn On” operation multiple times, observing that the contents UI

of the network packets did not change, validating the use call
ColorController.setPowerState()
of a hardcoded key with a poor encryption method. We
also observed the use of broadcast messages during device
usage after pairing. We found that the app uses the following
Intrinsics.b()
message to discover and obtain the current status of the device– Network
call
{"system":{"get_sysinfo": }{}}. We also found that
"{"system":{"set_relay_state":{"state":0}}} was
the message for turning the device off. Datagram.send() UdpTransport.accept() ...
Based on the analysis, we created a rogue app to control a
TP-Link smart plug device. Static analysis played an important Figure 3: Path (simplified) from UI function to a network call.
role to find vulnerable paths in the app whereas dynamic The path includes no encryption function.
analysis helped in understanding the communication protocol
and the messages exchanged. Recall that, during our analysis, The LIFX exploit consists of a script that sends UDP
we noticed that the pairing process was not needed to control broadcast messages to control the device. Similarly to the
the device. This is a severe flaw as the user would not even be Kasa exploit, we used static analysis to find a vulnerable
aware of an attack—the official app would still work as intended attack vector for the app. For that, we inspected the code
even with a rogue app controlling the device simultaneously. and discovered the UdpTransport class, responsible for
A video demonstrating the exploit is available from the link5 . creating and sending the UDP messages (related the Q2).
2) Exploiting LIFX: LIFX [33] controls smart lights manu- While inspecting this class, we found that broadcast UDP
factured by LIFX, a company specialized in smart lights [34]. messages were sent through the UdpTransport.accept
method (related to Q3). Then, we analyzed the call chain
5 Kasa exploit: https://figshare.com/s/d5bc439a7527df358f5f backwards leading to the UI function responsible for controlling

6
the state of the smart light, i.e., turning it “on” and “off”– 3) Exploiting WeMo: WeMo is the official app to control
ColorController.setPowerState, the starting point of Belkin devices from the product line WeMo [35], focusing
this path. Figure 3 shows this path. on a variety of IoT devices in the smart home segment. The
By monitoring the network while using the LIFX app to proof-of-concept exploit we developed is a script that arbitrarily
turn the lights “on” and “off”, we confirmed that broadcast controls a smart plug. As with earlier apps, we started our
messages were exchanged during communication between the analysis by answering the four questions from Section II-B.
app and the device. Then, we proceeded to inspect the code Q1) Is the key hardcoded? The WeMo app uses no encryption
and find the structure of the messages. We started from the or authentication in communication with the device.
network call from Figure 3, whose code is depicted in Listing 4. Q2) Does the app use local communication? The WeMo app
It is worth noting that contrary to the Kasa app, which used a uses the Universal Plug-and-Play (UPnP) protocol to handle
JSON structure for the message, we could not infer the layout both device and service discovery on the local network, with
of the message by monitoring the network only, as the message UDP acting as the underlying network protocol.
was in a byte array format. Q3) Does the app send broadcast messages? Using UPnP
implies that the SSDP protocol is used on the app. As the
1 class UdpTransport ... { ...
2 void accept(TargetedMessage targetedMsg) { SSDP protocol operates with a specific multicast address–
3 Message msg = targetedMsg.getMessage(); 239.255.255.250– broadcast messages are not used.
4 byte[] ba = msg.toData();
5 datagramSocket.send(ba); Q4) Does the app use any well-known protocol with
6 } vulnerabilities? We found that the app uses the UPnP protocol.
7 ...
8 } Although simple by design, this protocol is known to be
vulnerable. In 2013, a security company discovered that over
Listing 4: Code used by the LIFX app to construct an UDP
80 million devices were susceptible to a UPnP vulnerability
message.
caused by excessive privilege in the network interface of those
devices [36]. They found that this vulnerability was actively
We then inspected the parameter(s) of this method,
being used in distributed denial-of-service (DDoS) attacks.
TargetedMessage, highlighted in Line 2. We found that the
array of bytes encapsulated on TargetedMessage objects is The WeMo exploit consists of a script that searches for
partly constructed within classes encoding different operations. a Belkin smart plug on the network and sends commands
For example, the class SetPower creates a message to modify for controlling it. To find an attack path, we followed a
the light power whereas the class SetColor creates a message different approach from previous exploits. As no encryption
to modify the light color. For illustration, Listing 5 shows was present, we first monitored the network to identify the
a fragment of the class SetPower. The layout of messages structure of the unencrypted messages. Then, by analyzing the
can be inferred from the method put. (The construction of code responsible for producing the message, we gathered the
the message header is omitted for brevity.) The sequence of necessary information to build the script.
invocations to method ByteBuffer.put* reflects the order After identifying that the app uses the UPnP protocol, we
of fields in the corresponding message. From that, we were first tried to locate classes containing UPnP service names
able to replicate the message layout in our script. We used the exposed by the devices (related to Q2). These names identify
same rationale to find the layout for other kinds of messages. the universal device name (udn) [37]. By design, they must
start with the prefix “urn:”. We found that the WeMoDevice
1 class SetPower ... { ...
2 final int SIZE = 6; long duration; int level; class contained the names of all services related to the Belkin
3 void put(ByteBuffer byteBuffer) { IoT devices, as seen in Listing 6. This is important as these
4 byteBuffer.putShort(this.level);
5 byteBuffer.putInt(this.duration); names are part of the request sent to the device.
6 }
7 ... 1 public class WeMoDevice { ...
8 } 2 AIR_PURIFIER = "urn:Belkin:device:AirPurifier:1";
3 LIGHT_SWITCH = "urn:Belkin:device:lightswitch:1";
Listing 5: Structure of messages used to turn LIFX devices 4 SWITCH = "urn:Belkin:device:controllee:1";
5 public void setState(String state) {
on and off. 6 this.mState = state;
7 }
8 ...
To summarize, we created a proof-of-concept exploit script 9 }
to arbitrarily control LIFX smart lights. Similar to the Kasa
exploit described in Section III-C1, we used static analysis Listing 6: Service names of WeMo devices complete list
to find a vulnerable path and dynamic analysis to understand was hidden for brevity.
the communication protocol between the LIFX app and the We then monitored the network while interacting with the
smart light. To our surprise, we found that the app did not WeMo app. By monitoring the packets exchanged and analyzing
implement pairing or encryption. Consequently, our script sends the response, we observed that the app specifies a function—
unecrypted commands to change the state of the smart light, SetBinaryState—to change the state of the device and
e.g., turning it “on” and “off” and to change the color and another function—GetBinaryState—to obtain the state of
saturation of the light. the device. Listing 7 shows the response of the WeMo plug

7
while using the app. The response is a SOAP envelope—the known vulnerabilities in the app.
type of message used in the SSDP protocol. The e-Control exploit we developed consists of a script
that can send arbitrary commands to a Broadlink IR remote
1 <s:Envelope ...>
2 <s:Body> controller. To create the script, we used the same methodology
3 <u:GetBinaryStateResponse ...> as the LIFX exploit, using static analysis to find a vulnerable
4 <BinaryState>1</BinaryState>
5 </u:GetBinaryStateResponse> path in the app. First, we inspected the code looking for usages
6 </s:Body> of the UDP protocol, where we found the obfuscated method
7 </s:Envelope>
a of the class PutInDataUnit, responsible for sending the
Listing 7: WeMo simplified response to query the current UDP packet to the broadcast message (related to Q2 and Q3).
device state. We then analyzed usages of this method. We discovered that
after scanning for devices on the local network, the function
While inspecting the code looking for the method b of the same class was responsible for parsing the device’s
SetBinaryState, present in the WeMo response, we found response (structured as a JSON message). Listing 9 shows the
the class DeviceListManager that receives as parameters class with both methods. We then analyzed backwards the call
the state and udn of the device and calls the function chain involving this class and found the UI call, representing
makeStateChangeRequest. Listing 8 shows a fragment of the start of the vulnerable path. We choose not to show the
class DeviceListManager. We then analyzed backwards the graph illustrating the vulnerable path for brevity reasons.
call chain from method makeStateChangeRequest leading
1 public class PutInDataUnit {
to the UI function responsible to turn the smart plug “on”.. 2 private Void a() { ...
The final vulnerable path was hidden for brevity. 3 e = new DatagramSocket();
4 e.send(new DatagramPacket(...,"255.255.255.255"));
1 public class DeviceListManager ... { ... 5 ...
2 void setBinaryState(String state, String udn) { ... 6 }
7
3 DeviceInformation device = getDeviceUDN(udn,...);
4 makeStateChangeRequest(udn, device.getMAC(),...); 8 private Void b(String... strArr) { ...
5 } 9 JSONObject jSONObject = jSONArray.getJSONObject(i);
6 ... 10 ManageDevice device = new ManageDevice();
7 } 11 device.setDeviceName(jSONObject.getString(a.d));
12 ...
13 }
Listing 8: Class (simplified) responsible for sending the 14 }
command to change the state of a WeMo device.
Listing 9: Class (simplified) responsible for sending an UDP
To summarize, we successfully created a proof-of-concept message through the network.
exploit that discovers WeMo devices compatible with the
SSDP protocol located on the local network and then can To discover the structure of the messages, we monitored the
execute arbitrary commands on them. We found that the app network while interacting with the e-Control app. By inspecting
uses the UPnP protocol with well documented vulnerabilities the JSON messages exchanged, we confirmed the structure
(see Table I), but we did not end up needing to use those of the message found during our static analysis. We then
vulnerabilities in the exploit since the devices also have other replicated this structure to control the device. It is worth noting
vulnerabilities such as not using encryption. that although we found the functions related to the pairing
process while inspecting the code, we did not need to replicate
4) Exploiting e-Control: e-Control is the app [38] responsi-
them on our script. A Broadlink device can be controlled
ble for controlling all devices from Broadlink—a company
independently of a previous successful pairing and without
specialized in smart home devices and universal remote
alerting the user. This is a severe flaw.
controllers. Our exploit was implemented as a script that can
arbitrarily control a Broadlink InfraRed (IR) remote controller. D. Vulnerability Disclosure
Similar to previous exploits, we start by answering the questions As of the publication deadline of this paper, we have notified
of Section II-B. all manufacturers of the vulnerabilities. During disclosure, we
Q1) Is the key hardcoded? We did not find use of encryption also included scripts showing how to control the device without
or authentication in the app. the official IoT app and possible approaches to mitigate the
Q2) Does the app use local communication? With our issues we found. None of them have sent any response to our
protocol discovery component, we found that the e-Control disclosures and to the best of our knowledge, have not released
app uses the QUIC UDP protocol to communicate locally with patches relative to these vulnerabilities.
Broadlink devices.
Q3) Does the app send broadcast messages? We found E. Threats to Validity and Limitations
usage of a global broadcast address (similar to the Kasa app), The main threats to the validity of this study are the
implying the use of broadcast messages. The obfuscated method following. External Validity: We ran this study against five
at Line 2 of Listing 9 shows this usage. devices, associated with four different apps. Although we
Q4) Does the app use any well-known protocol with analyzed more apps (see Section IV), we only purchased
vulnerabilities? We did not find usage of protocols with well- these devices. As usual, the results may not generalize to

8
other devices. To reduce bias, we selected smart home devices cloud service has access to the commands sent to the device.
according to a well-defined criterion based on popularity in Consequently, a potential long-range security risk exists if the
the Amazon website. It is worth noting that the characteristics cloud service is ever compromised, a non-negligible risk [39].
of the apps that control the devices we purchased are similar We observe that 18 apps communicate locally with their
to the ones we analyzed but not purchased. corresponding device(s) and that 16 apps use broadcasting.
Internal Validity: Our results could be influenced by uninten- Note that a negative answer to a question does not imply an
tional mistakes during human inspection. For example, we exploitable vulnerability. Further inspection is necessary to
could have missed an important vulnerable path in an app. understand the issue. For example, although the app “August
As for limitations, our infrastructure and methodology do Home” uses local communication, that happens only through
not account for the possibility of apps making Java Native Bluetooth, which may restrict an attacker to be in close
Interface (JNI) calls. In this study, none of the apps calls proximity to the device, limiting the attack surface. The app
native functions through JNI. In a complementary study (see “Ring—Always Home” also does not appear problematic. After
Section IV), however, we found that some apps make JNI closer inspection, we find that the use of SIP, a protocol known
calls. They use JNI, for example, to implement encryption. As to be insecure (see Table I) is due to one specific feature of
expected, reverse-engineering native code is more challenging. the app, Voice over IP (VoIP). However, this feature can be
disabled and, if enabled, it is isolated from other parts of the
IV. D ISCUSSION app (with no apparent flows in between).
This section describes findings from a larger set of apps
compared to the one used in Section III that enabled us to V. D EFENSE S TRATEGIES
construct exploits. In this case, we did not not purchase devices,
so these findings are indicative of the potential extent of Our analysis suggests that developers of software for IoT
vulnerabilities. IoT devices included cameras, locks, and alarms, devices find it non-trivial to do proper key management. 50%
suggesting a significant safety issue if the vulnerabilities we of the apps either used hardcoded keys or did not do encryption.
found were exploitable. We consider companion app analysis to Some apps though did not use hardcoded keys and it is
be a valuable tool for discovering potential vulnerabilities prior instructive to see how they secured app-device communication.
to making purchases of large or expensive smart appliances We have not found use of a hardcoded key or of local
or where human safety could be an issue. Our analysis is communication in Nest thermostat’s companion app. The Nest
conservative with respect to potential vulnerabilities. We only thermostat provides a UI interface that provides a display and
present a negative result if we can confirm it in code. For also entry of data (by rotating a ring around the thermostat).
example, by analyzing the eWeLink app, which uses native A user can use that interface that to select a WiFi network
code, our analysis was not helpful in analyzing the app for and enter the WiFi password. That allows the device to talk to
hardcoded keys and, to be conservative, we counted the app the Nest cloud service securely over SSL. The companion app
as not having vulnerabilities to hardcoded keys. does not talk directly to the device; instead, the user creates
For this experiment, we start with the top-100 smart hubless a free account on the Next cloud service and then signs into
devices on the Amazon website by popularity and then restrict that using the companion app over SSL. Then, the user adds
the resulting set to devices that use WiFi and Bluetooth the thermostat to his account by entering a random code that
for communication. We find 96 such devices, including the is displayed on the thermostat’s interface. The user that way
5 devices that we previously purchased and analyzed in is assured that the correct thermostat is being added to the
Section III. These 96 devices only correspond to 32 companion account. Furthermore, the thermostat and the cloud service can
apps, saving us significant analysis effort compared to analysis also mutually authenticate each other and establish a shared
of devices themselves. secure link. No shared keys between the companion app and the
Figure 4 shows the distribution of answers to the questions thermostat are required since, from then on, the communication
for the analyzed apps as pie charts. To answer these questions between the companion app and the thermostat happens over
we used the same methodology described in Section III. SSL links to the cloud service.
Considering these questions, we find 31% of the apps to not The EZVIZ uses a different strategy. Unlike Nest, it supports
use any encryption at all and 19% to use hardcoded keys, local communication between the companion app and the
strongly suggesting that at least 50% of the apps are potentially device over the local network. The shared encryption key
exploitable with further protocol analysis. These correspond to is enclosed in the box in the form of a QR code and must be
37 out of 96 devices, i.e., 38% of the devices. scanned by the companion app. This strategy is better than
Out of the 32 apps analyzed, we found 4 apps to use encryp- hardcoded keys provided the key in the QR code is of sufficient
tion without hardcoded keys, not use local communication, not length, random, and strong crypto library is used.
use broadcasts, and not use known insecure protocols. All their Certain strategies are not recommended. We found several
communication was via the cloud service, likely over SSL. apps rely on native code. In our current analysis, we did not
The four apps include the popular Nest app. With respect to analyze native code and thus could have missed some uses
attacks considered in this paper, this is a relatively secure way of hardcoded keys. But, it is certainly possible to analyze
to communicate. But it does have a privacy tradeoff in that the binary code using tools such as Ida Pro [40] and extract

9
 No Encryption (10/32) Local Communication (18/32)
44%
31% Hardcoded Keys (6/32) Avoids Local Communication (14/32)
50%
No Hardcoded Keys (16/32) 56%
19%

(a) Apps regarding encryption.

(b) Apps regarding local communication.

Broadcast Messages (15/32) Insecure Protocols (6/32)

54% 82%
Avoids Broadcast Messages (17/32) Secure Protocols (26/32)
46% 18%

(c) Apps regarding broadcast messages. (d) Apps regarding secure protocols.
Figure 4: Distributions of different features for the set of analyzed apps.

potential constants, including keys. Similarly, code obfuscation, involving non-use of cryptography, lack of enforcement of
is unlikely to be an adequate defense. strong passwords, and incorrect TLS certificate validation [47].
VI. R ELATED W ORK The white paper mentions that the team used network moni-
toring and reverse engineering techniques, but did not discuss
In this section, we review some of the previous studies on details of what was reverse-engineered (e.g., device firmware,
security in a smart home context. apps, or cloud services) or how. Our work differs in that it
Denning et al. [3] presented potential security attacks against focuses on a different set of vulnerabilities (e.g., many of the
smart home devices, pointing that common attacks to traditional apps we analyzed in 2018 use cryptography, but with hard-
computing platforms, like denial-of-service and eavesdropping coded keys) and we present details of analysis of companion
on network could also be used in a smart home context. apps to show how such vulnerabilities can be discovered.
Komninos et al. [41] presented a survey about smart home
security, pointing different usage scenarios and categorizing
threats into network domain (such as eavesdroping, traffic
analysis and replay attack) and smart home introduced concept VII. C ONCLUSIONS
(such as device impersonation, update and illegal software).
Focusing on IoT platforms, Fernandes et al. [6] analyzed
over 499 apps on SmartThings and found out that 55% of Securing communication between IoT devices and the mobile
those are over-privileged largely due to design flaws in the apps responsible for controlling them is crucial for security and
privilege model of the platform. The authors also demonstrated even safety, depending on the types of IoT devices on a network.
how to take advantage of this with four proof-of-concept Unfortunately, analysis of device firmware is usually non-
attacks, both remotely and locally. Jia et al. proposed a context- trivial. In this study, we showed that analyzing the smartphone
based permission system for appified IoT platforms with fine- companion apps that are released for the device can provide
grained context identification and runtime prompts [42]. Other important clues for potential vulnerabilities in the devices. By
works [43], [44] focus on program analysis techniques used analyzing the companion app code, we assessed whether the
on IoT platforms. Most of these works analyze apps written communication between five best-selling IoT devices and their
in platform-dependent and restricted languages whereas we companion apps occurs over a secure channel. We found that
analyze companion apps in the larger Android platform. was not the case. We were successful in creating exploits for all
Android apps have been analyzed for a variety of security- five devices and able to control them, leveraging information
related issues, such as cryptographic misuse [24], [23], [45] that we gathered while analyzing the companion apps, both
and memory corruption [46]. For example, Egele et al. [24] statically, through program analysis, and dynamically, through
analyzed the violation of six rules including the use of ECB monitoring the network. We also extended our study to 28
mode and constant keys/IVs/seeds. Wei et al. [23] designed a additional apps. We found that 31% of the apps do not use
static analysis tool for security vetting of Android apps and any crypto to protect the device-app communication and that
used it to detect the use of the weak ECB mode for encryption; 19% use hardcoded keys. A significant fraction of the apps
the analysis is intra-procedural and thus limited in scope. (40–60%) also use local communication or local broadcast
In 2015, the Veracode team published a white paper on communication, thus providing an attack path to exploit lack
security analysis of six IoT devices to examine vulnerabilities of crypto or use of hardcoded encryption keys.

10
 R EFERENCES [25] Z. Wang, X. Jiang, W. Cui, X. Wang, and M. Grace, “Reformat:
Automatic reverse engineering of encrypted messages,” in Computer
[1] G. Group, “Gartner says 8.4 billion connected "things" will be in Security – ESORICS 2009, M. Backes and P. Ning, Eds. Berlin,
use in 2017, up 31 percent from 2016,” 2016. [Online]. Available: Heidelberg: Springer Berlin Heidelberg, 2009.
https://www.gartner.com/newsroom/id/3598917 [26] J. Chen, W. Diao, Q. Zhao, C. Zuo, Z. Lin, X. Wang, W. C. L. M.
[2] I. for Critical Infrastructure Technology (ICIT), “Rise of Sun, R. Yang, and K. Zhang, “IoTFUZZER: discovering memory
the Machines,” http://icitech.org/wp-content/uploads/2016/12/ corruptions in iot through app-based fuzzing,” in 25th Annual Network
ICIT-Brief-Rise-of-the-Machines.pdf, 2017, james Scott and Drew and Distributed System Security Symposium, NDSS 2018, San Diego,
Spaniel. California, USA, February 18 - 21, 2017, 2018.
[3] T. Denning, T. Kohno, and H. M. Levy, “Computer security and the [27] S. Checkoway, D. McCoy, B. Kantor, D. Anderson, H. Shacham,
modern home,” Commun. ACM, vol. 56, no. 1, pp. 94–103, Jan. 2013. S. Savage, K. Koscher, A. Czeskis, F. Roesner, and T. Kohno,
[Online]. Available: http://doi.acm.org/10.1145/2398356.2398377 “Comprehensive experimental analyses of automotive attack surfaces,” in
[4] Samsung, “Smartthings website.” [Online]. Available: https://www. Proceedings of the 20th USENIX Conference on Security, ser. SEC’11.
smartthings.com/ Berkeley, CA, USA: USENIX Association, 2011, pp. 6–6. [Online].
[5] Amazon, “Echo & alexa.” [Online]. Available: https://www.amazon.com/ Available: http://dl.acm.org/citation.cfm?id=2028067.2028073
Amazon-Echo-And-Alexa-Devices/b?ie=UTF8&node=9818047011 [28] B. Reaves, J. Bowers, N. Scaife, A. Bates, A. Bhartiya, P. Traynor,
[6] E. Fernandes, J. Jung, and A. Prakash, “Security analysis of emerging and K. R. B. Butler, “Mo(bile) money, mo(bile) problems: Analysis
smart home applications,” in 2016 IEEE Symposium on Security and of branchless banking applications,” ACM Trans. Priv. Secur.,
Privacy (SP), May 2016, pp. 636–654. vol. 20, no. 3, pp. 11:1–11:31, Aug. 2017. [Online]. Available:
[7] X. Lei, G. Tu, A. X. Liu, C. Li, and T. Xie, “The insecurity http://doi.acm.org/10.1145/3092368
of home digital voice assistants - amazon alexa as a case [29] TP-Link, “Kasa smart home products.” [Online]. Available: https:
study,” CoRR, vol. abs/1712.03327, 2017. [Online]. Available: //www.tp-link.com/us/kasa-smart/kasa.html
http://arxiv.org/abs/1712.03327 [30] “Kasa smart wi-fi plug by tp-link - control your devices from anywhere,
[8] D. D. Chen, M. Woo, D. Brumley, and M. Egele, “Towards automated no hub required, works with alexa and google assistant (hs100).” [Online].
dynamic analysis for linux-based embedded firmware,” in 23rd Annual Available: https://www.amazon.com/Kasa-Smart-Wi-Fi-Plug-TP-Link/
Network and Distributed System Security Symposium, NDSS 2016, San dp/B0178IC734?keywords=tp-link&qid=1539182867&sr=8-7&ref=sr_
Diego, California, USA, February 21-24, 2016, 2016. [Online]. Available: 1_7#customerReviews
http://wp.internetsociety.org/ndss/wp-content/uploads/sites/25/2017/09/ [31] W. Chapman, “Caesar cipher.” [Online]. Available: https://courses.
towards-automated-dynamic-analysis-linux-based-embedded-firmware. physics.illinois.edu/cs125/su2017/mp3_caesarcipher.php
pdf [32] W. Foundation, “Wireshark website.” [Online]. Available: https:
[9] “Carnegie Mellon University Binary Analysis Platform (CMU BAP),” //www.wireshark.org
https://github.com/BinaryAnalysisPlatform/bap, Carnegie Mellon, 2018. [33] L. L. Inc., “Lifx,” 2018, online; accessed 09-October-2018. [Online].
[10] TP-Link, “Tp-link.” [Online]. Available: https://www.tp-link.com Available: https://play.google.com/store/apps/details?id=com.lifx.lifx
[11] T. Ambient, “Zigbee vs Z-Wave: Two big smart home standards explored,” [34] LIFX, “Lifx website.” [Online]. Available: https://www.lifx.com/
https://www.the-ambient.com/guides/zigbee-vs-z-wave-298, 2018. [35] Belkin, “Wemo.” [Online]. Available: http://www.wemo.com/
[12] Tuya, “Tuya website.” [Online]. Available: http://www.tuya.com/ [36] “Security flaws in universal plug and play: Unplug,
[13] S. Hirst, “WiFi Hacking: How Hackers Break Into Your Wireless don’t play.” [Online]. Available: https://blog.rapid7.com/2013/01/
Network,” https://thevpn.guru/wifi-hacking-security, The VPN Guru, 29/security-flaws-in-universal-plug-and-play-unplug-dont-play/
2018. [37] “Upnp technical basics: Upnp device architecture (uda).” [Online].
[14] J. Caballero, P. Poosankam, C. Kreibich, and D. Song, “Dispatcher: Available: http://upnp.org/resources/documents/UPnP_UDA_tutorial_
Enabling active botnet infiltration using automatic protocol reverse- July2014.pdf
engineering,” in Proceedings of the 16th ACM Conference on [38] “e-control.” [Online]. Available: https://play.google.com/store/apps/
Computer and Communications Security, ser. CCS ’09. New details?id=com.broadlink.rmt
York, NY, USA: ACM, 2009, pp. 621–634. [Online]. Available: [39] E. Fernandes, A. Rahmati, J. Jung, and A. Prakash, “Decentralized
http://doi.acm.org/10.1145/1653662.1653737 Action Integrity for Trigger-Action IoT Platforms,” in 22nd Network and
[15] A. Al-Fuqaha, M. Guizani, M. Mohammadi, M. Aledhari, and M. Ayyash, Distributed Security Symposium (NDSS 2018), Feb. 2018.
“Internet of things: A survey on enabling technologies, protocols, and [40] “Ida pro.” [Online]. Available: https://www.hex-rays.com/products/ida/
applications,” IEEE Communications Surveys Tutorials, vol. 17, no. 4, [41] N. Komninos, E. Philippou, and A. Pitsillides, “Survey in smart grid
pp. 2347–2376, Fourthquarter 2015. and smart home security: Issues, challenges and countermeasures,” IEEE
[16] MITRE, “Cve - common vulnerabilities and exposures.” [Online]. Communications Surveys Tutorials, vol. 16, no. 4, pp. 1933–1954,
Available: https://cve.mitre.org/ Fourthquarter 2014.
[17] MQTT, “Mqtt website.” [Online]. Available: http://mqtt.org/ [42] Y. J. Jia, Q. A. Chen, S. Wang, A. Rahmati, E. Fernandes, Z. M. Mao,
[18] NIST, “Security considerations for voice over ip systems.” [Online]. A. Prakash, and S. J. Unviersity, “Contexiot: Towards providing contextual
Available: https://csrc.nist.gov/publications/detail/sp/800-58/final integrity to appified iot platforms,” in Proceedings of The Network and
[19] O. C. Foundation, “Upnp - universal plug and play specifications.” Distributed System Security Symposium, vol. 2017, 2017.
[Online]. Available: https://openconnectivity.org/developer/specifications/ [43] Z. B. Celik, P. McDaniel, and G. Tan, “Soteria: Automated iot safety
upnp-resources/upnp and security analysis,” arXiv preprint arXiv:1805.08876, 2018.
[20] “Simple service discovery protocol draft,” https://tools.ietf.org/html/ [44] Z. B. Celik, E. Fernandes, E. Pauley, G. Tan, and P. McDaniel,
draft-cai-ssdp-v1-03, Internet Engineering Task Force, 1999. “Program analysis of commodity iot applications for security and privacy:
[21] U. CERT. [Online]. Available: https://www.us-cert.gov/ncas/ Challenges and opportunities,” arXiv preprint arXiv:1809.06962, 2018.
current-activity/2013/01/29/CERT-Releases-UPnP-Security-Advisory [45] S. Nadi, S. Krüger, M. Mezini, and E. Bodden, “Jumping through hoops:
[22] “jadx: Dex to java decompiler.” [Online]. Available: https://github.com/ why do java developers struggle with cryptography apis?” in Proceedings
skylot/jadx/ of the 38th International Conference on Software Engineering. ACM,
[23] F. Wei, S. Roy, X. Ou, and Robby, “Amandroid: A precise and general 2016, pp. 935–946.
inter-component data flow analysis framework for security vetting of [46] J. Chen, W. Diao, Q. Zhao, C. Zuo, Z. Lin, X. Wang, W. C. Lau, M. Sun,
android apps,” in Proceedings of the 2014 ACM SIGSAC Conference R. Yang, and K. Zhang, “Iotfuzzer: Discovering memory corruptions
on Computer and Communications Security, ser. CCS ’14. New in iot through app-based fuzzing,” in Proceedings of The Network and
York, NY, USA: ACM, 2014, pp. 1329–1341. [Online]. Available: Distributed System Security Symposium, 2012.
http://doi.acm.org/10.1145/2660267.2660357 [47] Veracode, “The internet of things: Security research study,”
[24] M. Egele, D. Brumley, Y. Fratantonio, and C. Kruegel, “An empirical https://www.veracode.com/sites/default/files/Resources/Whitepapers/
study of cryptographic misuse in android applications,” in Proceedings of internet-of-things-whitepaper.pdf.
the 2013 ACM SIGSAC Conference on Computer and Communications
Security, ser. CCS ’13. New York, NY, USA: ACM, 2013, pp. 73–84.
[Online]. Available: http://doi.acm.org/10.1145/2508859.2516693

11