The secret life of GPS trackers (2/2)

The Cloud Strikes Back

Last fall, I published a deep-dive analysis of vulnerabilities I had discovered in a widespread network of GPS tracking devices. It’s been nearly nine months since I disclosed my findings to the manufacturer, Shenzen i365, and issued a public service announcement on the Avast blog to inform our users of this risk. Yet, to this day, I estimate there are upwards of half a million devices still out in the wild, exposing exact real-time GPS coordinates of the children, elderly, and even material possessions that these products are promising to keep safe.

You might be wondering how such a wildly insecure brand got into the hands of so many consumers around the world. The problem, I found, is much bigger than a single vulnerability disclosure to one single device vendor; instead, the GPS trackers I detailed in Part I of my research actually opened my eyes to a web of supply chain relationships that exponentially increase the security issues from one white-labeling vendor to the next.

In this follow-on article, I’ll explain how far and wide these cheap, knock-off brands are by detailing the GPS trackers’ infrastructure itself and explaining the manufacturer-vendor-consumer relationship.

Just to clear up wording for the purpose of this article, the manufacturer is the one who is really producing the electronics (tracker) whereas the vendor is whoever sells that device with added value in form of software, app or cloud solution.

But first, let me recap the first part of this research.

Chapter 1: Device mayhem

GPS trackers come in a variety of makes and models, and for various purposes. They are commonly advertised to track the location of children on-the-go, usually in the shape of watches that contain a microphone/speaker or camera to enable communication with parents. I also analyzed GPS trackers designed for cars, with some models that were even allowing hackers to connect to the vehicle’s immobilizer to kill the engine remotely. I studied trackers for pets in the shape of  collars, trackers for the elderly with built-in emergency call  functionality, and general-purpose trackers on a keyring. What all these trackers have in common is a basic scheme of operation (illustrated below) — as well as a set of vulnerabilities in the cloud API that could allow an attacker to gain full control over the device.

Intermezzo: A short intro to the supply chain issue

To fully grasp how far this rabbit hole leads, I need to take a step back to explain what the supply chain problem actually entails. In today’s IoT landscape, being the first to bring a new product to market is prioritized over taking the time to beef up its security. Especially in the realm of cheap devices where the competition is enormous and vendors are less likely to invest in building everything in-house, the solution is to build a product from various components purchased from third parties. That’s called a supply chain. It’s not a new concept and manufacturing has always worked like this, but what worries security researchers today is that there is usually no guarantee that those component of products are secure, especially if a vendor’s budget is limited and it can’t afford to conduct a proper security assessment of every single item from its BOM (bill of material list).

Chapter 2: All Trackers of the World Unite!

Looking at GPS trackers market, many look alike, but are sold under different product names by different vendors. The truth is that there are countless trackers out there, and are all manufactured by only a few factories in China. The famous manufacturers of trackers out of China today include companies like:

Bofan	Coban	LHYK	XexunBofan
BSJ	CanTrack	Meitrack
Benway	GooMe	ReachFar
Concox	i365GPS	TKSTAR

It’s likely that you haven’t heard of any of these companies before, unless, of course, you read our first part of this research. Well, it’s not a surprise you would be unfamiliar as they, for the most part, produce the tracker hardware, and the end-user, only really interacts with the accompanying mobile application and cloud infrastructure, which is usually white-labeled by someone else. So, vendors are usually those who sell and combine these three major components from different sources. We tried to map all manufacturers, solution providers, and vendors, but it’s such an extensive web that it is simply not in our power to encapsulate all of them. For illustration purposes, this is what the typical supply chain looks like:

The image above seems to be pretty simple and understandable, but that’s an ideal world. In the real world, there are many exceptions in this schema; for example, cloud solution providers could also be directly selling final solutions with both an app and hardware, or, hardware factories have a source of firmware from another developer.

Chapter 3: Recap of Vulnerabilities

I found many issues with the i365 brand of trackers, so let’s recap them just for reference:

Default login credentials

All trackers of that particular vendor had 123456, one of the most insecure passwords possible, pre-configured as the default password. Without further knowledge, users were not pushed into changing it.

Cloud login was unencrypted

Login into web services and also into the mobile application was sent unencrypted over the wires so anyone could have intercepted or changed it.

Cloud login was weak

The trackers’ usernames were also pre-configured, never giving the user an opportunity to choose their own. In fact, the assigned username is actually just part of the device’s international mobile equipment identity (IMEI) number, which is easy to iterate through. Moreover, the password has been pre-set to 123456 again.

Data transmitted between the tracker and cloud is plaintext

Data traveling over the tracker’s GPRS mobile connection is not encrypted and lacks authentication. Further, the tracker allows an attacker to change the endpoint (IP address and port) of where the data is sent, just by sending a plain SMS with a predefined password. This lack of encryption allows anyone to intercept and modify communication which allows all sorts of scenarios such as data leaks, spoofing users’ position, sending malicious commands, and so on.

• 

Cloud infrastructure API is broken and insecure

The API endpoint following the SOAP standard communication protocol has many issues. Most of the functions require no prior authentication; the only identifier of the device is a six-digit number that could be quickly iterated through the device-related data, such as the GPS history or stored photos in the cloud. It also goes over HTTP, so again, no encryption — although in this case, it is irrelevant because anyone could call the API as it’s missing proper authentication.

Even though you see the Key field here, it’s not the session key you get by login in, but in fact, the baked-in key from the application is accepted. As it turns out, this key is also shared by different vendors, which again points towards one common cloud.

I mentioned that this seems to be a bigger problem than just one Chinese vendor, and it turned out unfortunately that I was right.

Chapter 4: Cloud strikes back!

So now let me explain to you why I recapped  the supply chain intro. Imagine this situation: there are dozens of manufacturers of GPS trackers producing all these different models of trackers with their own firmware that speaks own protocol, so either they create their own solution and app, or they buy a ready-made solution. Which way would you go?

Because I am quite suspicious that this is NOT an isolated problem, I was thinking of getting a car tracker from another manufacturer… but wait, do I have to buy another one? This time, I decided to approach it differently.

Virtual research of physical device

I knew where to expect vulnerabilities, do i even need a physical device? I picked this one (and by picking I mean i found it on the internet by a random search for GPS tracker):

According to the manufacturer’s webpage, this tracker is capable of cutting off power to the car’s ignition, sending alarms when the ignition is on, and all the “standard” functions, which include a microphone and speaker. But do I need to buy it for this hack experiment? I decided to do the analysis virtually to prove the point that it’s not difficult to properly perform a security assessment of any of these devices and companion apps. Moreover, to prove my suspicion that this device is using the same backend services.

First steps would be to get the device’s operating manual and download the companion application. On the manufacturer’s webpage, this caught my eye:

• 

So, I have a source for the web portal and Android application. First, let’s see the portal:

Hmm, this seems familiar. As I don’t know the exact IMEI or Licence Plate Number (since I didn’t actually purchase it) I can’t log in, but let’s try at least to look how this login data goes over the wire.

So far it seems similar, but not enough to confirm my suspicions. So let’s have a look into the Android application.

Well, that doesn’t say much. So, Iturned to Avast’s own state-of-the-art Android application analysis tool, apklab.io:

Now that’s something! Using static analysis of the Android application, having no physical device, I spotted a build-in URL that seems to be exactly what I am looking for, so let’s just try it.

Oh no (or should I say oh, yes), this seems to be familiar:

OK, so now let’s just test if they share the same vulnerabilities, starting with GetDeviceDetail:

Without any hesitation, we used a baked-in key from the previous application and guessed DeviceID (this was the third attempt)

Well we were then greeted by:

This proves that all these trackers have something in common: although made by different manufacturers, it seems that the cloud infrastructure is made by the same company. Just to prove my point I downloaded the manual, and although it looks slightly different, I got what I came for:

---

You can see the same pattern as in previous research, how to set up an IP address and port of a server where the tracker should connect to send GPS data and to receive commands…….unencrypted and unauthenticated.

Researcher’s ultimate tool… Google

We know that there are several vendors using one cloud, but how can we find more? It’s not the most sophisticated way of doing research, but sometimes simple things such as Google can give you fruitful endings. Yes, I Googled OpenAPv3.asmx and as unbelievable as it may seem, I found many pages where the URL resembled a format I had already seen. But what a surprise when I also found this:

You know it is typically not a good standard to leave your web open in a way that anybody can browse through it freely (with the exception of C&C server operators ;)), fortunately this webpage has been already taken down. But it gave me a clue as to how the API is structured and what you can find there. I noticed three things here:

1. Log directory was browseable which could give me a more detailed hint on where this whole backend system came from
2. There are multiple versions of the API OpenAPIV1-V4, and it turned out that all of them were accessing the same data.
3. The ZKImages folder is self-explanatory I think. Yes it was full of images taken by GPS trackers with a built-in camera 

Obviously, the log directory was the first thing that attracted my attention.

As you can see logs have been pretty up to date, so we opened most recent of them

Some exceptions in the SQL client when trying to connect to the DB. However, the most valuable information here was the name of a binary that implements the framework. You know all disasters in the information security world come from the wrong code, and lousy code usually comes from programmers. So Idecided to follow that lead. There is nothing you can tell from the name of the binary itself: NewGPS2012.Logic. Except the fact that it’s probably pretty old .NET binary. And because I’ve been lucky with Google before, I tried that again

I was pretty astonished by the results.I found many log directories indexed by Google, which gave me a list of domains using what appears to be the same framework almost for free, but one of them was special:

Yes, someone just left an update of the framework binaries laying around. (This page is fortunately already down too). I learned so much in analyzing those binaries (and may have more blog posts on this topic in the future), but one of the essential things I found was in a SendCommandAPI.dll file which had an exhaustive list of functions.

Shortly, this turned out to be the universal API that can talk to all different models of all different manufacturers of GPS trackers. And here we are. THAT is the main reason why this whole thing makes sense. If you are a manufacturer or vendor of an HW device, you probably need a cloud solution that is ready to use and compatible. For the sake of sanity we won’t publish the name of the solution vendor, although it is not that hard to find out.

Hmm, support for location shoes? Now, I’m really scared.

Give me everything

One of the new and more serious vulnerabilities I found underscores how poorly this solution is being implemented and operated. But to explain, let me go back to our previous blog post. Do you remember what goes over the wire, when you’re logging in using the web portal? You’ll get these requests to API which contains DeviceID:

Maybe you’ve spotted one more strange information here:

But wait, how is that possible? We know that we don’t really have a user account with these trackers. Remember the only user identification is IMEI or ID of the tracker? What is more concerning is the fact that I had more trackers by the same company and all of them have the exact same UserID in the response. So what does it mean? Wait, no, it can’t be right… or could it be?

Let’s get to our OpenAPIV3.asmx API and have a deep look on the functions that it provides:

So we just put in our userID and obligatory Key we already used several times and we got this response:

Wait, login name? What could go wrong, right? Given the level of security of the whole system, I just gave it a try using the well-known password we already used so many times. And this time I chose to login by “Account”:

What I saw was just astonishing. I got into the control panel of the vendor having all the sold trackers at our disposal. So the UserID is in fact UserID of the re-seller / vendor who sold you your particular tracker.

• 

From here you have full control over the trackers. And yes, you see it right, there are 1,026 pages of 10 trackers on each page which gives you easy control of a batch of 10,260 devices. For example, there is a reset password option and guess what, it doesn’t ask you for a new password; when pressed, it sets it to 123456.

Fix or hotfix or not fix

By now, we see that device security is not of concern to those vendors. At the time of this writing (June 2020), the vendor has issued a fix to this bug, but it is more of a hotfix. From now on you can’t choose 123456 as a password and with a new login you have to change the password if you already have 123456 as one.

Well, it turns out this is not a fix at all because these API endpoints are not properly authenticated. Once again, we’ll turn to the API in OpenAPIv3.asmx endpoint:

It might seem complicated, but in fact, it actually isn’t. What is more important here is that the ID in this case is an ID of the user and it’s again only 0-999999, which is pretty easy to enumerate. The rest of the required fields are known. So by running a simple query, we can easily get this response:

Notice the resSize of the result set. By a single query, you’ll get all devices assigned to a particular account. And when you iterate through all the possible IDs for the user, well you’ll get all the users and devices. From there you can get any information you’d like, phone numbers, location, usernames, in case of this endpoint also the data from OBD interface of your car and all the things I’ve shown you in my previous post. And last but not least, you can fully control a remote device, make calls or send an SMS from a tracker. Imagine what an attacker could do. Recruiting an army of mobile devices to send SMS to a premium number or manipulating votes in an SMS voting poll, for example.

I have been researching these insecure GPS devices for quite some time already, striving to understand the size of the problem. So far, I have identified over 30 different instances of this framework being operated on the internet and more than 500 different versions of trackers using this service. It’s hard to estimate the size of the problem but to have at least rough estimation I did a full scan of 2 random clouds that gave me these numbers:

788,644 + 251,886 geo-located trackers from two clouds. Provided that we can roughly estimate, from what we’ve seen so far, that there could be more than 15M of devices that can be located and controlled.

It’s also worth mentioning that, because of the supply chain, not all of these devices are cheap brands from the few Chinese factories I mentioned earlier. During my research, I also identified a lot of European and US based brands, some of which are even being sold on Amazon. But what was interesting in the case of an American version of a tracker, is the fact that the website uses HTTPS and seems pretty legit; it is also using a device that has LTE support and you even pay a monthly fee for the plan. You have to activate your device and create an account, but underneath lives the same cloud framework we’ve already seen with no security.

That also raises a question of legality of handling data and privacy as most of these “out of China” brands still store customer data on Chinese servers (belonging to the cloud solution vendor), which is definitely not in agreement with recent legislation in the US nor in the EU, not speaking of collecting personal data and storing them with almost no security.

To illustrate that not only Chinese customers are affected, this is the chart of trackers located by country from our two full scanned clouds:

vendor A		vendor B
count	country	count	country
99036	China	386231	China
1976	Mongolia	15391	United States
1652	Ghana	6633	Cambodia
818	Dominican Republic	6529	Mongolia
675	Cambodia	6018	Ghana
670	Netherlands	3650	Myanmar
615	Kenya	3432	Bangladesh
598	Myanmar	3339	Kenya
347	Viet Nam	2315	Dominican Republic
267	Peru	2168	India

Chapter 6: Conclusion  

As I said in the beginning, I found a company providing a cloud solution to all the HW manufacturers and vendors. We can’t name them, but just for illustration, this is what is the scope of their services:

Here you can find everything, even the documentation for the OpenAPI protocol and protocols for particular trackers – no word of security:

How can I conclude this research into the world of cheap GPS trackers? I think the best I can do is to share with you this proud proclamation found on the same page of cloud vendor

And that’s only one server and information from 2014. That is exactly how big this problem is and could also be considered as a proof of how serious the supply chain issue is nowadays. Especially in case of cheap IoT and cloud enabled devices.

During the course of my investigation, I stumbled upon many apps and vendors who are affected, very often they even don’t know they have a problem. I have been thinking how to approach responsible disclosure while at the same time help affected users. I decided not to show all the apps and clouds as there is no easy way to fulfil the responsible disclosure and public service announcement at the same time in this case.

If you feel you could be affected, please reach out to us and we’ll try to help you. You can always reach out to us at @AvastThreatLabs

I’d like to thank all my colleagues and fellow researchers at Avast and also the whole information security community for help with this research. Extra kudos goes to my colleague Nikolaos Chrysaidos and his team for the amazing apklab.io tool which gave me a lot of great insights and effortless reversing of Android apps.