CATEGORIZING THE SECURITY AND PRIVACY OF
“INTERNET OF THINGS” DEVICES
by
Matthew A. Wynn
APPROVED BY SUPERVISORY COMMITTEE:
Alvaro Cardenas, Chair
Murat Kantarcioglu
Bhavani Thuraisingham Copyright c 2018
Matthew A. Wynn
All rights reserved CATEGORIZING THE SECURITY AND PRIVACY OF
“INTERNET OF THINGS” DEVICES
by
MATTHEW A. WYNN, BS
THESIS
Presented to the Faculty of
The University of Texas at Dallas
in Partial Fulfillment
of the Requirements
for the Degree of
MASTERS OF SCIENCE IN
COMPUTER SCIENCE
THE UNIVERSITY OF TEXAS AT DALLAS
May 2018 ACKNOWLEDGMENTS
The author would like to thank Dr. Alvaro Cardenas and the members of the Cyber-Physical Systems lab for their guidance and insight. This material is based upon work supported in part by NSF under award number CNS 1553683.
April 2018
iv CATEGORIZING THE SECURITY AND PRIVACY OF
“INTERNET OF THINGS” DEVICES
Matthew A. Wynn, MS The University of Texas at Dallas, 2018
Supervising Professor: Alvaro Cardenas, Chair
Internet of Things (IoT) devices are becoming an important part of our daily lives. In this thesis, we analyze the security and privacy risks of IoT devices in Smart Homes Hubs, the intersection of our daily lives and the internet, as well as intimate devices, where the vulner- abilities can put the owners at risk of privacy breaches and even sexual assault. We discuss the role of these IoT devices, analyze their practices and vulnerabilities, and emphasize the importance of holding the security and privacy of these devices to a higher standard than other IoT tools.
v TABLE OF CONTENTS
ACKNOWLEDGMENTS ...... iv ABSTRACT ...... v LIST OF FIGURES ...... viii CHAPTER 1 INTRODUCTION ...... 1 CHAPTER 2 ANALYSIS OF SMART HOME HUBS ...... 2 2.1 Introduction ...... 3 2.1.1 Related Work ...... 4 2.2 Summary of Smart Hubs ...... 5 2.2.1 Google Home Mini ...... 5 2.2.2 Amazon Echo Dot ...... 6 2.2.3 Samsung SmartThings Smart Home Hub ...... 8 2.2.4 OZOM Box 3.0 ...... 8 2.3 Security Analysis ...... 10 2.3.1 Google Home Mini ...... 10 2.3.2 Amazon Echo Dot ...... 10 2.3.3 Samsung SmartThings ...... 11 2.3.4 OZOM Box 3.0 ...... 12 2.4 Conclusion ...... 15 CHAPTER 3 SEXUAL INTIMACY IN THE AGE OF SMART DEVICES . . . . . 17 3.1 Introduction ...... 17 3.2 The Changing Notions of Sexual Intimacy ...... 18 3.2.1 Liberty and Privacy ...... 19 3.2.2 Safety and Security ...... 20 3.2.3 Related Work ...... 21 3.3 Devices ...... 22 3.3.1 Vibease ...... 23 3.3.2 OhMiBod blueMotion ...... 24 3.3.3 We-Vibe ...... 26
vi 3.3.4 Kiiroo Pearl2 and Fleshlight Launch ...... 26 3.3.5 Lovense Nora and Max ...... 28 3.4 Security and Privacy Findings ...... 28 3.4.1 Vibease ...... 28 3.4.2 OhMiBod blueMotion ...... 33 3.4.3 We-Vibe ...... 37 3.4.4 Kiiroo Pearl2 and Fleshlight Launch ...... 41 3.4.5 Lovense Nora and Max ...... 42 3.5 Conclusions ...... 42 CHAPTER 4 CONCLUSION ...... 44 REFERENCES ...... 45 BIOGRAPHICAL SKETCH ...... 47 CURRICULUM VITAE
vii LIST OF FIGURES
2.1 Google Home Mini ...... 6 2.2 Google Home History ...... 6 2.3 Google Assistant Settings ...... 7 2.4 Home Mini Settings ...... 7 2.5 SmartThings Routines ...... 9 2.6 Google Assistant traffic, the phrase “Hey Google, what’s the weather?” was spoken just before the 60 second mark...... 10 2.7 Alexa traffic, the phrase “Hey Alexa, what’s the weather?” was spoken about the 50 second mark...... 11 2.8 Traffic between the SmartThings Hub and Samsung Servers. A motion sensor set up to turn off a lightbulb is triggered at 23 seconds. The lightbulb is turned back on via an external integration at 30 seconds...... 12 2.9 Firmware format ...... 13 3.1 Vibease App Store. Audiobooks can be used to control vibration patterns. . . . 24 3.2 Using the Vibease with a trusted remote partner...... 25 3.3 OhMiBod App...... 27 3.4 The We-Vibe App...... 27 3.5 Lovense Chat...... 29 3.6 Lovense Pattern Store...... 29 3.7 Notifications with a locked screen might pose privacy risks...... 32 3.8 We were surprised to find that our default image profile in Vibease after linking to Facebook was the profile Image of our test Facebook account...... 33 3.9 OhMiBod Attack...... 37 3.10 Successful Impersonation...... 37 3.11 Attempting to break SSL results in disabling of remote functionality ...... 39
viii CHAPTER 1
INTRODUCTION
Home automation is becoming increasingly popular in today’s society. Advances in Internet of Things technology has transformed this hobby into affordable systems for increasing home security, providing better responses to safety hazards such as fires, and increasing the quality of life of early adopters.
1 CHAPTER 2
ANALYSIS OF SMART HOME HUBS
Authors – Matthew Wynn, Junia Valente, Luis Salazar, Alvaro Cardenas
The Computer Science Department, EC 31
The University of Texas at Dallas
800 West Campbell Road
Richardson, Texas 75080-3021
Key words: IoT, security, smart homes Corresponding author: Matthew Wynn
2 I was the primary researcher of these devices. I studied each of the devices, analyzed the network traffic and the update scripts, discovered the vulnerabilities in the OZOM device, and wrote a large majority of the paper.
2.1 Introduction
Home automation is becoming increasingly popular in today’s society. Advances in Internet of Things technology has transformed this hobby into affordable systems for increasing home security, providing better responses to safety hazards such as fires, and increasing the quality of life of early adopters. At the heart of home automation are “Smart Home Hubs”. These hubs provide a cen- tralized place for users to connect various IoT devices, incorporate them into an automation system with integrations, and interact with these systems via external commands. Many of these Smart Home Hubs offload their data and processing to a cloud service, which handle integrations with external services. However, as more IoT devices are created and integrated with Smart Home systems, the security implications become more serious. We identify four different attack targets that come along with these “smart hubs”. The first is the ability for a hacker to control connected devices such as smart locks, appliances, and a variety of sensors. Several Smart Homes are set up as security systems, where sensors (such as contact sensors, motion detectors, and cameras) generate an alert on a user’s smartphone if they are triggered (e.g., if motion is detected when the user is at work). It would be trivial for an attacker, having successfully compromised a smart home hub, to limit the outgoing traffic and exclude alerts, disabling the user’s security system and allowing them to enter the house undetected. Another potential security target can be the users’ accounts linked to these devices. These devices usually connect to cloud-based services provided by Amazon or Google, for
3 example. Taking over these devices allow attackers to access information about the user’s accounts. In these examples especially, if permissions are set up poorly, an attacker could access the target’s payment information, search and purchase history, private conversations, and other personal data.
Third, the attacker may be able to remotely gain access to the device, and then move laterally across an internal network. In 2017, a casino was hacked by way of an Internet- connected fishtank (Limited, 2017). Hackers were not able to directly access the casino’s servers, which were behind a firewall. However, by exploiting vulnerabilities in the IoT sensors on the fishtank, they were able to get inside the firewall and extract data from the casino’s servers. Similarly, a hacker could use a weakness in a Smart Home hub to get inside a user’s home network and search for other internal devices to exploit.
Finally, an attacker may be able to use information from the sensors and usage data associated with a Smart Home hub to monitor the user’s activity. From this, they might determine the user’s schedule, the devices they own, when they are on vacation, etc. Ther- mostat settings may reveal when the user is usually away, door or motion sensors could indicate where users are in the house, and light activity may show when the user is asleep.
2.1.1 Related Work
In 2017, Jose and Malekian explain security issues in existing home-automation systems (Jose and Malekian, 2017). They attempt to define “normal” user behavior (i.e. proximity sensors near a front door will be triggered before the user attempts to unlock that door), detect anomalies that could indicate a malicious actor, and request additional verification when an attack is detected.
Noah Apthorpe, Dillon Reisman, Nick Feamster published “Closing the Blinds: Four
Strategies for Protecting Smart Home Privacy from Network Observers” (Apthorpe et al.,
2017). They identify the threats smart home consumers face to network sniffers attempting
4 to determine users’ private behaviour. They then propose four solutions: blocking traffic, concealing DNS, tunneling traffic, and shaping and injecting traffic. In this way, they are able to mask the side-channel privacy threats that are inherent to today’s smart home technology.
2.2 Summary of Smart Hubs
In this paper, we study 4 different Smart Hubs. The Amazon Echo Dot and the Google Home Mini are both “Smart Assistants”. These devices act as microphones and speakers, listening for voice commands and performing actions. The Samsung SmartThings Hub and the OZOM Box 3.0, on the other hand, set up networks for linking smart sensors and devices, and controlling the interactions between them.
2.2.1 Google Home Mini
The Google Home Mini is the smallest of the Google Home products. It is shaped like a pebble, 4 inches in diameter (see Fig. 2.1). It has a micro USB port for power, a microphone mute switch, and touch sensors on the top left, right, and center that are used for lowering the volume, raising the volume, and manually triggering listening, respectively. The center sensor was disabled in an update, after hardware issues caused the device to falsely detect a press and start recording audio for processing. The assistant is triggered by using a wake word—“Okay Google” or “Hey Google”. The assistant is always listening for these phrases, and upon hearing them, activates the indicator lights on the top, continues recording, and begins sending the audio (including the audio of the user speaking the wake word) to Google’s servers for processing. The user will then speak a command, i.e., “What’s the weather like?”, or “Turn on the lights.” After sending the full audio to the server, the device then receives a response and speaks it back to the user. All of the queries, recorded audio, and response transcripts are available for the user to review and delete online as seen in Fig. 2.2.
5 Figure 2.1. Google Home Mini Figure 2.2. Google Home History
The device is setup via the Google Home app for iOS and Android. When the Google
Home Mini is plugged in for the first time, it will broadcast a WiFi network. The app on the user’s phone will detect the WiFi network and prompt the user to setup the device.
The user’s phone then connects to the hub’s WiFi and initializes the device with the user’s
Google account and home WiFi credentials. Once setup, the user can use the phone app to add addresses, credit card information, music services, and integrations with other Smart
Home devices. Most of this information is specific to “Google Assistant” (Fig. 2.3) instead of the specific device (Fig. 2.4), and is stored on Google’s servers, rather than the device itself. As such, users can speak to Google Assistant on any enabled device and get consistent results.
2.2.2 Amazon Echo Dot
The Echo Dot is shaped like a tall hockey puck. It has four buttons on the top: volume up, volume down, mute, and a button to manually trigger listening. It also has indicator lights and a speaker. Similar to the Home Mini, the Echo Dot listens for a wake word, such as
“Alexa”, which can be chosen from a list.
6 Figure 2.3. Google Assistant Settings Figure 2.4. Home Mini Settings
The basic functionality is very similar to Google Home. However, while the Google Home
Mini processes commands via the Google Assistant platform, the Echo Dot uses Amazon
Alexa. The Echo Dot also uses Bluetooth for casting music from other devices, while Google
Home uses the chromecast protocol. Finally, the Echo Dot includes a 3.5mm audio output jack, which is missing on the lowest Google Home offering.
7 2.2.3 Samsung SmartThings Smart Home Hub
The SmartThings hub provides a Z-Wave and ZigBee network for connecting SmartThings devices. It connects to the Internet via Ethernet and provides control for these applications via the SmartThings app or website. The application provides control of connected devices (outlets, switches, motion detectors, etc). It also supports “Routines”; for example, a “Good Morning” routine might be configured to turn on the lights at a certain time or when a sensor is activated, as in Fig. 2.5. Another interesting feature of the Samsung SmartThings Home Hub is the support for SmartApps. Anyone can create and request to publish these apps, which provide automation support and integration with other devices and services. For example, the Google SmartApp provides integration with Google Assistant so that one can, for example, say “Hey Google! Turn on the outlet.” Another app, Jenkins Notifier, logs into a Jenkins build server and changes the color of smart lightbulbs based on the status reported by Jenkins.
2.2.4 OZOM Box 3.0
The OZOM Box 3.0 is a home automation hub popular in Latin America. When we looked up the FCC ID for the OZOM hub device, we found that the actual manufacture is Ser- comm Corporation. Further, the manufacture rebrands this particular hub device under two different company names: OZOM and Vera Smart Home Control. While OZOM devices are popular in Latin America, Vera devices are sold in the USA. ROC-connect, a California- based company, provides the firmware running on OZOM, and Sodimac, a Chilean home improvement warehouse company, sells OZOM devices in Latin America. Meanwhile, a dif- ferent company, Mi Casa Verde (MiOS), maintains the firmware and applications running on Vera devices. We found that OZOM and Vera devices use a similar firmware image. Devices built for the OZOM seem to center around home security and safety. These products include sirens, alarms, motions sensors, cameras, panic buttons, smart locks, and
8 Figure 2.5. SmartThings Routines
more. The documentation describes how to simulate presence at home with smart lights, even when the user is away. It also provides services for alerting emergency contacts when certain events are triggered.
9 2.3 Security Analysis
2.3.1 Google Home Mini
We found that much of the Google Home Mini’s traffic was encrypted, with minor exceptions being connectivity checks to /generate 204 pages. These pages will generally return blank HTTP 204 responses, unless the user is behind a “Captive Portal”, such as in hotel or coffee shop WiFi. There is still some encrypted data being sent when the device is idle, but the throughput to Google servers increases dramatically when responding to a voice command, as in Fig. 2.6. By detecting this, an attacker may be able to obtain some information about usage patterns.
Figure 2.6. Google Assistant traffic, the phrase “Hey Google, what’s the weather?” was spoken just before the 60 second mark.
2.3.2 Amazon Echo Dot
Similar to the Google Home Mini, most data, aside from connectivity checks, is encrypted. Additionally, aside from small, infrequent “heartbeats”, the Echo Dot does not maintain
10 regular traffic with the servers. Thus, as shown in the Fig. 2.7, someone able to sniff the traffic would be able to determine when the device is being used.
Figure 2.7. Alexa traffic, the phrase “Hey Alexa, what’s the weather?” was spoken about the 50 second mark.
2.3.3 Samsung SmartThings
The Samsung SmartThings box, as with the previous devices, encrypts most of its data. Even though some of its domains, for example its firmware site fw-update2.smartthings.com, use self-signed certificates, the keys are still trusted by the SmartThings device, and so the connections cannot be feasibly hijacked. Sensors and events cause network traffic, such as in Fig. 2.8 to appear on connections between Samsung’s servers and the SmartThings Hub.
The implications of a malicious actor obtaining this information is slightly more serious than in the case of the smart-assistants. Sensor and event traffic can indicate a user is moving about the house, activating lightbulbs or locks, or is otherwise active. By analyzing this
11 data, someone could determine when a homeowner is away or sleeping, and plan a physical attack to his property.
Figure 2.8. Traffic between the SmartThings Hub and Samsung Servers. A motion sensor set up to turn off a lightbulb is triggered at 23 seconds. The lightbulb is turned back on via an external integration at 30 seconds.
2.3.4 OZOM Box 3.0
While much of the network traffic between the box and the OZOM Cloud is encrypted, when analyzing the traffic upon booting, several vulnerabilities become apparent. On each boot, the device checks for new updates to its firmware and application scripts over unencrypted
HTTP. These files are not signed or cryptographically verified in any way. By intercepting and modifying these scripts via a Man-In-The-Middle attack, an attacker can add his own code to the software, giving him a backdoor to control the device.
12 The OZOM checks for updates to several files; among them are Firmware, Gagent, Gsync,
and Gupdate. Since all of these are downloaded over an unencrypted link, we are able to
obtain and analyze them.
The firmware file can be analyzed with a binary-file analysis tool. The firmware is
organized As seen in Fig. 2.9. By looking at the firmware we found that the Ozom box is an
OpenWRT base image with minor modifications.
0x0 Header: ”MIPS OpenWrt Linux-3.18.21” LZMA compressed data (0x6D) 0x40 Squashfs filesystem 0x163D0D little endian compression: xz size: 8388608 bytes 0x5C0004
Figure 2.9. Firmware format
The system has an RPC service which is enabled by default. This service is activated by
the SySVinit according to the dynamic link /etc/rc.d/S12rpcd, which starts the service every time the OS boots. The risk comes from the default credentials stored within the
/etc/config/rpcd file, in which the password ‘$p$root’ is stored in plain text. Further analysis is required to determine if an attack is possible via the RPC service using the root
credentials stored in this file.
The second file, Gagent, is a compressed directory including the main software handling
most of the Smart Home functionality. The same Gagent program may be distributed via
one of several files, including gagent.tgz, epsilon.tgz, factory.tgz, gagent.lib.tgz,
gagent.factory.tgz, and more. Much of the Gagent are compiled Erlang beam files which control interactions between the hub, the attached devices, the internal web server, and the
OZOM API server. These files are encoded as binary and cannot be decompiled back into
Erlang, but there are several configuration files and shell scripts that provide insight as to
13 what the device is doing. One interesting script is gagent.init, which the init system starts on boot. This shell script sets up the environment for gagent, and also checks for updates for the Gsync and Gupdate scripts (described below).
Gsync is a shell script that is run as the last step of the firmware’s rc.local file, at the end of the boot sequence. It downloads hardware-specific OpenWRT packages for the device.
It also checks for updates to the previously-described Gagent tarball. Finally, the Gupdate script sets up a local WiFi network with a plaintext password (87654321) and checks for a new firmware file.
As described above, these four components include shell scripts that check for updates for the other scripts and tarballs. While there are minor implementation differences for each download (i.e., the gagent.init script will fall back to using a proxy or wget if basic curl does not work when downloading), the basic algorithm is the same.
As you can see in Algorithm 1, there are two files the script downloads, first filename.md5, and then, if that MD5sum is different from the MD5sum of the file on disk, it downloads filename. Then, so long as filename.md5 is valid for the downloaded file, the file is in- stalled.
An attacker could easily perform an attack by first obtaining a file (e.g., the Gsync file, which is available on the firmware website), and modifying it. This modification could be inserting an SSH publickey or installing a reverse shell, for example, and creating an MD5sum with the updated hash. The attacker would then use a Man-in-the-Middle technique such as
ARP spoofing or DNS hijacking (i.e., with Ettercap) to redirect the device to his own files or modify the script and provided MD5sum on the wire. Since the download is unencrypted and unsigned, and there is no form of verification other than the simple hash, the box should blindly install the attacker’s file and run it when scheduled next.
14 Function download filename newMD5 ← Curl (filename.md5); if newMD5 exists then // Successful download // Check already existing file’s hash oldMD5 ← MD5sum (/path/to/filename); if oldMD5 6=newMD5 then newFile ← Curl (filename); if newFile exists then // Check new file’s hash dlMD5 ← MD5sum (newFile); if dlMD5 = newMD5 then // Verify Install (newFile) else Log (“Download Failed”) end else Log (“Curl error”) end else Log (“filename is already up to date”) end else Log (“MD5 download error”) end end Algorithm 1: Download Script
2.4 Conclusion
We have determined that Smart Home hubs provide a central role in the lives of their users. Attacks on Smart Homes have real-life consequences, posing a threat to the security and privacy of the inhabitants. While most of the devices we studied make heavy use of encryption, the OZOM provided a risk to its users by downloading its firmware over plaintext. Additionally, care needs to be taken, to ensure that an attacker in a position to sniff traffic can not tell when users are active and when they are away. As smart homes become more common and integrated with our everyday tasks, the implications of security and privacy vulnerabilities becomes more critical. It is imperative
15 that Smart Home Hub manufacturers make security a high priority before putting their products in the middle of their users’ lives.
16 CHAPTER 3
SEXUAL INTIMACY IN THE AGE OF SMART DEVICES
This paper serves an extension to “Sexual Intimacy in the Age of Smart Devices: Are
We Practicing Smart IoT?” (Wynn et al., 2017), (DOI 10.1145/3139937.3139942). I was the primary researcher of these devices. I discovered the two main vulnerabilities in the
OhMiBod and Vibease apps, extended the We-Vibe analysis, and was the sole researcher for the Kiiroo and Lovense devices.
3.1 Introduction
While IoT devices are collecting physical data of diverse human activities such as electricity consumption, location information, driving habits, and biosensor data, perhaps no other information captured by IoT devices is as sensitive as our sexual preferences. With the rise of smart sexual devices that offer wireless connectivity via Bluetooth Low Energy (BLE),
Wi-Fi, and even the Internet, we need to start an open and detailed discussion of the security and privacy risks to the users of these devices, and how vendors can make these devices more secure, private, and safe.
In this paper we analyze a collection of smart Internet-connected intimate devices: the
Vibease, We-Vibe 4 Plus, OhMiBod blueMotion, the Kiiroo Fleshlight Launch and Pearl2, and the Lovense Max and Nora. All of these devices connect to a smartphone application
(app) using BLE, and all of them offer the option of remote control via the Internet, where a partner is able to interact with the user of the device while they are apart. We find systematic problems in all devices, ranging from devices continuously advertising their presence in BLE
(so anyone looking for nearby Bluetooth devices can potentially identify the owner of a device) to authentication problems between partners, making the risk of a remote sexual assault a dangerous possibility.
17 We reported our findings to Vibease and OhMiBod and both companies were responsive
to our requests. Vibease acknowledged our help in their security website https://www.
vibease.com/security, and the day the camera-ready paper was due, they contacted us stating that our reported vulnerabilities had been fixed in their latest iPhone and Android apps. OhMiBod was also responsive, and they told us they were currently in the middle of changing their developing company, and they informed their new company that their future apps should fix our reported vulnerabilities. Our reported impersonation vulnerabilities have
CVE numbers CVE-2017-14486 and CVE-2017-14487.
This paper is organized as follows: we first contextualize the problem with a discussion of sexual intimacy, morals legislation and liberty. We then describe the functionalities of the devices we analyzed. Finally, we illustrate our security and privacy concerns with these devices and suggest recommendations to improve the safety and privacy of these devices.
3.2 The Changing Notions of Sexual Intimacy
Sexual devices play an important role in the intimate choices of individuals. Vibrators in particular have a historical role. Physicians used genital massage as early as the middle of
1600’s to treat female “hysteria” or “womb disease” (Herald, 2004) and vibrators were later invented in the late 19th century to treat the same ailments. Vibrators began to be marketed together with other electrical household goods, appearing in McClure’s magazine in March
1899 (Herald, 2004), and vibrating genital massagers were sold in the Sears Roebuck catalog until the 1920s (Herald, 2004). However, as their perception shifted from their medical benefits to their role in sex, their general availability and acceptance have been challenged by our moral culture. To fully understand the security and privacy implications of new IoT sex devices, we need to study the context of moral legislation and sexual abuse.
18 3.2.1 Liberty and Privacy
The rights of liberty and privacy in a society are deeply divided over moral culture (Struening,
1996). We value and protect the freedoms of religion and expression, in part, because we believe that wrestling with and coming to our own religious and moral judgments is an essential component of self-determination and self-definition. Sexual choice and intimate association play an analogous role in the individual’s life (Struening, 1996); however these intimate choices haven’t been as protected as other freedoms due to moral norms.
Morals legislation has been at the center of many important controversies over equal protection of the laws and the regulation of sexual and private conduct. When states in the U.S. have banned vibrators and other sex aids, historical litigation strategies challenging these laws have reinforced existing biases involving women’s sexuality, as courts seem more willing to see a constitutional right of women to the private use of these devices as long as they have a sanctioned relationship with a man or as long as the use of the device is for medical or therapeutic purposes (Herald, 2004).
In Lawrence v. Texas, the Supreme Court of the U.S. held unconstitutional a Texas law criminalizing sexual relations between individuals of the same sex as it infringed the petitioners’ “right to liberty” (the liberty of persons to engage in deeply intimate choices) and because the law furthered “no legitimate state interest” as moral disapproval alone could not justify intrusion into the “personal and private life of the individual” (Possolo, 2013). After
Lawrence, discussion on ending bans to sexual devices shifted from their validity for medical or therapeutic purposes and focused on whether the government has any reason, other than moral disapproval, for policing consenting adults in their private bedroom activities (Herald,
2004). The debate over laws regulating the sale of sexual devices is at the heart of an important question that was raised in Lawrence: to what extent can morality serve as a legitimate basis for laws that place a significant burden upon individual liberty interests?
19 State and federal courts in the U.S. are currently divided as to the constitutionality of laws banning the sale or distribution of sexual devices. In Williams v. Morgan, the Eleventh
Circuit upheld an Alabama law prohibiting sales of devices used for sexual stimulation and stated that Lawrence did not recognize a fundamental right to sexual privacy. In contrast, in Reliable Consultants, Inc v. Earle, the Fifth Circuit reached the opposite conclusion when reviewing a similar statute in Texas (Possolo, 2013). Finally, the supreme courts of five states have come out on different sides on this issue, only two states have upheld laws against the sale of sexual devices: Alabama and Mississippi (Possolo, 2013).
Laws criminalizing the sale of sexual devices have real consequences; they have been en- forced by undercover police operations, and people have been prosecuted and imprisoned for violating their terms (Possolo, 2013). Smart sexual devices are enabling new ways of tracking users of potentially banned devices, and the data collected by the manufacturer of the device might be requested (or hacked) by governments where the devices have been banned. These problems are exacerbated in countries with even stronger stances on moral legislation and stronger enforcement; for example, there is evidence that the Egyptian government might have used the dating app Grindr to entrap gay and transgender women (Times, 2016). Sim- ilar abuses could be pursued by attempting to track the users of IoT-enabled sexual devices.
Sex toys are banned in several countries in Africa, the Middle East, and Asia, and therefore protecting their users against other users and even nation-states is one of the challenges that smart sexual device manufacturers will have to prioritize.
3.2.2 Safety and Security
In addition to privacy issues, the functionalities of smart sexual devices also open the door to new security and safety concerns. For example, the smart vibrators we analyzed offer control of via Bluetooth, but some devices had weak Bluetooth settings and a nearby attacker could hijack a connection and control the device without the owners realizing they have lost control.
20 The devices we analyzed also allowed remote partners to connect via the Internet and
control the device, but weak authentication can put owners of the device at risk, believing
they have accepted a vibration command by their partners while in reality the vibration
commands are being sent by an attacker.
These two scenarios can be considered sexual assault and even rape. As recently summa-
rized by Peter Teffer from EUObserver (EUosbserver, 2017), in Belgium, the criminal law on
rape contains the phrase by whatever means without consent, which indicates that hacking
a sex toy in Belgium could be considered rape. In Ireland, it wouldn’t be rape, but it could
fall under the definition of sexual assault: vaginal intercourse manipulated by any object by another person. In the U.S. the FBI removed in 2013 the requirement of force under their
definition of rape, and now also include without the consent of the victim. Different states
have different legal definitions of rape, but one legal definition, which is used by the United
States Armed Forces is found in the United States Uniform Code of Military Justice where
the attacks we described would be classified as sexual assault since their definition includes
the sentence inducing a belief by any artifice, pretense, or concealment that the person is
another person.
In the attacks discussed in this paper there is still a human involved that could be
considered liable for the malevolent actions. But what if the sex toy is self-learning? What
if sex robots with artificial intelligence become predatory (EUosbserver, 2017)? These are
questions that we will need to address in the not so distant future (Sharkey et al., 2017).
3.2.3 Related Work
At DEFCON 2016, two experts warned that while they were evaluating whether third parties
could exploit a particular vibrator, they actually found that users should be more worried
about manufacturers that are collecting and storing data sent by these devices. The expert-
s/hackers analyzed the We-Vibe 4 Plus c and detected it sends temperature and intensity
21 data to the manufacturer, in real time. They highlighted that this practice raises several issues to consider: hackers could steal the data stored by the manufacturer to blackmail the company itself or, even worse, since in some countries it is prohibited having this kind of toys, the collected data could reveal who is using them leading to severe punishments
(Motherboard, 2016; Register, 2016). A month later, a woman from Illinois decided to sue the manufacturer of her we-vibe device after learning, from the DEFCON talk, what was happening with her very personal data (Today, 2016). More recently, it was announced that during the lawsuit the layers found that the app associated to we-vibe devices also collects users emails, making it possible to relate usage information to specific customers. Instead of going to court, the company agreed to settle. It also agreed to stop collecting email addresses and update its privacy notice (Radio, 2017).
Recently a researcher developed a Tor-based mechanism to protect users’ identities (Moth- erboard, 2017). The researcher set up her vibrator to receive commands through the Tor network. She used a Tor service, Ricochet, to create a hidden service associated to the device. Users that know the address of this Ricochet service can send remote commands.
This mechanism protects the communications and hides the identities of the endpoints in a communication.
3.3 Devices
All the devices we analyze communicate via Bluetooth Low Energy (BLE) with a smartphone app (one device uses regular Bluetooth instead of BLE), and in turn, the app in the phone communicates with the manufacturer servers. BLE is a new variant of Bluetooth tailored for
IoT devices with battery constraints and low-rate communications. BLE offers new privacy and security features to protect IoT users. Some of these include the ability to hide the name or address of the devices (so devices are not discoverable by others, only by previously
22 paired devices), randomization of the addresses of the device, so users cannot be tracked as they move to different places, and encrypted communications.
In this paper we study if our smart vibrators have implemented the best security and privacy aspects of BLE, and have good app security practices. We use the Ubertooth One
Bluetooth sniffer to monitor communications in BLE and regular Bluetooth.
3.3.1 Vibease
The first device we study is the Vibease. The device is about 2.5 inches long and slightly curved. Its outside shell is a water-resistant form of plastic that is hypo-allergenic and designed to sit in a woman’s undergarments during use. On the top of the device, there are two manual control buttons. One is for power and the other directly controls vibration.
There is a charging port obscured on the end to protect the electronic components. Next to the buttons there are two LEDs to show various status codes during use.
Vibease also developed a mobile app, available as Wireless Remote Vibrator for An- droid (Vibease, 2014b) and as Vibease chat for iOS (Vibease, 2014a). The app also has audiobooks and sound clips paired with vibration patterns that can be downloaded and run
(Fig. 3.1). Users may use Facebook to register in the app, or they may choose an email and password.
The app allows several users to interact via a social network. Users also define a nickname that will be used by the app and an optional verification code; if the code is defined, only other users that know the code will be able to search for that user in the social network.
Contacts may be added through a username, email, or URL links sent to other users. Once a device owner has accepted a request for a connection, it is possible to exchange text and voice messages, pictures, emoticons and vibration requests. Vidcalls and messages can also contain vibration commands. The first time a vibration request is received it prompts the receiver to acknowledge whether to accept or reject that request. A user can also give permission to
23 Figure 3.1. Vibease App Store. Audiobooks can be used to control vibration patterns. add the contact to a trusted-users list. Fig. 3.2 illustrates how the device allows someone to remotely control the device (the other devices follow similar patterns to allow remote control of the vibrator).
3.3.2 OhMiBod blueMotion
The OhMiBod blueMotion is a wearable Bluetooth-enabled smart vibrator. Users can control the vibrator using the OhMiBod Remote app for Android and iOS (see Fig. 3.3). There are a variety of vibration styles and patterns to choose from. The user can choose control vibrations of the device through default rhythmic presets, touch input to the app, or voice recording.
24 Figure 3.2. Using the Vibease with a trusted remote partner.
Contrary to the other devices we study, the OhMiBod blueMotion does not communicate with the phone using BLE, rather it uses Bluetooth 2.0.
Users can add other users within the app as contacts. A request can be sent by searching for an account username. A user can make a connection request to another user to either have control of the vibrator or to have the user’s own vibrator controlled. Once accepted, users can send messages and pictures to each other. A user can, at any time, change his account to be public or private. A private account can only be searched and found by entering the full username. A public account can be searched with a matching substring of the username.
25 3.3.3 We-Vibe
The We-Vibe 4 Plus is a U-shaped vibrator which, similar to the Vibease, connects via BLE to an app in the phone which can control the pattern and the intensity of the We-Vibe. To use the application, no registration is required, the only required step is to pair the We-Vibe with the phone. The We-Vibe also allows a remote partner to control the device by using a URL link. Contrary to the other devices studied, we found that We-Connect does not allow us to take a screenshot of the app (Fig. 3.4) via the “FlagSecure” option. This restriction in screenshots is likely motivated as a step to protect the privacy of We-Vibe users. Since the application has chat and call capabilities, screen captures of these events could compromise the privacy of a user if these activities were shared by the remote party, or stolen from the user’s smartphone. However, we were able to modify our rooted phone’s operating system
to hook into the setFlags() and setSecure() functions, and override the disabling of screenshots for this paper. Another interesting feature is that the app needs to be in the active screen for a call to be maintained; the moment the user switches the application in the active screen, the call ends. Again, we believe this is also done to protect the privacy of we-vibe users (shutting down the app as soon as the user hides it from view) but we were not able to find justification for these design choices in the We-Vibe website, manuals, or FAQ.
3.3.4 Kiiroo Pearl2 and Fleshlight Launch
The Kiiroo Pearl2 is an insertable vibrator with touch sensors, allowing for synchronization with some other Kiiroo devices. Similarly, the Fleshlight Launch is a device which can hold a masturbatory sleeve and automatically move it up and down. The two Kiiroo devices are controlled by the FeelConnect app for iOS and Android, which, similar to the previous devices, allows for remote control of the device. The unique feature of this app is integration
26 Figure 3.3. OhMiBod App. Figure 3.4. The We-Vibe App. with the FeelMe website, which provides videos with timestamped device intensity metadata.
In this way, users can syncronize their strokes or vibrations to the content in the videos they watch on their computer. After creating an account on the FeelMe website and using the app to scann a QR code displayed on the website, a secure publish/subscribe connection is set up via the PubNub data stream network. While watching videos with this intensity metadata, the browser publishes vibration/stroke commands, and connected apps receive them and trigger the device.
27 The app is build with Apache Cordova, and, as such, is a html/javascript application that has been wrapped in an Android APK. It provides functionality for downloading binary
firmware for the bluetooth devices, connecting to the PubNub channels, and converting intensity data sent on that channel into vibrations or strokes for each device.
3.3.5 Lovense Nora and Max
The Lovense Nora is an insertable vibrator with two arms and a rotating head. Its male counterpart, the Lovense Max is an artificial vagina with vibration and contraction functions.
These devices are designed for local and remote control, as well as syncronization with each other via sensors on each toy. Each of these operations is performed on the Lovense Remote app. The application provides vibration intensity control via slider widgets, music files, live recorded sound, and preset patterns. Users can create their own preset patterns and publish them for other users to download and try, shown in 3.6.
Finally, partners can add each other on the app by searching for their usernames. Once connected, they can chat (3.5) via text and video, control each other’s devices, and send patterns. Since these conversations may be sensitive, the app also allows the user to set a
4-digit passcode that must be entered whenever the app is opened, or before photos are sent.
3.4 Security and Privacy Findings
3.4.1 Vibease
BLE Pairing
The vibease has a pairing mode that must be activated by holding down the power button for 5 seconds during startup. If not in this mode, it will only connect to the device with which it was previously paired, which is a good security practice. Having said that, this device has some BLE problems. Upon a scan request, the vibrator will return its name as
28 Figure 3.5. Lovense Chat. Figure 3.6. Lovense Pattern Store. a Vibease product to any device that asks. During our tests, a neighbor’s Vizio TV was sending scan requests and our vibrator was more than happy to tell the TV that it was a
Vibease vibrator; even if the Vibease was not in pairing mode. This is a big privacy risk, e.g., if there are only two people in a room and one finds the existence of the device, it will compromise the privacy of the Vibease owner. BLE also provides devices with the ability to hide their real address and to randomize their address to prevent them from being tracked across multiple locations, but the Vibease does not use these functionalities. A more secure
29 option would be to use ADV DIRECT IND when not in pairing mode, and to enable the use random BLE addresses. Traffic between the vibrator and the phone is encrypted using standard BLE encryption protocols. We used Crackle (Ryan, 2017), which is a tool used to test the security of BLE encryption, but we were unable to crack the keys.
App
The analysis of the IP traffic between the smartphone app and the cloud revealed a number of concerning issues. The app uses XMPP (Extensible Messaging and Presence Protocol) (Editor Peter Saint-Andre. Jabber Software Foundation, 2004) for message exchange with other apps, and chats and vibration commands between apps are sent via unencrypted XMPP, even though XMPP supports TLS and SASL for encryption and authentication (Sinn et al., 2008). While the server supports OAUTH2 authentication, the client sends the XMPP SASL
auth token using the PLAIN mechanism, which encodes via TOKEN = Base64(username\0password) (\0 is the null byte). Thus, when we see the authentication token:
30 front of several graduate students. In the class we showed how the threat of a remote sexual assault is a very real possibility. During the chats, an XMPP message packet with the following schema is sent:
Vibration commands use the body tag with message [*VIBEREQ:REQ!] to request access to send vibrations. After receiving [*VIBEREQ:ACP!] (request approved), it sends a request for touch functionality: [*VIBEFEAT:Touch|REQ!] and receives [*VIBEFEAT:Touch|ACK!] to begin the vibration session. Then, the application sends a vibration pattern in the form [*VIBEPATTERN:X|Y!], where X is an intensity value between 1 and 10, and Y is the number of milliseconds between pulses. In addition to the problem of impersonation and the risk of sexual assault, since all these messages were unencrypted, adversaries could see usernames, messages, and files sent between two Vibease users. We also discovered that images were being sent unencrypted in earlier versions of this app but the sharing of unencrypted images was fixed by an application update in version 2.50.37, pushed on March 27th, 2017, during our tests. While images are no longer sent over plain HTTP, their filenames are still sent over the unencrypted XMPP session. Another concern is that the app has not been updated to take advantage of Android changes to improve permission management. In Android 6.0 (API level 23) and higher, permissions may be granted and revoked at run-time. In earlier versions permissions were assigned during installation and could not be changed. As a consequence, users only had two options: install an app with all the permissions it requested, or not install it at all (Project, 2017). Since the Vibease app has not been updated, users must install the app and grant
31 all permissions it requests, even if it is not clear the reason for some of them, otherwise they cannot use it. The app requests permissions to access contact list, user’s location (exact and approximate), and id and state of the phone. Also to download files without notification, update system configuration, and draw itself over other apps in the phone.
Considering the sensitive nature of the app, notifications that show up on the screen of the phone, even when it is locked, might pose an additional privacy risk. Fig. 3.7 shows some of the notifications the Vibease app shows. The app includes the option of defining a pin number to get access to the application, but notifications in particular are shown regardless of having a pin enabled.
Figure 3.7. Notifications with a locked screen might pose privacy risks.
Finally, in addition to XMPP communications we also saw SSL-encrypted communica- tions between the app and the servers. We were able to use the Packet Capture application for Android to install custom CA certificates on our phone, set up a proxy, and study the SSL traffic. We discovered that the application was making connections toedge-star-shv-01-dft4.facebook.com,
Flurry Analytics agentportal2.flurry.vip.gq1.yahoo.com with information about the phone model, battery status and other system information, and AWS servers.
32 One of the domains we saw our app contacting was the Graph service of Facebook, which has an API for the profile pictures from a user. This finding is intriguing as we had not authorized the application to use our Facebook profile picture, and we were surprised to find that our default image profile in Vibease after linking to Facebook was the profile Image of our test Facebook account, as seen in Fig. 3.8.
Figure 3.8. We were surprised to find that our default image profile in Vibease after linking to Facebook was the profile Image of our test Facebook account.
3.4.2 OhMiBod blueMotion
Bluetooth
Similarly to the Vibease, if the blueMotion device is discoverable, it broadcasts its name (OhMiBod) to any device scanning at the time, along with its hardware address—therefore, the device presence can be discovered, and it can be tracked and recognized in different geographical places. Perhaps more worryingly is that if the phone it is paired to has bluetooth disabled, the vibrator will default into discovery mode, and anyone can then pair with the device, because it uses a 0000 (manual) pairing passcode (this passcode is recommended by Android devices). After being paired, an adversary can make the OhMiBod device vibrate without having to reverse-engineer the vibration protocol (as we did with the Vibease device) because we
33 discovered that the OhMiBod blueMotion is essentially a speaker (we found this when we wanted to play music in our phone but instead the device started vibrating), and it uses the amplitude of the audio file as the control for the vibration.
App
All communications between the OhMiBod app and the OhMiBod API server are TLS- encrypted. The app connects to the API server at https://api.ohmibod.com:443 or the
NodeJS API server at https://api.ohmibod.com:5000. We used SSLsplit as a proxy that terminates the SSL connection, logs the headers and body of the request, and re-encrypts the connection with a provided CA key. Since https generally only authenticates the server to the client, as long as we have installed the CA certificate on our phone, the proxy appears seamless.
Response for a user search:
{ " result ": { "ack": "success", " data ": { " users ": [ { "country": "United States", "email": "2b241506ec773b93276f4c2 18346527668991fcfedaa3214496 db6a04c257c5dcadd7d2a9564a17 8d1a8a20d3615d579789a357ac5a 595596efbe7ec8a20e911",
34 "gender": "f", "is_temp": 0, "month": "0", "news": null, " optIn ": 0, "phone": null, "photoURL": null, "privacy": 0, "state": "AL", "status": 1, "token": "$2a$12$b9dDipB8QP1ancyT oKJoJuywpXAfQ19WOlHBT1BJskv 98.K89qV/y", "user_id": 61852, "username": "temoctest", "year": 1920 } ] } } }
In our analysis, the inner packets contained mostly 404 errors, as many of the functions of this app, like editing one’s profile, were broken. However, searching for a user, requesting to control their vibrator, and chatting with the user does work. Searching for another user on the app returns, among other things, their userID, username, and a ”token” field. Upon
35 inspecting other network requests, it became clear that these three fields were used to identify a user between sessions, once they had authenticated with their username and password.
Since we are returned these fields simply by searching for a user, we can impersonate any user we search for. Rather than reverse engineering OhMiBod’s websocket protocol and setting up a client that could speak it, it was easy enough to test this out by editing the apps settings. An attacker can edit /data/data/com.ohmibod.remote2/shared prefs/OMB.xml in a rooted Android phone. This file contains info about the currently logged-in user and their OhMiBod contacts. After replacing all instances of the logged-in user’s token, user id, and username with those of the target user, and starting the app, the attacker can request to connect with another user. This victim then sees the request as coming from the compromised account (a presumably trusted partner), and any consequent chats and interactions will appear as such.
We summarize our attack in Fig. 3.9, Mallory is attempting to impersonate Alice and connect with Bob. To do so, Mallory first logs into the OhMiBod Server with her account.
She then searches for Alice’s user, and inspects the network traffic that is returned. This network traffic has Alice’s username, user ID, and authentication token. Mallory closes the app and edits the OMB.xml file, replacing her authentication info with the info she just obtained by searching for Alice. Upon reopening the app, she will appear as Alice.
Mallory can then send a connection request to Bob, and Bob will see a connection request from Alice. Bob, unaware that the other participant is actually Mallory, may accept the request, and begin an intimate chat and vibe session with Mallory, leading again to potential sexual assault, and privacy issues. We tested the successful impersonation attack and the unsuspecting user received the impersonated request captured in Fig. 3.10.
36 Figure 3.9. OhMiBod Attack. Figure 3.10. Successful Imperson- ation.
3.4.3 We-Vibe
Bluetooth
Bluetooth pairing is managed by the application itself, and does not seem to expose much information to the user via the OS’s bluetooth settings. However, the device does advertise itself as “4 Plus” to whomever requests, and it does not seem to randomize its MAC ad- dress, despite this being supported by BLE. Once paired, Bluetooth data was sent via ATT write requests. Each request contained some value, i.e., 0fff00f000000000, specifying the intensity of the upper and lower vibrator sections.
37 App
In late 2016, two hackers at DefCon presented a remote exploit for the WeVibe 4 plus, allowing them to take over a nearby vibrator while it was in use. Additionally, they revealed that the WeConnect app was periodically sending information about the vibrator’s intensity and temperature, back to the WeVibe servers. Soon afterwards, the vibrator’s creator,
Standard Innovation, reached a $3.75 million class-action settlement for collecting this data.
Court documents claimed that about 300,000 people bought Bluetooth-enabled WeVibe devices, and 100,000 used the app. WeVibe customers could receive up to $199, the cost of a high-end WeVibe vibrator. Additionally, if they paired their vibrator to the app, they would be eligible for up to $10,000 Given this expensive settlement, along with the embarrassing exploit, it is likely that WeVibe poured their efforts into securing the app, promoting privacy, and preventing further introspection.
Communications between the app and the server are set up via encrypted XMPP. This
XMPP seems to be secure, using TLS 1.2 with cipher suite TLS ECDHE RSA WITH AES 256 GCM SHA384, one of the strongest suites widely available. Requests are made to 209.15.0.47 port 443, which is non-standard for that type of communication (443 is usually https, but is allowed by more firewalls than the 5222–5223 more commonly used from XMPP). Instead of relying on the system’s trust, the app has hard-coded 3 SHA256 CA fingerprints into the app. This makes it particularly difficult to sniff the encrypted traffic using a proxy like SSLSplit, as we cannot rely on the app to trust the custom CA certificates we provide the Android OS.
Additionally, if the initial XMPP messages are not established, all remote functionality is disabled, as in 3.11.
From viewing the configuration files and the decompiled APK, we can determine that
XMPP is used for control commands. That is, requesting to connect to an established partner, and sending vibration patterns. In fact, the app stores the trusted partner’s
38 Figure 3.11. Attempting to break SSL results in disabling of remote functionality
XMPP username — which appears to be randomly generated — and uses this to initi- ate a session when one partner wishes to connect. An example of this username would be
“[email protected]”. The user’s own credentials appear to be base-64 encoded and obscured.
+Mg2hpC12HgrpglJr8vOs
Outside of control commands, actual chat (including voice and video chat) and vibrator remote control appears to be performed by Twilio, an external service which uses the ICE
39 protocol with STUN and TURN to set up a WebRTC session. WebRTC is a real-time communications protocol that allows clients to stream audio, video, and data without the need for plugins. In order to authenticate with the Twilio service, the clients need to obtain session tokens. The way the tokens are received is interesting. The client makes a request to https://tools.sic-apps.net/webrtc/ get token.php, which will fail if the correct HTTP user-agent headers are not set (mainly,
X-User-Agent should be set to sicapps), which attempts to restrict usage to the WeConnect application. The PHP script returns a list of STUN and TURN servers, with usernames and credentials. By using these servers, Twilio is able to set up a secure connection between the clients. Twilio requires account credentials to return those Network Traversal Service
Tokens, and so the request to Twilio itself should be made from the sic-apps server, which will give the client Android device the session tokens.
This app goes out of its way to protect the privacy of its users. All communications are encrypted, and there are barriers in place to prevent man-in-the-middle attacks, even by the owner of the device. No identifying information is tied to the account: authentication information is randomly generated and abstracted away. The app does appear to use Google
Analytics, but no other major form of analytics. Finally, the choice to block screenshots and disable notifications by default are good privacy practices.
While it is possible for someone who is sniffing traffic to discover that a user is carrying a vibrator session with a remote user, it is not immediately obvious. The IP addresses used during set-up appear to be dedicated to WeVibe traffic, so if one knew the WeVibe IPs, he could make a correlation. However, there are no PTR records or whois information associated with these IPs that would immediately suggest that the traffic is intimate. Additionally, the domain name “sic-apps.net” (Standard Innovation Corperation Apps), which would appear in DNS queries and the unencrypted part of a SSL handshake (specifically SERVER HELLO), is very discreet. This is contrary to other applications, which would contact domains that
40 are clearly vibrator sites (i.e. “chat.vibease.com” or “api.ohmibod.com”. In this way, both the data, and the metadata, are secure.
3.4.4 Kiiroo Pearl2 and Fleshlight Launch
All of the traffic from the app appeared to be encrypted via TLS or QUIC encryption, ex- cept for downloading firmware. On connection, the application makes a request to http:
//feel-technologies.com/firmware — a JSON document which lists (https) urls to hex- adecimal firmware files. A theoretical attacker could update this document to point to his own files, perhaps adding a backdoor in the BLE connection protocol, allowing his phone or computer to take control of the device at any time. However, given that the firmware is a list of hexadecimal numbers, reverse-engineering it would prove extremely difficult.
Fortunately, the other IP traffic seemed secure. The PubNub channels, used to send device intensity data to the phone, were protected with a secret key. One interesting security feature was the use of JSON Web Tokens (JWT) in data sent from the server to the client, such as rooms to connect to, or establishing a shared session. These tokens contain data along with a HMAC-SHA256 signature. In this way, a user cannot modify the included data without obtaining the server’s secret key and modifying the signature, and the server can verify the data has not been altered when the JWT is sent back. While we were able to intercept the data by installing a custom CA Certificate on our phone, the use of Globally
Unique Identifiers (GUID) and channel-based architecture makes a web-based attack via the
API unlikely.
From a privacy perspective, even though most of the data is encrypted and the servers contacted are Amazon Web Services IPs, the domain names queried could still provide some metadata to network sniffers. We saw DNS queries and SSL handshakes to feel-technologies. com and api.feel-app.com, which may reveal that the user is using an intimate device to someone sniffing the network.
41 3.4.5 Lovense Nora and Max
All Lovense traffic we saw was encrypted via TLS, and we were unable to successfully in- tercept SSL traffic with SSLSplit. However, by introspecting the APK, we were able to find some interesting results. While the decompiled app is partially obfuscated (i.e., many func- tions and variable names are replaced with a, b, etc.), we are still able to determine what it is doing.
Connections to trusted partners are established via XMPP in a TLS tunnel. Messages sent via XMPP are also encrypted via AES with Cypher Block Chaining mode (CBC).
However, the initialization vectors, AES keys, and cipher information are all hard-coded into the app in dc/alr.java, making them public to anyone who chooses to decompile the app and rendering the encryption useless. However, given that the messages are already in an encrypted tunnel to the Lovense servers, it does not actually open up any vectors for attack. Interestingly, this encryption is also applied to potentially sensitive application data stored on the device, such as the user’s password and message logs.
A potential privacy issue we found is that the XMPP usernames used to communicate with trusted partners is simply the email address the user provided during registration.
While we were unable to see the XMPP usernames of random accounts, it is possible to retrieve the email addresses of trusted partners. Given the requests for connections we found advertised in the titles of vibration patterns users had published, we believe it is likely two strangers may connect believing to be anonymous, and then an attacker could retrieve their new partner’s email address and use it to find more information about them.
3.5 Conclusions
In this paper we have performed a first study of sexual intimacy in the age of IoT devices.
Because of moral disapproval, social stigma, and even because of laws banning some of these
42 devices, the privacy practices of smart sexual devices need to be held to higher standards than other less-sensitive devices. In addition, because the possibility of remote sexual assault, manufacturers also need to follow take authentication and integrity as high priorities. In the three devices we analyzed we can see systematic problems, from Bluetooth prob- lems to app problems. For Bluetooth, one of the easier practices to improve on is on providing anonymity services for the device (which should be available in most BLE devices). A sec- ond recommendation is to improve the pairing practices of these devices and to guarantee connections with secure token keys. Apps and cloud servers should also be more careful with user data, minimizing information about users, and improving authentication and encryption practices.
43 CHAPTER 4
CONCLUSION
In this thesis, we have emphasized the importance of security and privacy in IoT Smart Home hubs and intimate devices. These devices exist at the intersection between the internet and our personal lives. As such, security risks could have real-life consequences for the safety and privacy of their users. Unfortunately, we found several vulnerabilities in the products we studied. However, we were very pleased by the responsible companies’ responses to the vulnerabil- ities. We informed Vibease and OhMiBod of the issues we found on August 25th, claiming CVE-2017-14486 and CVE-2017-14487. Both manufacturers responded quickly, recognizing the issue, along with their intentions to fix them. Vibease released a new version of their app on September 17th, and publicly acknowledged us on the security page of their web- site. OhMiBod also released an update to their API servers on November 3rd, preventing other user’s tokens from appearing in a search. They completely redesigned their app and published that update several months later.
44 REFERENCES
Apthorpe, N., D. Reisman, and N. Feamster (2017). Closing the blinds: Four strategies for protecting smart home privacy from network observers. CoRR abs/1705.06809.
Editor Peter Saint-Andre. Jabber Software Foundation (2004, Oct). Rfc 3921: Extensible messaging and presence protocol (xmpp): Instant messaging and presence. https://xmpp.org/rfcs/rfc3921.html.
EUosbserver, P. T. (2017). Sex toys and smart robots: Who’s liable? https://euobserver.com/science/137456.
Herald, M. (2004). A bedroom of one’s own: Morality and sexual privacy after lawrence v. texas. Yale JL &. Feminism 16, 1.
Jose, A. C. and R. Malekian (2017, July). Improving smart home security: Integrating logical sensing into smart home. IEEE Sensors Journal 17 (13), 4269–4286.
Limited, D. (2017). Darktrace Global Threat Report 2017. https://www.darktrace.com/resources/wp-global-threat-report-2017.pdf.
Motherboard, D. O. (2016). The internet of dildos is watching you. https://motherboard.vice.com/read/dildo-data-hacking.
Motherboard, J. C. (2017, Aug). We anonymously controlled a dildo through the tor network. https://motherboard.vice.com/en us/article/wjnwgb/we-anonymously- controlled-a-dildo-through-the-tor-network.
Possolo, M. (2013). Morals legislation after lawrence: Can states criminalize the sale of sexual devices? Stan. L. Rev. 65, 565–1371.
Project, A. O. S. (2017). Requesting permissions. https://developer.android.com/guide/topics/permissions/requesting.html.
Radio, C. D. N. P. (2017). Vibrator maker to pay millions over claims it secretly tracked use. http://www.npr.org/sections/thetwo-way/2017/03/14/520123490/ vibrator-maker-to-pay-millions-over-claims-it-secretly-tracked-use.
Register, I. T. T. (2016). Your Intimate Personal Massager –Cough– Is Spying on You. http://www.theregister.co.uk/2016/08/07/ your sec toy is spying on you hackers crack our plastic pals.
Ryan, M. (2017). Crackle. https://github.com/mikeryan/crackle.
45 Sharkey, N., A. van Wynsberghe, S. Robbins, and E. Hancock (2017, July). Our sexual future with robots. Foundation for Responsible Robotics.
Sinn, R., V. Mohite, and S. Sharma. (2008, Oct). An analysis of xmpp security. Technical report, San Jose State University.
Struening, K. (1996). Privacy and sexuality in a society divided over moral culture. Political research quarterly 49 (3), 505–523.
Times, L. S. N. Y. (2016). Gay and Transgender Egyptians Harassed and entrapped, Are Driven Underground. https://www.nytimes.com/2016/08/11/world/africa/ gay-egyptians-surveilled-and-entrapped-are-driven-underground.html.
Today, E. A. M. U. (2016). Woman sues sex-toy maker for invading privacy. http://www.usatoday.com/story/news/2016/09/15/ woman-sues-sex-toy-maker-invading-privacy/90400592/.
Vibease (2014a). Vibease chat. https://itunes.apple.com/us/app/swinger-safari-2-0/id933024993?mt=8.
Vibease (2014b). Wireless remote vibrator. https://play.google.com/store/apps/details?id=com.vibease.ap3.
Wynn, M., K. Tillotson, R. Kao, A. Calderon, A. Murillo, J. Camargo, R. Mantilla, B. Rangel, A. A. Cardenas, and S. Rueda (2017). Sexual intimacy in the age of smart devices: Are we practicing safe iot? In Proceedings of the 2017 Workshop on Internet of Things Security and Privacy, IoTS&P ’17, New York, NY, USA, pp. 25–30. ACM.
46 BIOGRAPHICAL SKETCH
Matthew A. Wynn is from Austin, Texas. After graduating from homeschool in 2014, he attended The University of Texas at Dallas, where he received a Bachelor’s of Science in Computer Science in May 2017. He then entered the Master’s program at The University of Texas at Dallas. During the summers of 2016 and 2017, he interned at investment firms Dimensional Fund Advisors and Charles Schwab, working in web development and big data. In June 2018, he will begin working for Home Depot Technology Center.
47 CURRICULUM VITAE
Q [email protected] matthewwynn.com m-wynn Matthew Wynn ¯ wynnmatthew
Education May 2017 BS in Computer Science, University of Texas at Dallas, Richardson, TX. + Academic Excellence Scholarship recipient + Hobson Wildenthal Honors College member Expected May MS in Computer Science, University of Texas at Dallas, Richardson, TX. 2018 Information Assurance Track
Employment History Summer 2017 Big Data Intern, Charles Schwab, Austin, Texas. + Rewrite Hive big-data scripts in Spark, simplifying logic and configuring partitioning to achieve up to a 35x speedup. + Determine and document best practices and performance techniques for Spark scripts. Summer 2016 Technology Intern, Dimensional Fund Advisors, Austin, Texas. + Create docker images for hermetic unit-testing environments. + Investigate docker-based Platform as a Service (PaaS) solutions. + Create continuous integration jobs in Jenkins. + Solve various problems involving Django, LDAP, Kerberos, and configuration management.
Activities and Projects Fall 2017 “Workshop on Internet of Things Security and Privacy” Presenter, ACM CCS. Lead author, presenter: “Sexual Intimacy in the Age of Smart Devices: Are We Practicing Safe IoT?” Spring 2016 “Topics in Enterprise Networking” Class Co-Instructor, Hobson Wildenthal Hon- ors College. Presented a semester-long survey of the techniques and technologies used in enterprise net- works to a class in the Honors College. Class included the TCP/IP stack, as well as concepts such as configuration management, service level agreements, and directory services. Aug. 2015 – 2018 Systems Administrator, Collegium V, University of Texas at Dallas. Maintain, administrate, and automate of a high-availability network lab for the students of the Collegium V Honors Program at UT Dallas, enforce high security standards and best practices, and contribute to the open-source deployment configuration. Jan. 2015 – 2018 Treasurer, Vice President, Linux Users Group, University of Texas at Dallas. Plan, promote, and execute events and activities for the Linux Users Group, teaching, advo- cating, and providing resources for learning Linux, open source, and free software. + Give presentations on Linux-related technologies such as Git. + Maintain internal and external projects, including contributions to the Void Linux distribution.