GPS trackers are designed to bring you greater peace of mind by helping you to locate your kids, your pets, and even your car. They can help keep the elderly or disabled safe by providing them with a simple SOS button to call for immediate help. Many devices are marketed for these purposes on common sites like Amazon and eBay and can be purchased for $25-$50 USD, making them more financially attractive than using a smartphone for some of the same capabilities.
But how much do we really know about these devices that always know where we are, and can sometimes even hear us (the majority of the devices we will discuss here have microphones too). It turns out that some GPS trackers today, especially those at the lower end of the market, should cause nightmares rather than bring peace of mind. Not only is their lack of security alarming, but these devices are more likely to make your loved ones more vulnerable, not less.
We decided to take a look at several child trackers available on Amazon, eBay, and Alibaba to see how they stood up to our scrutiny.
GPS Trackers basics
The GPS trackers available today use multiple communication channels and technologies. Figure 1 shows a typical architecture.
There are many transport protocols and layers involved, so we worked on many fronts at the same time to assess the security of these devices.
Usually, the tracker itself is a simple, inexpensive devices that carries a SOC (system on chip) module as the main component; a serial bus connects the SOC to a GPS module that provides a location as well as to a GPRS modem that connects to a SIM card which provides DATA+SMS capabilities to the device. Very often, you can also find a microphone and a speaker for phone functionality that is used when the “SOS” button is pressed.
We broke our research down into four categories:
- Analyze the onboarding process of a particular device
- Analyze web page and management portal if there is one
- Analyze traffic between Mobile application and the cloud
- Analyze the GPRS traffic between the tracker and the cloud
The real device and first touches
We decided to pick one tracker and do some more extensive research. We chose a tracker being marketed as “T8 Mini GPS Tracker” which fits on your keyring, has an SOS button, and two-way communication capabilities (speakers and microphone).
What first caught our eye was the onboarding process. The accompanying leaflet states:
As the instructions state, there is a web portal and a mobile application that you can use to manage the tracker. We took the path of least resistance and first opened a web application which is reachable at http://en.i365gps.com. It is wrong on so many levels:
As you can see the first red flag is that the login form is served over HTTP protocol, not over the more secure HTTPS. Moreover, you have two options to connect to the cloud: by using an account with username and password or using ID and password. Which one to pick? We turned to the leaflet for answers. It says:
This applies both for Android application as well as for web application. What is also an alarming fact is that last sentence: “…user needs to contact reseller to register a username if need to login by username.” Since you have to call the reseller to request a username, it’s fairly clear you are intended to use the ID, the password for which is “123456.” Not a good start.
For demonstration purposes, our ID was: 17032491112 and password 123456. When you log-in into the web you are welcomed by this interface.
Everything here is still transmitted over insecure HTTP protocol, and you can change your password, but you still cannot create an account. Let’s focus more on the ID.
The ID used as a username
The ID used as “username” for getting into the application is 11 digits long. As you can see on device information closeup (Figure 7), it’s sometimes referred to as an IMEI for “international mobile equipment identity.”
You can see the device is identified as T8S-49112 so that the last five digits are taken from the “IMEI” and the beginning is probably the model number. What’s strange here is that the number referred to as IMEI doesn’t fit the standard IMEI specification. According to the specification, IMEI should be 15 digits long where the last digit is a so-called control digit. When we searched a bit more we found full IMEI inside the tracker (Figure 8) itself and later also on a small sticker on the box. So in our case, the full IMEI was:
So when we take our “IMEI” and ID number and match them to the specification format, we’ll get
The first part of so-called TAC consists of various sub-parts, but for simplification, we can say that it is assigned to the vendor in much the same way as prefixes of MAC addresses. What it also means is that the numbers of all other trackers are predictable and you can easily enumerate them. In combination with a fixed password, that means we could log into about 25% of devices in this sequence of IMEI numbers.
Getting to know the protocols
Ok so let’s put IMEI enumerability aside for a moment and let’s have a look at how the device, mobile application, and web application talk to the cloud.
Web application to the cloud
We already know all the communications in the web application go over HTTP, so let’s take a look at what requests we see originating from the web application using some standard tools:
By using simple tools, we can see that all the requests are standard JSON AJAX requests in plaintext. We don’t need to go deeper into analyzing this part as the commands are more or less the same as those that the mobile application issues to the cloud. While it’s interesting to note that all the JSON requests are again unencrypted and in plaintext, what is even more concerning are the commands the device can issue. In addition to expected commands, such as getting GPS coordinates and setting geofencing, there are others that really stand out:
You can make the tracker call an arbitrary phone number and once connected, you can listen through the tracker the other party without their knowledge.
You can make the tracker send an SMS message to an arbitrary number on behalf of itself. This could allow you to obtain the telephone number of the device and use SMS as an attack vector.
You can send a URL to a tracker from which the tracker can update its firmware allowing an attacker to place new firmware on the device.
Mobile application to the cloud
Now let’s have a look at how the android application called AIBEILE communicates with the cloud. After capturing the traffic using Wireshark, we immediately see that it uses plain text HTTP protocol to communicate with the cloud through a non-standard port, in this case, TCP:8018.
Figure 13: Android application captured traffic at the moment of logging-in
You can again see that the whole communication goes unencrypted and plaintext to the endpoint http://(redacted):8018/openapiv3.asmx. And here is how the actual request looks:
What is interesting here is that the login request uses built-in Key and LoginAPP values which gives us a hint that this “framework” is being used by different applications as the Key is also baked inside the APK file itself.
LoginType field here differentiates between login by username and password (LoginType=0) or IMEI and password (LoginType=1) methods. This parameter controls what set of credentials you are using.
When the login is successful, a response is returned in HTTP wrapped in an XML string which is actually JSON. The typical successful response looks like this:
We see many self-explanatory fields here, but the two most important here are key2018, which is a Base64 encoded 64 bytes long session key, and deviceID where both are needed to carry on further requests and commands.
One such command could be GetTracking. You can see that command is issued after login (Figure 13). As expected the only input parameters are:
We are not completely sure what the Model field is good for but other fields are again self-explanatory. And here we have a response:
Now we know that the application and cloud communicate completely in plaintext, no encryption.
Tracker to the cloud
Now let’s dive deeper into how the device itself speaks to the cloud, how the data is exchanged between the actual tracker and servers through a mobile operator provider.
It is not easy to decode or reverse engineer a protocol which is using IP transport on top of LTE or GPRS mobile protocols. There is usually no easy way to tap into the traffic as it goes encapsulated inside GPRS from the device to the telco provider and then directly to the cloud server leaving no obvious way to sniff the data on its way to the cloud or back.
If you want to analyze such traffic, you have basically two options:
- Build your own “fake” BTS station and run your own GSM network so you can observe all the traffic going through.
- Inspect the data just before they are being encoded and sent by GPRS modem inside the device.
The first option is complicated and to do it legally, you need a Faraday cage as running your own GSM network without required licenses is illegal in most countries (not to mention pretty difficult). Also to build the equipment is not that easy however there are many open source solutions (https://osmocom.org/projects/osmobts), still it is pretty far from being convenient and easy compared to ethernet or WiFi sniffing.
The second option requires a bit of HW skills and a willingness to void the warranty on the device. We’re totally fine with this. As we pointed out at the beginning most GPS trackers have GPRS modems as a discrete component inside, and even though it is usually pretty small inside, there is still a good chance to tap the serial line between the main CPU and GPRS modem.
So we did, and after opening a GPS tracker we identified a few pads that looked exactly like the connection points we need. There are two sets of serial connection pads (TXD/RXD/GND), which are obviously one for GPS to CPU communication and another set for CPU to GPRS modem, so by trial and error we identified the right set:
And after completing this exercise, we are able to confirm that all the data travels (again) unencrypted from the GSM network to cloud server. The communication is text-based protocol and the most concerning thing is the lack of authorization. The whole thing works just by identifying the tracker by its IMEI.
SMS to tracker
Last, but not least, there is one more channel you can use to control the tracker. As it is basically a lightweight mobile phone, it allows you to set up and get some information using a simple SMS message. To get a GPS position you can issue an SMS from your phone to the number of a SIM card inserted inside your tracker. To do so you need to know the password, but unless the user changed it, the default password is the same for all devices.
Figure 20: SMS commands as being stated in the manual
We learned all of this by doing some hardware reversing, but did we really have to? It turns out that while studying the commands you can issue through SMS messages directly to the tracker we found this one:
Although, hidden under the semi-mysterious name “Setup IP and port” that command actually means that you can set up the IP address and TCP port where the cloud server the device communicates with is located. That’s the holy grail for an attacker (or a security researcher); in combination with the unsecured protocol being used for sending data back and forth, you can easily do a MITM (man in the middle) attack and capture all the data using standard IP tools. So we did:
(you can easily spot the IMEI/ID and coordinates)
Format of identified commands seems to be textual and follows this format:
Heartbeat command tracker -> server[3G*1703249112*000C*LK,0,1226,85]
Heartbeat response server -> tracker:[3G*1703249112*0002*LK]
Activate monitor mode (callback this number) server -> client:[3G*1703249112*0015*MONITOR,+420612661749]
Send SMS “Test” to provided number (+420602661749) server->client:[3G*1703249112*0016*SMS,+420602661749,Test]
Position and status (client->server):[3G*1703249112*0090*UD,210619,053538,V,37.481010,N,-122.2315369,W,0.00,0.0,0.0,0,86,86,0,15,00000000,4,255,202,1,2082,5673,140,2082,12,128,2082,5671,118,2082,11,115]
Finding APIs all over the place
While investigating the various API endpoints we found that the platform we are investigating seems to be widely used by many other vendors out there. With a little bit of googling we found what seems to be the documentation for the mobile app -> cloud interface:
It’s not the purpose of this research to go through every single command that this API offers, but let’s have a look at a few examples to further illustrate how bad the security is and what consequences could this have for regular users.
Command GetDevicePhoto. While the tracker we investigated didn’t have a camera, others that use the same cloud framework do (such as A19-3G Network GPS Smart Watch on the image below) This command certainly piqued our interest.
Figure 25: Kids GPS trackers with built-in camera
When we looked at the parameters of the command we saw this:
As you can see there are really not many parameters needed: the DeviceID is the 6 digit number you get when you login to the account. The TimeZones actually doesn’t matter as it’s being used only for adjusting output timestamps of pictures. And the Key is the fixed key assigned to the Android application which is using this API. (see Figure 14).
When we tested this against a tracker with a built-in camera, we saw how easy it was to get the device to dump a list of all its photos.
The result is a nice JSON formatted document in the form of:
The only thing you need to do is append imgUrl to photoName and you have a URL of the picture, no further authorization required. Also if you pay attention you’ve noticed that the pattern of the photoName seems to be familiar.
And it turns out that ID is actually that IMEI/ID of a tracker used to login to the account. So you can theoretically scan through the timestamp and get all the pictures from a particular time period. But honestly, the easiest way is to scan through all DeviceIDs (Figure 27) as it is only 6 digits number and you really don’t need anything else.
Scale and white labelling
Ok so let’s get back to the IMEI/ID that in combination with default password serves as the credentials for your account. Remember how easy it was to scan through that 1M of possible IMEI numbers as they have the same prefix? So we scanned an arbitrary 4M sequential serial numbers ourselves just to get an idea of the scale of the devices out there and we learned that at least six hundred thousand devices are live in the wild with default passwords. We executed a deeper scan of a subset of one million of these devices to determine make, model, and location; of the one million, we scanned, over 167,000 were locatable.
Figure 29: a result of a detailed scan of 1M serial numbers for tracker devices
Now it’s obvious that the same infrastructure is used for all or at least most of the trackers from this vendor as we identified 29 different models of trackers during this scan of 1M IMEIs. All the models are sold by wholesaler Shenzen i365, and we were able to determine that some models in this scan are being sold under different product names, which leads us to the conclusion that infrastructure and devices are being white labelled and sold under different brand names. In many instances, however, we were only able to determine a generic model number.
| Number of trackers | Tracker model |
| 60601 | T58 |
| 36658 | A9 |
| 26654 | T8S |
| 20778 | T28 |
| 20640 | TQ |
| 11480 | A16 |
| 10263 | A6 |
| 9121 | 3G |
| 7452 | A18 |
| 5092 | A21 |
| 4083 | T28A |
| 3626 | A12 |
| 2921 | A19 |
| 2839 | A20 |
| 2638 | A20S |
| 2610 | S1 |
| 1664 | P1 |
| 749 | FA23 |
| 607 | A107 |
| 280 | RomboGPS |
| 79 | PM01 |
| 55 | A21P |
| 26 | PM02 |
| 16 | A16X |
| 15 | PM03 |
| 4 | WA3 |
| 4 | P1-S |
| 3 | S6 |
| 1 | S9 |
Figure 31: trackers models and their counts in 1M detailed sample scan
You are probably already feeling like there is a lot more to this story than meets the eye as we found devices that are not produced by this particular company during this scan. It turns out that this problem is much bigger than it looks. How big? We’ll show you in the follow-up to this which goes deeper into the relationships between different products and companies and into many surprising facts about cloud infrastructure. We found more alarming vulnerabilities and much more instances of this cloud and trackers.
But so far we think we are speaking of approximately 50 different applications sharing the same platform (and probably also the same vulnerabilities) as seen in this picture:
Possible attack vectors
Considering the fact that every single communication channel to the cloud used by these products has security issues, there are endless possibilities of exploitation. But let’s focus on the most interesting ones:
Off the shelf locked device
It seems that every device’s account is active from the time the device is manufactured, so an attacker can lock-out the user out of the account even before he buys his tracker just based on the IMEI number because you can change the password of an account which belongs to a device that has not been used yet.
Getting to know the phone number
There are some commands that you can issue to a tracker only by using SMS message (such as the command that allows you to set the cloud server to which the data flows). However, if the user doesn’t put the number of the SIM card of their tracker into the account, an attacker (seeing only the account) won’t know it. But it’s easy to get it. Through the account, an attacker can make the tracker send an SMS to a phone number of a phone in his possession which allows him to tie the ID of a tracker with its phone number. Once known, the attacker can send an SMS that sets the new IP address and PORT of a cloud server and reroutes all the traffic from the tracker to your server of choice. All of this can be done remotely, allowing an attacker to see the full movements of anyone with the device.
Spying on people
Because the cloud allows you to send a command to any tracker that makes it voice-call any arbitrary number, you can easily spy on the user of the tracker without them being aware that the tracker has called someone.
Spoofing location
It is startlingly easy to lie to the cloud telling it that the tracker is somewhere else or is doing something else, as the service in the cloud is open and the only thing it needs is to see the ID/IMEI in the packet, all the other information is up to you.
Conclusion & future work
As you can see there are strong indicators that this issue goes far beyond the scope of one vendor. We found similar APIs being used by different applications also found models that are not being made by this particular vendor that is linked to this cloud infrastructure. We are already writing the next part of this research which concentrates mostly on cloud infrastructure being used and how white labelling brings this issue into a gigantic scale.
I’m looking forward to seeing you in the next part of this blog post where my colleague Nikolaos Chrysaidos and I will deep dive into the world of white labelling, platform sharing and into all that bad decisions and design flaws that lead to the poor state of security as we see it today across the whole spectrum of IoT and smart devices.
In favour of responsible disclosure, we informed this particular vendor on 24-Jun-2019 and we didn’t get any response to repeated messages as of today.
Edit:
The second part of a series is out: The secret life of GPS trackers (2/2)
