As internet of things (IoT) devices continue to seep into our homes and offer an increasingly wide range of features, new concerns are beginning to arise about the security of the data processed by these devices. Although they’ve been subject to countless security breaches that led to the exposure of people’s login details, financial information and geographical location, among others, there are few kinds of data with more potential to harm users than those relating to their sexual preferences and behavior.

With new models of smart sex toys entering the market all the time, we might think that progress is being made in strengthening the mechanisms that ensure good practices in the processing of user information. However, our research revealed interesting security flaws derived from both the implementation of the apps controlling the devices and the design of these devices, affecting the storage and processing of information. Today, these findings are more relevant than ever, since we are seeing a rapid rise in sex toy sales as a reflection of the current situation around the world and social distancing measures related to COVID-19.

As is the case with any other IoT device, there are certain threats to privacy when using internet-enabled adult toys. Vulnerabilities could allow attackers to execute malicious code on the device, or to lock it preventing the user from sending any command to the toy. In fact, we have already seen real-case scenarios involving similar attacks, as researchers have found ransomware aimed at locking vulnerable chastity belts while the devices are in use and demanding that the victims pay a ransom to unlock the gizmos and free themselves.

Characteristics of smart sex toys

Nowadays, smart sex toys exhibit many features: remote control across the Internet, group chats, multimedia messages, videoconferences, synchronization with songs or audiobooks, and the capacity to connect with smart assistants, to name a few. Some models can synchronize to replicate their movements, and some others are wearables.

In terms of architecture, most of these devices can be controlled via Bluetooth Low Energy (BLE) from an app installed on a smartphone. The app is responsible for setting any options on the device and controlling the user’s authentication process. To do so, it connects to a server in the cloud, which stores the person’s account information. In some cases, this cloud service also acts as an intermediary between partners using features like chat, videoconferencing and file transfers, or even giving remote control of their devices to a partner.

Figure 1. Architecture of a smart sex toy

This architecture presents several weak spots that could be used to compromise the security of the data being processed: Intercepting the local communication between the controlling app and the device, between the app and the cloud, between the remote phone and the cloud, or directly attacking the cloud-based service. Despite the fact they have already been subjected to the scrutiny of many security researchers ([1], [2], [3], [4], among others), our investigation demonstrated that these devices continue to contain security flaws that could threaten the security of the data stored as well as the user’s privacy and even safety.

Why is security so critical when it comes to sex toys?

As one can imagine, the sensitivity of the information processed by sex toys is extremely critical: Names, sexual or gender orientation, lists of sexual partners, information about device usage, intimate photos and videos – all these pieces of information can have disastrous consequences if they fall into the wrong hands. New forms of sextortion appear on the radar if we consider the intimate material accessible through the apps that control these devices.

In addition to concerns about privacy, smart sex toys are not exempt from the possibility of being compromised by cyberattackers either. Regarding vulnerabilities in a sex toy’s controlling app, an attacker could take control of the toy leading to DoS (denial of service) attacks that block any commands from being delivered, or a device that is weaponized in order to carry out malicious actions and propagate malware, or even a device deliberately modified to cause physical harm to the user, such as by overheating.

And finally, what are the consequences of someone being able to take control of a sexual device without consent, while it is being used, and send different commands to the device? Is an attack on a sexual device sexual abuse and could it even lead to a sexual assault charge?

Security evaluation of two popular devices

The purpose of this research was to determine the level of security in Android apps created to control the most popular models sold by the main brands of sexual pleasure devices and so establish to what extent they ensure the confidentiality of their users’ data. The analysis is based on two models: Max by Lovense and We-Vibe Jive.

The following sections detail some of the security issues we found for each app and device. Both developers were sent a detailed report of the vulnerabilities and suggestions for how to fix them. At the time of publication of this article, all vulnerabilities have been addressed. We would like to thank WOW Tech Group and Lovense for their cooperation in dealing with the reported issues.

Bluetooth (BLE) Connection

Since in this protocol the peripheral device needs to be continually announcing its connection so the user can connect to it, anyone can use a simple Bluetooth scanner to find these devices in their vicinity.

Figure 2. Discovery of sex toys available in the immediate vicinity, through a Bluetooth scanner

Figure 2 shows how easily these devices can be found with a mobile Bluetooth scanner. In the scanner we can see both Jive and Max and detailed information. Jive announces itself with its model name, making it very easy to identify. Also, the power of its signal is -69 dBm. As the scanner approaches the device, this power level will increase, allowing its owner to be located.

Both Jive and Max are paired using the “Just Works” method, which is the least secure of all BLE pairing methods. In this method, the temporary key used by the devices during the second stage of pairing is set at 0, and the devices then generate the value of the short-term key on this basis. This method is widely open to man-in-the-middle (MitM) attacks, as any device can connect using 0 as the temporary key. In practical terms, this means the Jive and Max will bond automatically with any mobile phone, tablet, or computer that requests them to do so, without carrying out any verification or authentication.

In the following proof of concept, the BtleJuice framework and two BLE dongles were used to replicate an MitM attack between a user and the Jive. In this simulated scenario, an attacker first takes control of a Jive, which can be connected to directly due to its lack of authentication, and then announces a dummy Jive device, which is set up based on the information that the original Jive announced. Next, when the user decides to connect to the toy, the user’s device actually connects to the fake device advertised by the attacker. The attacker then can, via the BtleJuice web interface, capture all of the packets sent by the user and intended for the toy and thereby obtain information about the modes of use, intensity of vibration, etc. The attacker can also edit the commands intercepted, changing the vibration mode or intensity or generate his own commands and send them to the toy, even if the user is not interacting with it.

In the case of the Jive device, these risks are increased due to the fact that it's a wearable, designed for the user to be able to wear it as they go about their day, at restaurants, parties, hotels, or in any other public location.

Lovense remote control through the brute forcing of tokens

The Lovense app’s list of options for its remote-control features includes the option to generate a URL in the format https://api2.lovense.com/c/<TOKEN>, where <TOKEN> is a combination of four alphanumeric characters. This allows remote users to control the device simply by entering the URL into their browsers.

Surprisingly for such a short token with relatively few possible combinations (1,679,616 possible tokens on an app with over a million downloads), the server does not have any protection against brute-force attacks.

When a query is made using a nonexistent token, the server redirects to /redirect and returns the JSON message {"result":true,"code":404,"message":"Page Not Found"}. However, if the token is valid, the server redirects to another URL in the format https://[apps|api2].lovense.com/app/ws/play/<SID>, which in turn redirects to https://[apps|api2].lovense.com/app/ws2/play/<SID>, where <SID> is the session ID: an MD5-like string that identifies the user and the ID of the device for which it was created. A token expires when its time limit is up (presumably 30 minutes), or when someone visits the final URL after going through the whole redirection process. However, some tokens remained active after the half hour was up, even for days.

Since it is possible to distinguish between valid tokens, active tokens, and expired tokens, depending on the response from the server, we created a proof of concept to find valid tokens by brute force. In the video, first we listed dozens of tokens: we created some of them with our device, and then added other random tokens. Most of the tokens generated by our device had already expired, but one was still active. Then we programmed a simple Python script and we used it against this set of tokens. When this script finds a valid token, it opens the final URL in the browser and checks if the session has expired with the help of a Chrome extension we designed for the purpose of this research. If the session is found to be active, it sends a message through a Telegram bot to the specified account, notifying it of the new control panel found. We recorded a proof of concept video, available here:

Working alongside the vendor, we were able to confirm that it was possible to find tokens from random users using brute force. This is an extremely serious vulnerability, as it allows an attacker to easily carry out remote hijacking of devices that are expecting connections through active tokens, without the user’s consent or knowledge.

Other privacy concerns

Regarding the applications that control these toys (Lovense Remote and We-Connect), some controversial design choices were found that may threaten the users’ privacy. This could be very dangerous, since many users grant control of their devices to complete strangers by sharing their tokens online, either as a personal preference or as part of a “cam girl/boy” service.

In Lovense Remote, there was no end-to-end encryption, screen captures were not disabled, the “delete” option in the chat did not actually erase messages from the remote phone, and users could download and forward content from others without a warning being sent to the content originator. Also, each email address is shared among all the phones involved in each chat, and is stored in plain text in many locations, such as the shared preferences file wear_share_data.xml. So, malicious users could find the email addresses associated with any given username and vice versa.

Finally, Lovense Remote does not implement certificate pinning for firmware updates; and as the decryption keys are stored within the app’s code, it would be relatively simple for an attacker to create a script to intercept the packets and redirect the victim to the attacker's malicious URL to download a fake firmware upgrade.

In the We-Connect app, sensitive metadata was not being stripped from files before they were sent, which means that users may have been inadvertently sending information about their devices and their exact geolocation when sexting with other users. Finally, the four-digit PIN to access the application can be easily brute forced by using a bad USB (proof of concept).

Conclusions

Smart sex toys are gaining popularity as part of the concept of “sexnology”: a combination of sex and technology. The latest advances in the industry include models with VR (Virtual Reality) capabilities and artificial intelligence-powered sex robots that include cameras, microphones, as well as voice analysis capabilities based on artificial intelligence techniques. Indeed, one could say the era of smart sex toys is just beginning.

As with any other IoT device, there is no bulletproof solution to assess and secure smart sex toys. As data protection depends largely on the best practices adopted by end users, it becomes a priority to educate consumers on the security and privacy risks associated with these adult toys.

Moreover, mobile apps like these smart sex toy control apps handle very valuable information from their users. It is critical for developers to understand the importance of spending the time and effort necessary to design and create secure systems, without succumbing to market pressures that prioritize speed over security. Neglecting the proper configuration of the production environment in favor of rapid deployment should never be an option.

The full white paper is available here: