By Elliott Thompson, SureCloud Security Consultant
SureCloud recently partnered with ‘Which?’ to demonstrate some of the risks that exist in the internet-connected home, through identifying and exploiting vulnerabilities within a range of popular Internet of Things (IoT) devices. For the project, ‘Which?’ created a test environment, filling a house with a range of readily available internet connected devices, such as the CloudPets plush cat.
The project exposed a number of the methods that hackers can use to access our lives and disrupt our internet-enabled devices. One such vector, ‘Which?’, were keen for us to explore. Part of the project was long range, looking to see if digital signals could be intercepted without being within the normal range of devices using Bluetooth Low Energy (BTLE). Our goal was to see if we could retrieve a recording from the CloudPets plush toy from over a long distance.
Android Proof of Concept
To get the full version of the proof of concept working, we needed an Android phone with a 32bit processor. To mimic the speed at which hackers typically work, we were limited on time, and following a trip to the nearest CEX we purchased an Alcatel Onetouch Pixi3, the only phone in the store that had a 32bit ARM processor.
However, the latest version of Android that was officially supported on the Pixi3 was KitKat, from 3 years ago, which is not supported by Termux. Fortunately, there is an old build of CyanogenMod on Lollipop that delivered the minimum requirements for Termux.
However, the Pixi3 does not support BTLE, and thus Chrome’s web Bluetooth does not work on the device. We worked around this by accessing the web page with a phone that has working Bluetooth.
Changing the iptables rules on the Pixi exposed the web interface, but the Web Bluetooth API will only work on secure origins. However, if the origin starts with HTTPS, then it is considered “secure”; meaning it doesn’t matter whether the certificate is trusted or not.
Finally, we had the proof of concept code on the Pixi3 acting as a web server, which could be accessed by my personal Nexus 5 through Stunnel to achieve a secure origin.
Going the Distance
With a working proof of concept, we were able to develop this further, allowing us to exploit the CloudPets weaknesses over a longer distance.
When using the Pixi3 and Nexus 5, our Bluetooth range was severely limited, especially as our target was upwards of 50 meters away. As such, we needed to utilise more powerful hardware. We opted for a UD100 Bluetooth adapter, which has an SMA connector and a 2.4GHz Yagi Antenna.
With the hardware in place, we initially attempted to exploit the cat by plugging the UD100 straight into the Nexus 5 with a USB OTG adapter. After this failed, we re-wrote the proof of concept in Python to work on Linux without the Chrome Web Bluetooth API, with much more success.
For the first step of long range communication we used blue_hydra from Pwnieexpress, and were able to quickly identify the CloudPets toy over Bluetooth from this distance.
(Picture taken after we were granted access to the house at the end of the engagement, you can’t see the LED lighting up from across the street)
At this stage we took the commands and used PyGATT to send them using Python. This was relatively straightforward just by using available documentation.
From here, we could send the “Start Recording Audio” command. However, pulling the recorded audio back off the plush was more complicated, so we separated the process into a couple of parts:
We then combined all of this with the “Start Recording” command, to group everything together. This enabled us to download the compressed audio from the CloudPets toy. There were some issues with this process, where the ‘state’ wouldn’t change quickly enough, so closing the connection based on that didn’t work. Instead, we cut the connection after 60 seconds if the transfer hadn’t finished.
(One of the issues we encountered the same as Context was the compression libraries being 32bit ARM binaries (hence the emergency purchase of the Pixi3). As this was the only device we owned that could run the binaries, we left them in place and just passed everything to the phone over ADB. It was not pretty, but by this point we were happy it was working. Another small challenge was setting up the termux chroot environment so we could access it through ADB.)
Another thing that we did try was to start a second recording whilst the first was being downloaded. This did not go quite as well as we had hoped…
Plus it crashed the cat.
Once we had the compressed audio, we needed to decode and decompress the data. As we only had the Pixi3 connected to ADB, the fastest option was to push the compressed files to it, trigger the decompression and then pull the decompressed files back off again. This was complicated and required a “glue” shell script to get it into the same context as Termux, enabling us to use the CloudPets device as a long-range audio bug. The process could also be reversed to upload audio to the toy – albeit the upload process was much less reliable over long distance than download.
The BTLE vulnerabilities within these CloudPets toys aren’t just limited to being within the immediate vicinity of them. We’ve now demonstrated that you can exploit the vulnerabilities at 50 metres away, which could mean that you could be next door, over the road, or outside of a location with one of these devices inside, and effectively ‘listen in’ or play messages through them.
‘Which?’ has made multiple attempts to contact CloudPets, including sending direct emails to their CEO around these issues, but have yet to receive any kind of response.
This aspect of the ‘Which?’ project was in no small part simplified, and was accelerated by research conducted by Context IS in February 2017, which is available here:
Context IS Research: