Bluetooth and Personal Protection Device Security Analysis
Looking at the ROAR, Wearsafe and Revolar personal protection devices - commonly used by women for personal safety but increasingly by other segments of the population including protesters, human rights workers, and the like - we discovered a few flaws or “gotchas” involving Bluetooth for the Wearsafe and Revolar (ROAR looked good):
While it wasn’t nearly as easy to remotely track a Revolar owner, it is still possible to track the owner of either the Revolar or Wearsafe device from a distance via Bluetooth with inexpensive antennas that extend the scanning range.
Both devices allow for Bluetooth scanning to identify the device as a personal protection device. Both devices allow for somewhat insecure Bluetooth pairing.
The Wearsafe product is subject to a denial of service attack that prevents the device from performing its main functions.
Personal protection devices are small physical devices that allow users to discreetly press a button to signal to friends that they’re in a potentially dicey situation, particularly if the act of pulling out and using their phone would cause a situation to escalate to something more serious.
The small devices use Bluetooth to talk to the phone, and by using a companion app on that phone that gathers GPS data, a list of friends can be sent a warning message about where the user is. There are usually multiple alerts with different meanings:
- This could involve a check-in (“I have arrived at a place and all is ok”)
- A potential danger (“The place I am at looks fairly sketchy”)
- Or immediate danger (“There is a bad person/situation confronting me, I am in immediate need of physical assistance”).
The alerts are triggered by pressing a button on the physical device, with one click meaning one thing and multiple clicks meaning something else.
The common scenarios are as follows:
- The user is a woman, and she has been stalked by someone. While she is out, she either sees or is confronted by the stalker. She’s afraid that if she gets out her phone it might cause her stalker to rush and grab her phone before she can call a friend or 911. By discreetly pushing a button on her personal protection device, she can send a warning with her location without triggering a physical confrontation that could occur if she got out her phone.
- A protester under a repressive regime is out marching. Suddenly, the protesters are surrounded by armed government thugs. If the protesters get out their phones, they might be arrested if it looks like they are filming the event or calling their friends. A discreet button press on a personal protection device can send a message to their friend with their location and that they are in danger. The friends could contact international press in the area to go investigate, based upon the GPS coordinates in the message.
As you can see, the need for the security for these devices is slightly different than many other Internet of Things (IoT) devices. There are both stalker victims and human rights workers who are afraid to wear Fitbits because they might be tracked, so purchasing one of these devices should allow the wearer to not just feel more secure, but actually be more secure. Between that and the increased use amongst human rights workers in foreign lands and protesters under duress from repressive authorities, security is of the utmost importance.
The devices are similar in that they require one to register themselves with the app to the vendor website, enroll recipients to get notifications from the user in the event that alerts are sent, and, of course, pair the device with the button to the phone via Bluetooth. There are multiple warnings that alert a recipient of a user’s situation, falling between a simple check-in to an all-out notification of immediate danger. All involve using the phone’s GPS coordinates.
When one approaches IoT, the most obvious thing is to go after the device itself and see if it can be compromised. In some cases, such as devices that are essentially small computers running a complete operating system, this makes sense. However, these devices usually operate autonomously and do not require frequent (or sometimes constant) communication with an app on a phone or getting data to the cloud.
Other times, an IoT device is intended to either communicate directly with the app on the phone, or it needs to move data from itself to the cloud and will use the phone as its router. In those cases, the point of attack changes; as by compromising a point on the communications path between app and cloud or by compromising just the phone, you stand the chance for more “impact,” particularly when dealing with a group of users that have adopted a technology - you could potentially compromise the entire group.
In this examination, we are looking at the Bluetooth side of things. From a Bluetooth perspective, personal protection devices pose two potential areas of threat - they could be tracked at the individual level, and they could be rendered inoperative via a remote attacker. We look at both approaches.
What To Check
Here is the current checklist Duo Labs usually goes through:
- Overall security stance of the device from a Bluetooth perspective.
- Secure Bluetooth pairing.
- Non-obvious names and values accessible via Bluetooth probing and scanning.
- Bluetooth stack on device not vulnerable to a denial-of-service attack.
- Design real-world attack scenarios, then try to connect the dots to see if they can be implemented using a combination of flaws found and existing limitations (or lack thereof) in the technology involved.
There is an immediate issue with using Bluetooth as the method for communication between device and phone - for the device to function, it requires the phone to have Bluetooth enabled. Keep in mind that some of the women that have purchased this product were afraid that they could be tracked via their FitBit (learned this from a friend who has worked with abused and harassed women). Turning on Bluetooth on your phone can have some unintended consequences.
The Apple iPhone, when Bluetooth is enabled, seems to remain in discoverable mode even after leaving the Bluetooth setup screen. According to multiple sources, including some on Apple’s website, it leaves discoverable mode when you leave the Bluetooth screen; however, every Bluetooth scanner says otherwise.
This means that if you use an iPhone to pair your personal protection device, you’ve just opened up the iPhone itself to tracking. A typical stalker would certainly be able to track via the phone itself, whereas the personal protection devices on occasion will go into discoverable mode as a part of their normal operation.
A dedicated stalker would eventually see the personal protection device, put two and two together, and adjust tactics accordingly. Currently, the only way to disable discoverable mode on an iPhone is to disable Bluetooth altogether, which kind of defeats the purpose since you cannot use your personal protection device without Bluetooth.
The Android could potentially do the same thing. However, by going into system settings (exact location may vary depending on the version of your OS), discoverable mode can be turned off, and a timer can be set to turn discoverable mode off if you’ve turned it on to pair to a device. The latest versions of the operating system already have discoverable mode turned off anyway, so the level of this particular risk is reduced.
At first glance, the Wearsafe product works as designed. There is a cumbersome element that involves getting the recipients of your warnings to install the app, and you have to subscribe to the service (a few dollars per month) before you can even start registering recipients. That said, once configured it works as designed.
Figure 1. The Wearsafe device.
The Bluetooth pairing process between phone and the Wearsafe device leaves something to be desired - as you pair, the phone says to enter the numeric code that appears on the device, which, of course, there is none.
However, the instructions state that the name of the Bluetooth device - in my case Tag-2292 - contains the numeric value for pairing. This means that instead of the hopelessly insecure “Just Works” method which essentially uses a hard-coded passkey of all zeroes, they are using the legacy 2.0 Bluetooth standard of a hard-coded 4-digit passkey, and they include the passkey in the Bluetooth device name.
Entering in 2292 allowed the pairing. While I could change the name of the device in the app, this was not pushed down or reflected in the device itself, which still advertised itself as Tag-2292. If they were going to do this, they could have simply gone with Just Works.
It should be noted that the serial number, verified by attaching to and querying the serial number GATT UUID (which starts with 0x00002a25), contains 2292 as the last four digits. Additionally, there was also a sticker on the underside of the lid of the Wearsafe device that had 2292 (see Figure 1).
Figure 2. Underside of the Wearsafe battery cover.
As soon as you plug the battery into the device, it begins advertising via Bluetooth. It seems to advertise nearly continuously, although there would be stretches where (according to the scanner) it would stop for maybe an hour or so, but would resume and continue in discoverable mode for hours on end. For the most part, it was on and letting the world know about its existence.
With the manufacturer set to “Wearsafe Labs, Inc.” and the device name of Tag-xxxx where xxxx is a four-digit number, it was more than easy to identify the device. With a free scanner app on a phone, the Wearsafe device was easily detected as long as you were within close range, and using a laptop along with a larger antenna, one could easily detect the device from longer distances (up to a quarter mile away with a $50 antenna, further with more powerful antenna). Coupled with the non-changing MAC address always starts with 40:54:E4, which is registered to Wearsafe Labs, Inc., it is easy to track the device from a slight distance, which kind of defeats the idea of having a stealth device.
Denial of Service
Regular types of denial of service did not impact the device, or at least initially seem to. The chip supports up to eight connections - so flooding the device with BLE connections did nothing if the connection with the paired phone was unbroken. However, once that phone connection came undone, the remaining connection was taken up and the device would not allow for connectivity from the phone to be re-established.
Since the BLE connection attempts were never completed and disconnected properly, the device was locked up from use, including the ability to send alerts. The only way to recover the device (letting it sit for up for 4 hours did not work) required a hard reset by removing and reinserting the battery.
It should be noted that repeated attacks did cause the battery to drain slightly quicker, but not enough to consider it a viable attack. For example, if the battery life were to last 21 days, at most the attacks probably knocked 2-3 days off of the life of the battery. Repeated attacks would drain the battery more substantially, but with the denial of service this seemed to be an unnecessary attack.
The app is easy to set up, and it is less work to get things configured to work than the Wearsafe. Additionally, it does not require the friends you are notifying to download the app, as it relies on both email and SMS for notifications. In general, while the device is more expensive than the Wearsafe, the entire process was less painless.
Figure 3. The Revolar device.
Bluetooth pairing is also an issue with Revolar. It will try to pair using Just Works, but it states in the documentation if you are prompted for a passkey to use “1234” (falling back to legacy 2.0 standards). Not exactly secure, but Revolar does make up for it in another way.
Once the battery is inserted, the Revolar device does not immediately start broadcasting its existence via discovery mode. Instead, to pair with the device, you have to hold down the button for 12-15 seconds to enter discovery mode, and then it can be paired with the phone.
After it has been paired, it goes into discovery mode to talk to the phone for roughly 30 seconds every 60 minutes. Otherwise, it is not discoverable via traditional scans, and direct probes to the MAC address of the device were unanswered. While still not perfect, this is a much more secure method of a device living in a Bluetooth world.
The manufacturer was listed as “Texas Instruments” and the name was listed as “Revolar,” which means the device is still trackable via Bluetooth scanning, although going into discovery mode once an hour creates a much smaller window.
Figure 4. Under the battery of the Revolar device.
Denial of Service
Attempts to cause the device to fail via denial of service did not work. Multiple attempts were made using a variety of techniques.
ROAR Personal Safety and Athena
The ROAR device, known as Athena, works with the ROAR Personal Safety app on your phone. Like the other two devices, you can trigger a couple of different alerts, however, Athena also has an alarm mode that clocks in at an impressive 90db with an attention-getting audio alert. This is a nice addition, as the user might be in a place where attention could be a helpful choice to consider in the event of a confrontation. So extra points for team ROAR for this.
Figure 5. The dark gray Athena device, for use with the ROAR Personal Safety app.
The pairing method is Just Works. Again, not really ideal, but at least there is no fallback to legacy 2.0 pairing. Like the Revolar, you have to trigger the device to start a pairing process, so this substantially reduces risk. That said, the security model implemented is rather impressive.
Athena has implemented the highest security settings, including LE Privacy, and this is in place before the device is even paired to the phone. Roughly every twenty minutes, a new MAC address is assigned. After pairing, if the Athena is triggered via a button press, the MAC address is cycled again. Even at the low level of Bluetooth, both privacy and security have been considered - most Bluetooth devices do not implement LE Privacy mode at all, so this is great to see.
The usual probing of the device turned out to be impossible. By using Secure Connection Only Mode, any connection to Athena requires authentication, and once paired, you cannot pair a second device. So the usual tricks of scanning the device with traditional Bluetooth hacking tools failed. Athena refused to give up any information at all.
Denial of Service
Like the Revolar, attempts to cause the Athena device to fail via denial of service did not work. Multiple attempts were made using a variety of techniques.
Here is a breakdown of issues looked at, and issues found.
|Possible Issue||Wearsafe||Revolar||ROAR (Athena)|
|Pairing method||Bluetooth 2.0 legacy 4 digit pin||Bluetooth 4.0 “Just Works” with fallback to 2.0 legacy 4 digit pin||Bluetooth 4.0 “Just Works”|
|Allows for multiple devices to pair||No||No||No|
|Bluetooth probing reveals too much info||Yes||Limited window, but yes||No|
|Trackable via scanning||Yes||Limited||No|
|Vulnerable to denial of service||Yes (flood of connections)||No||No|
|Uses additional security methods||No||Discovery mode enabled once per hour||Secure Connection Only Mode including LE Privacy|
Wearsafe Vulnerable to Bluetooth Tracking.
Using a Bluetooth scanner, including free scanners available for phones, it is possible to physically track the wearer of a Wearsafe device. The device is easily identified via the manufacturer, “Wearsafe Labs Inc” and name “Tag-xxxx” where xxxx is a four digit number - the same number used in the pairing process.
Recommendation to vendor: Only use discovery mode for pairing, and only periodically to check in via the phone app if needed. Implement Secure Connection Only Mode and LE Privacy from the Bluetooth specification - periodically rotate the MAC address used for advertising and after every battery change. Change the manufacturing name to something less obvious. Disable legacy 2.0 pairing support.
User remediation: Remove the battery in the Wearsafe device until right before entering a physical space where you might be threatened. While this is vague and in many cases defeating of the entire point of having the Wearsafe device to begin with, this is probably the best solution until a vendor fix is provided. If you are using iOS and have the Apple Watch, use the app for the Apple Watch from Wearsafe instead of the device (the Apple Watch uses LE Privacy), which will prevent tracking.
Wearsafe Vulnerable to Denial of Service.
Under a heavy load on connection requests, if the device becomes disconnected from the phone it is paired to, an attacker can fill the connection table, rendering the device unable to re-establish communication with the phone without a hard reset (temporarily remove the device’s battery). There is no indication in the app that this has occurred. Subsequently, activation of an alert via the device fails to go through the phone, with no indication of alert delivery failure.
Recommendation to vendor: Periodically time out spurious connections, perhaps more quickly when all connections are in use. Implementation of Secure Connection Only Mode will eliminate this issue.
User remediation: None. If the device is unable to connect to its paired phone, remove and replace the battery.
Revolar Vulnerable to Bluetooth Tracking.
Using a Bluetooth scanner, including free scanners available for phones, it is possible to physically track the wearer of a Revolar device. The device is easily identified via the name “Revolar.” In spite of the fact that discovery mode is used only periodically (once per hour) this still allows for a window in which tracking can occur.
Recommendation to vendor: Implement Secure Connection Only Mode and LE Privacy from the Bluetooth specification - periodically rotate the MAC address used for advertising and after every battery change. Disable legacy 2.0 pairing support.
User remediation: Remove the battery in the Revolar device until right before entering a physical space where you might be threatened. While this is vague and in many cases defeating of the entire point of having the Revolar device to begin with, this is probably the best solution until a vendor fix is provided.
There were no issues outside of the pairing process, but even that is mitigated to the point of not being an issue.
The main issue for the Wearsafe device involves the denial of service, and coupled with the ability to track the device, creates a rather nasty situation.
By scanning for Bluetooth devices, an attacker could recognize a Wearsafe device using inexpensive hacking tools, and could even detect a Wearsafe device from a distance with the proper antenna. Additionally, using the same hardware, it is possible to perform a denial of service by rapidly connecting to device repeatedly. Since Bluetooth, by nature, is not the most stable of communications, it will on occasion drop and then re-establish connections with paired devices.
A sustained connection attack against the Wearsafe device in a lab environment took advantage of this, and would result in the denial of service within 90 minutes on average. A dedicated attacker could locate the victim and launch the attack while the victim is stationary (at home in the evening, or while at their place of employment), even from a distance.
In the scenario of an attacker going after a victim, they can remotely disable the Wearsafe device and then simply use it as a tracking device to hone in on the victim. The attacker would be well aware that any attempt to use the device to notify others simply would not work, and perhaps be emboldened.
During our testing and reporting to Wearsafe, they asked for a video showing the denial of service attack in action. While originally made just for them, we thought we’d link to an edited version of it here for those that are interested.
The main issue for the Revolar is tracking of the device. While the window of tracking is slight, it is there and alerts an attacker that the potential victim is capable of remotely and quickly notifying others of their location. The main concern is that the attacker can adjust tactics (disguise, approach from behind, quickly restrain hands, etc.) to address the situation of the victim actually using the device.
As stated previously, it should be noted that all three products - Wearsafe, Revolar, and ROAR - require Bluetooth to be active on the phone the device is paired to. If your concern is that you can be physically tracked via Bluetooth by your personal protection device, whether that personal protection device can actually be tracked or not may not matter.
If your phone is an Android, many models allow you to turn off “discoverable” mode, and in recent models, discoverable mode is off by default. For the iPhone, turning on Bluetooth puts the phone in Bluetooth’s discoverable mode with no way to turn it off. A device in discoverable mode can be tracked.
Figure 6. Using the iPhone as a “personal protection device”.
For you iPhone users, you could use your phone as a personal protection device of sorts - by invoking Emergency SOS. If your iPhone is in your pocket, you could potentially get your hand in there to use that SOS to get help. This also disables Touch ID, which has the somewhat morbid side effect of preventing an attacker - who just rendered you unconscious - from using your fingerprint to try to thwart actions the SOS triggered. It should also be noted that this negates the need for turning on Bluetooth which makes your iPhone trackable.
For each reported vulnerability listed in the Vulnerability Summary section above, this is the vendor response to each one.
Oct. 18, 2017 - Contacted the vendor via email, 90 day clock started.
Oct. 25, 2017 - Wearsafe reported any vulnerability would be fixed in a future update.
Oct. 30, 2017 - Wearsafe requested a video demonstrating the vulnerability.
Nov. 01, 2017 - Video sent to Wearsafe, Wearsafe acknowledged and said they will work on the denial of service issue.
Nov. 09, 2017 - Wearsafe released an update to their app, version 1.10.2.
Jan. 05, 2018 - Have not received any further updates from Wearsafe, latest version appears to correct the Denial of Service issue. Assigned CVE ID.
Jan. 24, 2018 - Public release date.
Oct. 18, 2017 - Contacted the vendor via email. No response.
Oct. 24, 2017 - We learned that Revolar filed for bankruptcy and shut down operations on September 25, 2017, and this was eventually made public on October 24, 2017. On the FAQ portion of their site was this answer: “Please refer to our knowledge center to find answers to frequently asked questions. We no longer have customer support personnel who can respond to support issues.”
The retailers that carried Revolar products - Target, Best Buy, Brookstone, and others - continued to sell the devices until they had depleted their stock. The service still worked as of this writing and they are trying to sell off their technology to another company, but there is no guarantee the service will continue for any extended length of time.
Did We Cover Your Product?
There are a number of personal protection devices on the market, and the market is constantly changing. We were specifically covering products that included “devices” as the model of discreet device activation over pulling out the phone was an interesting one. There are other products out there with devices, and there are dozens of app-only devices that require one to interact with the phone (or, in some cases, a paired smart watch). If you are curious about one of these other products and have an urge to explore them as well, we do have a few resources to point you to:
Look at our analysis of a smart power tool, as it covers pulling apart applications and sniffing encrypted traffic by bypassing certificate pinning Bug Hunting: Drilling Into the Internet of Things. Our Bluetooth hacking blog post covers tools and their use, and was written during the testing of the personal protection devices: Bluetooth Hacking Tools Comparison.
Our exploration of hardware was honed on the ROAR Athena device: Examining Personal Protection Devices: Hardware and Firmware Research Methodology in Action. Our Bluetooth security explanation covers the different modes of security and privacy settings: Understanding Bluetooth Security.
There are a couple of issues to keep in mind when purchasing IoT devices - particularly those with security implications like personal protection devices. First, the device may be subject to an attack, even a simple one like the denial of service against the Wearsafe Tag. If this were a smart toaster, no one would care and we probably wouldn’t even report it, but this particular type of vulnerability is the exact wrong thing for such a device to have.
Second, a number of small startups like the Revolar seem great, only to go out of business in spite of having a decent product that is shipping. While it is hard to determine what the future may hold for any IoT device, it is a harsh reminder that it is a tough market filled with lots of promise and shiny newness that often fails, sometimes unexpectedly.
Given the patching, we’re willing to recommend either the Wearsafe Tag or the ROAR Athena. For the Wearsafe product, if you have the Apple Watch, you might consider using that in place of the tag as the Apple Watch Wearsafe app is riding on a much more secure platform, placing it much closer to the ROAR model in terms of security.
For me, the ease of the ROAR coupled with a lack of a monthly subscription service and advanced security, give it a distinct advantage. After using both and looking at the implemented security, I’d personally recommend the ROAR product due to the amount of care and thought in the security model.
Hopefully this evaluation helped inform you if you were planning on purchasing one of these devices, and we hope the evaluation process gave you some insight into how one approaches testing the security of such devices.