TrackR Tag - User’s True Coordinates Exposed (VU#762643)
TrackR Tag - affects user privacy by exposing the user’s real geo-location.
The TrackR Pixel Tracker
The TrackR Pixel is one of the tracking devices produced by TrackR, and for the purpose of this post, you can assume that all TrackR devices follow a similar design and behavior.
Here is how the TrackR Pixel looks-like:
This small tracker can remain powered for up to one year using the tiny battery that comes with it. The tracker pairs with the TrackR mobile application on Android, and the pairing process involves no authentication at all. The device advertises itself with the Bluetooth name “tkr”, and the Android app detects the tracker when the user presses the center of the device, which triggers its internal button. After that, the app pairs the tracker with the phone.
Before pairing the tracker, the user must create an account, so registration is required. This is where our analysis begins.
The Sweet Spot
One of the core functions of the TrackR mobile application is to help users locate their tracker when it is lost. This process works through a community-based system. While users are searching for their own trackers, the application also scans for any TrackR devices in range. When another tracker is detected, the application silently reports the tracker’s presence and the phone’s current coordinates to the server. This means every user is unknowingly helping others find their lost trackers.
Each tracker has a unique tracking ID. This ID is created by taking “0000” and appending the reversed hexadecimal representation of the tracker’s Bluetooth address. By using a web proxy, I examined the API calls and experimented with them. I discovered that anyone could track any TrackR device without any form of authorization. The only requirement was the Bluetooth device address of the tracker.
Because the tracker broadcasts its presence every few seconds when it is not connected to a phone, its Bluetooth address is publicly visible. Once the BDADDR is known, it can be used to track the user’s location.
Private Information Exposed
Users who own a TrackR device, such as the TrackR Pixel, often attach it to important personal items like their keys. Since people usually keep their keys near their mobile phone, the mobile device constantly knows the location of the tracker and regularly reports this information to the server.
If the user leaves their mobile phone in another place, for example at home, other users become the ones reporting the tracker’s location. This is not considered a bug. It is part of the intended design. TrackR uses a community-based tracking feature in which every TrackR user helps other owners locate missing or stolen items. The TrackR mobile application runs quietly in the background as a service, so the user does not need to open it for the reporting to occur.
The important point is that it does not matter whether the owner carries their phone with them or not. Other nearby users, without realizing it, will provide the tracker’s coordinates to the server. Due to the vulnerability described in this article, this system unintentionally exposes private information, because the server will reveal a user’s physical location to an attacker who knows the tracker’s Bluetooth address.
Spear Phishing and Specific Targets
Moreover, this tracker could be abused through social engineering techniques. For example, an attacker could give a tracker as a free gift and continue monitoring its location by using the tracking ID, which they would have recorded before handing the device to the victim. TrackR does not enforce any restriction that prevents multiple users from attaching the same tracker to their accounts. Although this scenario requires preparation, it becomes more realistic when the device is given or sold as a second-hand product.
Tracking Anyone and Everyone
By sending crafted HTTPS POST and GET requests to the vulnerable TrackR API, an authenticated attacker could retrieve sensitive information, such as the coordinates of users who own or carry the tracker. The only requirement is the tracker ID. Since the tracker ID is simply the reversed MAC address of the device, it can be obtained by anyone scanning for nearby Bluetooth devices, even with a regular Android phone.
When creating a tracker ID or attaching to an existing tracker ID, the application communicates with the server using a specific endpoint through a POST request.
To Create the Tracker ID or to attach to Tracker ID (if already created), the following URL is used (POST):
https://platform.thetrackr.com/rest/item?usertoken=…
payload = ‘{”customName”:”tracker_for_my_keys”,”type”:”Bluetooth”,”trackerId”:”00XXXX-XXXXXXXX”,”icon”:”trackr”,”timeElapsedSync”:304}’
r = requests.post(”https://platform.thetrackr.com/rest/item?usertoken=” + userToken, headers = headers, data = payload)To fetch all own devices (including the just-attached new device) — (GET):
https://platform.thetrackr.com/rest/item?usertoken=…
r = requests.get(”https://platform.thetrackr.com/rest/item?usertoken=” + userToken, headers = headers_get)
data = json.loads(r.text)Note: The token is generated at the login procedure and returned by the server.
GET /rest/user?email=yourmail%40domain.com&password=yourpass HTTP/1.1
PoC
Please note the Coordinates were altered - Also without auth.
def pushDevice(trackerId): # will always return of Not Found if not created before by the user
payload = '{"customName":"'+pickAName()+'","type":"Bluetooth","trackerId":"'+trackerId+'","icon":"trackr","lost":false,"timeElapsedSync":'+str(random.randint(100,1000))+'}'
url = "https://platform.thetrackr.com/rest/item/"+trackerId+"?usertoken=" + userTokenTo be more thorough about the kind of information that the server is able to retrieve, the following information is presented:
LastUpdated: So the attacker knows how fresh data is
Custom name: This is replaced by our custom name when we create/attach to the Tracker ID so it doesn’t make any sense for us
Last Known Location: The coordinates and how accurate these are (very accurate if you ask me)
Seen By Type: Who reported the last update (crowd or user)
Lost: If reported as lost
Battery Level: The level of tracker’s battery in percentage
Type: Bluetooth — I am not aware of all products of TrackR, but it seems most trackers are developed by using BLE technology
[
{
"lastKnownLocation": {
"latitude": 30.123455,
"lastSeenBy": {
"seenByType": "CROWD_LOCATE_USER",
"name": ""
},
"longitude": 30.112232,
"accuracy": 16
},
"ownershipOrder": 0,
"lastUpdated": 1581871440781,
"lost": false,
"lastTimeSeenDiff": 33670,
"customName": "mynew",
"ownersEmail": "MYMAILXXXX@gmail.com",
"timeUpdatedDiff": 685496,
"id": 5894866519982080,
"trackerId": "00005150-52d48gee",
"groupItem": false,
"batteryOrderUrl": "https://store.thetrackr.com/battery-replenishment-program?trackerId=9cac263f593abfb2&discount=BRP&token=d8005225b33088cf",
"batteryLevel": 5,
"type": "Bluetooth",
"lastKnownPlaces": [],
"lastTimeSeen": "Sun Feb 16 16:54:52 UTC 2020",
"icon": "trackr"
}
]Private Information Exposure Mitigation
Mitigating this type of privacy issue is not simple, because it requires changes in both software and hardware design. The core problem is that the tracker does not use any authentication mechanism during pairing. To address this, the tracker should implement a passkey or PIN-based authentication method, and the PIN should be provided on a physical label. This ensures that only the legitimate owner can pair, configure, or modify the tracker.
The Tracker ID should also be redesigned. Instead of using the reversed Bluetooth address, the Tracker ID should be a random value, at least ten bytes in size, and ideally sixteen bytes. This identifier should only be accessible to an authenticated user, and the user must know the passkey or PIN to retrieve it. With this approach, the low-power design of the device remains intact, while significantly improving its security.
If TrackR wants to continue supporting second-hand sales, it should allow the Tracker ID to be regenerated when the authenticated owner chooses to reset the device. This would prevent previous owners from tracking the device after transferring it to someone else.
Access to Unauthenticated Alarm Characteristic
The tracker does not implement any authorization mechanism, which means that anyone within Bluetooth range, typically around ten meters, can connect to the device and trigger its beeper. Because no security checks are in place, a malicious user could activate the alarm at any time. This type of action does not require sophisticated tools. It can be done with common Bluetooth applications available to the public, and it is simple enough that someone could create their own app in minutes.
The “beep” function corresponds to a standard Bluetooth SIG characteristic, and the values required to trigger the alarm are defined in the specification. The vendor implemented this characteristic correctly from a functional perspective, but without authorization, the device remains vulnerable.
To improve security, the tracker must enforce an authentication step before allowing access to its alarm characteristic. This would ensure that only the legitimate owner can trigger the beeper and interact with sensitive functionality.
Target Location Spoofing
The best part is when anybody, any non-registered user, can alter the current location of any tracker device, at any time.
It is found that the only thing that is needed to alter any tracker’s Coordinates is a single HTTPS PUT Request to a hashed-like path. I guess this is security through obscurity. The “secret” URL allows the submission of information by using unauthenticated access and should be avoided in the year 2020.
Location Spoofing Mitigation
Mitigating location spoofing is also challenging, because any user with the application is currently allowed to submit coordinates and a list of nearby tracker IDs. Under the existing design, the server cannot reliably distinguish a legitimate request from an illegitimate one.
The vendor should adopt the recommended mitigations described earlier. With proper authentication and a securely generated random Tracker ID, the server would know which devices belong to genuine owners. It would also recognize the correct random identifier associated with each tracker. This would allow the system to separate real tracker IDs from forged ones.
To further reduce the risk of brute-force attempts, the Tracker ID should be extended beyond the six bytes that are currently used. A larger random value significantly increases security. In addition, all location update requests should require authentication, so that only authorized devices can report coordinates to the server.
Impact
The TrackR was founded in 2009. It is quite funny how serious this vulnerability is, considering the scale of the company and the little complexity of such a product.
As of August 2017, over 5 million TrackR devices had been sold
Wikipedia
Google play reports ~20k Users to have the application installed and 1 million downloads, yet other applications exist on other platforms, pointing to the same vulnerable API.
Vulnerability Disclosure Time-table
15/02/2020 — Vulnerability Discovered
19/02/2020 — Vendor TrackR Notified via support email
28/02/2020 — Vendor TrackR Notified via support email
28/02/2020 — Vendor Adero Notified via adero.com (possibly parent company?)
04/03/2020 — Vendor TrackR notified via secondary sending email address
17/04/2020 — Cert Coordination Center Submission
25/04/2020 — Cert CC Replied with vendor’s contact info
6/05/2020 — Attempted to contact them multiple times
06/05/2020 — Published ( VU#762643 )