Multiple Bluetooth Low Energy (BLE) Tracker Vulnerabilities

Last updated at Mon, 22 Jan 2024 18:28:15 GMT

Executive Summary

While examining the functionality of three vendors' device tracker products, a number of issues surfaced that leak personally identifying geolocation data to unauthorized third parties. Attackers can leverage these vulnerabilities to locate individual users' devices, and in some cases, alter geolocation data for those devices. The table below briefly summarizes the twelve vulnerabilities identified across three products.

Credit

These issues were discovered by Deral Heiland and Adam Compton of Rapid7, Inc. and disclosed in accordance with Rapid7's disclosure policy.

Product Description

Bluetooth Low Energy (BLE) device trackers are small hardware tokens that are designed to be attached to personal items such as keyrings, wallets, or purses. These devices pair with the user's smartphone via Bluetooth, and can alert the user when the device moves out of range. The tracking hardware tokens themselves do not maintain network connections, but rely on associated smartphone apps to report geolocation data.

The devices examined were the TrackR Bravo from TrackR, the iTrack Easy from KKMCM.com, and the Nut from Zizai Tech. The Tile from TILE, Inc. was also examined, but none of these issues were discovered with this product, aside from a minor screenshot caching issue which does not appear to reveal private information.

Vulnerability Details

For each product, vulnerability details and possible mitigations are discussed below. Users concerned about these issues should reach out to their respective vendors using their normal support mechanisms, and update their mobile applications when fixes are released.

Until vendor-supplied fixes are available, the risks associated with these vulnerabilities should be weighed against the benefits of continuing to use these tracker devices and applications.

Most of the vulnerabilities described are only exploitable by an adversary who is in close physical proximity to the affected devices; the effective range of an exploit is noted on the summary table for each vendor.

R7-2016-18: Multiple Vulnerabilities in Trackr Bravo

The TrackR mobile app also caches screenshots when minimized; while no critical information appears to be exposed in this way, it is a best practice to clear unique data and use a generic application image for context switching.

R7-2016-18.1: Cleartext Password (CVE-2016-6538)

Examination of the TrackR Bravo mobile application running on an iPad revealed that the account password used to authenticate to the cloud API was stored in cleartext in the cache.db. Examining the cache.db file reveals the cleartext password as shown in Figure 1.

Given typical user habits of password reuse, this sort of password disclosure can impact other online services.

Mitigation for R7-2016-18.1

A vendor-supplied patch should configure the mobile app to prevent storing potentially sensitive information such as passwords in cleartext. While some local storage is likely necessary for normal functionality, such information should be stored in an encrypted format that requires device authentication.

Users are strongly advised to avoid reusing passwords between services whenever possible in order to limit the damaging effects of accidental or intentional exposure of account credentials.

R7-2016-18.2: Device Tracking ID Exposed (CVE-2016-6539)

The TrackR device ID can be obtained by being in close proximity to a TrackR device and utilizing a Bluetooth low energy (BLE) application to monitor for BLE devices. The TrackR ID is the manufacturer device ID, which is constructed of a manufacture identifier of four zeroes (0000), followed by the BLE MAC address in reverse (0f7c-XXXXXXd9) for a combined TrackR ID of 00000f7c-XXXXXXd9. This is shown in Figure 2.

Mitigation for R7-2016-18.2

A vendor-supplied patch should change the tracker ID so that is not directly related to the manufacturer device ID, nor the device's BLE MAC address.

Absent a vendor-supplied patch, users should be mindful of when they use the TrackR device in public spaces, as this ID can be reused on the cloud-hosted service to track devices (and therefore, the user) remotely as described in R7-2016-18.3.

R7-2016-18.3: Unauthenticated Access (CVE-2016-6540)

Unauthenticated access to the cloud-based service maintained by the vendor is allowed for querying or sending GPS data. Authentication appears to only be used to sync data back to the mobile application during application install or reinstall.

An adversary can access GPS data for any TrackR device from any web browser without authentication by using the tracker ID number (Figure 3), which can be discovered while being in Bluetooth range, as described above as R7-2016-18.2. The URL format is https://phonehalocloud.appspot.com/rest/tracker/00000f7c-XXXXXXd9.

Mitigation for R7-2016-18.3

A vendor-supplied patch to the cloud service should enable authentication before GPS data can be queried or written to the via the cloud service API.

Absent a vendor-supplied patch, users should be mindful of when they use the TrackR device in public which will expose the device ID, as described in R7-2016-18.2.

R7-2016-18.4: Unauthenticated Pairing (CVE-2016-6541)

TrackR Bravo device allows unauthenticated Bluetooth pairing, which allows unauthenticated connected applications to write data to various device attributes.

In the below example, this vulnerability allowed the device's advertised name to be changed via BLE - Generic Access 0x1800 Device name 0x2A00 as shown in Figure 4:

This lack of write access authorization also allows an adversary to enable the device's remote alarm, triggering the alarm to both cause annoyance and drain the device's battery. Figure 5 describes this access via "BLE - Generic Access 0x1802 Device name 0x2A06."

Mitigation for R7-2016-18.4

While the device is designed to pair with any nearby application to perform crowd-sourced, opportunistic geolocation services, a vendor-supplied patch should enable proper authenticated pairing for write access so only the authorized user's mobile application can pair and alter data on the device.

Absent a vendor-supplied patch, users should be mindful using the TrackR device in public spaces.

R7-2016-20: Multiple Vulnerabilities in iTrack Easy

The iTrack mobile app also caches screenshots when minimized; while no critical information appears to be exposed in this way, it is a best practice to clear unique data and use a generic application image for context switching.

R7-2016-20.1: Tracking ID Exposed (CVE-2016-6542)

The iTrack device tracking ID number, also called "LosserID" in the web API, can be obtained by being in range of an iTrack device. The tracker ID is the device's BLE MAC address, as shown in Figure 6.

Mitigations for R7-2016-20.1

A vendor-supplied patch should change the tracker ID so that is not directly related to the manufacturer device ID, nor the device's BLE MAC address.

Absent a vendor-supplied patch, users should be mindful of when they use the iTrack device in public spaces, as this ID can be reused on the cloud-hosted service to track devices (and therefore, the user) remotely as described in R7-2016-20.2 and R7-2016-20.3.

R7-2016-20.2: Duplicate Registration (CVE-2016-6543)

A captured device MAC/losserid can be registered under multiple user accounts, as seen in Figure 7, allowing shared access to the cmd:getgps data.

This getgps data value is set when an iTrack device comes into detection range of another user's iTrack mobile application. The mobile application then sets the getgps GPS data for that detected device's losserID with the cmd:setothergps.

This vulnerability can be exploited by an adversary to register the authorized user's device, and therefore gain access to GPS data any time the device comes in proximity of a running instance of the iTrack mobile application.

Mitigations for R7-2016-20.2

A vendor-supplied patch should prevent the duplicate registration of devices.

Absent a vendor-supplied patch, users should be mindful of using the iTrack device in public spaces, as described in R7-2016-20.1.

R7-2016-20.3: Unauthenticated Modification (CVE-2016-6544)

The getgps data can be written without authentication by setting the data using the parametercmd:setothergps. An example of this is shown in Figure 8.

This vulnerability can be exploited by an adversary to alter the GPS location data of a lost device.

Mitigations for R7-2016-20.3

A vendor-supplied patch should require authentication before allowing write access for the data stored for getgps.

R7-2016-20.4: Weak Session Management (CVE-2016-6545)

Session cookies are not used for maintaining valid sessions. The user's password is passed as a POST parameter over HTTPS using a base64 encoded passwd field on every request. An example of this is shown in Figure 9, collected using standard man-in-the-middle (MitM) techniques.

It is a best practice to manage web service sessions with session cookies, rather than resending the user's password. Session cookies can be expired or invalidated upstream after a timeout period or in the event of a compromise. In this implementation, sessions can only be terminated when the user changes the associated password.

Mitigations for R7-2016-20.4

A vendor-supplied patch should enable proper session management.

Absent a vendor-supplied patch, users should be mindful of when they use the iTrack device in public spaces and avoid connecting their mobile device to an unknown or open, public WiFi access point.

R7-2016-20.5: Cleartext, Base64-Encoded Password (CVE-2016-6546)

Examination of the iTrack Easy mobile application running on an iPad revealed that the account password used to authenticate to the cloud API was stored in a cleartext format in the cache.db. Examining the cache.db file reveals the base64-encoded password as shown in Figure 10.

Given typical user habits of password reuse, this sort of password disclosure can impact other online services.

Mitigation for R7-2016-20.5

A vendor-supplied patch should configure the mobile app to prevent storing potentially sensitive information such as passwords in cleartext. While some local storage is likely necessary for normal functionality, such information should be stored in an encrypted format that requires device authentication.

Users are strongly advised to avoid reusing passwords between services whenever possible in order to limit the damaging effects of accidental or intentional exposure of account credentials.

R7-2016-22: Multiple Vulnerabilities in Zizai Tech Nut

R7-2016-22.1: Cleartext Password (CVE-2016-6547)

Examination of the Zizai Tech Nut mobile application running on an iPad revealed that the account password used to authenticate to the cloud API was stored in cleartext in the cache.db. Examining the cache.db file reveals the cleartext password as shown in Figure 11.

Given typical user habits of password reuse, this sort of password disclosure can impact other online services.

Mitigation for R7-2016-22.1

A vendor-supplied patch should configure the mobile app to prevent storing potentially sensitive information such as passwords in cleartext. While some local storage is likely necessary for normal functionality, such information should be stored in an encrypted format that requires device authentication.

Users are strongly advised to avoid reusing passwords between services whenever possible in order to limit the damaging effects of accidental or intentional exposure of account credentials.

R7-2016-22.2: Session Token Leaked (CVE-2016-6548)

Examination of the Nut mobile application running on an iPad revealed three requests which communicated without encryption (HTTP, rather than HTTPS). These requests contained the user's authenticated session token within the URL. Examples of these URLs are shown in the table below.

An adversary can capture these requests and reuse the session token to gain full access to the user's account. An example of this technique is shown in Figure 12.

Mitigation for R7-2016-22.2

A vendor-supplied patch should configure the mobile app to always communicate over HTTPS, rather than the cleartext HTTP protocol. In addition, the mobile application should pass session tokens only via HTTP headers or as part of a POST request, rather than embedding the token in the URL.

Absent a vendor-supplied patch, users should be mindful of when they use the Nut mobile application in public spaces and avoid connecting their mobile device to an unknown or open, public WiFi access point.

R7-2016-22.3: Unauthenticated Pairing (CVE-2016-6549)

The Nut device allows unauthenticated Bluetooth pairing, which allows unauthenticated connected applications to write data to the device name attribute.

In the below example, this vulnerability allowed the device's advertised name to be changed via BLE - Generic Access 0x1800 Device name 0x2A00 as shown in Figure 13:

Mitigation for R7-2016-22.3

While the device is designed to pair with any nearby application to perform crowd-sourced, opportunistic geolocation services, a vendor-supplied patch should enable proper authenticated pairing for write access so only the authorized user's mobile application can pair and alter data on the device.

Absent a vendor-supplied patch, users should be mindful using the Nut device in public spaces.

Disclosure Timeline

This vulnerability is being disclosed in accordance with Rapid7's disclosure policy.

• Thu, Aug 25, 2016: Attempted contact with vendors.
• Fri, Sep 09, 2016: Disclosed details to CERT/CC as VU#617567, VU#974055, and VU#402847
• Fri, Sep 09, 2016: CVEs assigned by CERT/CC
• Mon, Oct 17, 2016: Disclosed R7-2016-18 to TrackR as issue #295585.
• Tue, Oct 25, 2016: Public Disclosure.