What’s wrong with automotive mobile apps?

Introduction

The recent story about the 19-year-old hacker who took control of several dozen Tesla cars has become something of a sensation. We already know that there was an issue with a third-party app that enabled access to data from Teslas. This made it possible for the security researcher to lock and unlock the cars, turn the lights on and off, and even enable keyless driving. All the functions in the native Tesla application became available due to a misconfiguration in third-party data logging software. So, let’s try to get a better understanding of what these apps are, why they appear on the market, and the risks they pose.

First public notice about the incident involving Tesla

The majority of modern vehicles are equipped with a special telematics module. The electronic control unit with a built-in SIM card provides the manufacturer with the vehicle’s location, warns the owner about upcoming vehicle inspections, and can even contact emergency services. In addition, the car owner gets some handy functions, such as the ability to check the vehicle’s location, control the door locks, remotely turn on climate control, and even automatically park the car. And all that by just using a mobile application.

Interface of a typical companion app

But why do people need a third-party app when all these functions are available in the car manufacturer’s application?

Native apps simply can’t satisfy the demand for features among modern car owners. For example, some users want to see how the fuel/energy consumption changes depending on their route. Some want to warm up the vehicle interior while their smart coffee machine starts making coffee in the morning. And others are not happy that they need to use several mobile applications for different car brands, and want to manage them all from a single universal application.

So, what can go wrong? The same sort of things that occur in other walks of life. A key is needed to gain access to a car, but in this case instead of a key there is a login or email and a password. And the prerequisite for the automaker’s backend to send a command to the owner’s vehicle if it receives these credentials. They are intended to be transferred directly from the automaker’s native app, but third-party apps can ask a user for the original credentials and send them to the automaker’s API on their behalf.

Communication between apps and vehicle

The risk is obvious: third parties get the ability, for example, to unlock the car or track all its movements on behalf of the car owner.

What’s the scope?

How many of these solutions are out there? Kaspersky analysts checked among mobile applications, open-source software and searched web services to find out. The research scope included 155 of the most popular solutions that require the vehicle owner’s credentials (login and password pair or API key) to interact with the vehicle. A total of 69 mobile apps and 81 solutions were discovered in open repositories, such as API clients in various programming languages. The findings also included web services, as well as a few other things of interest.

Types of applications (download)

Each of these discovered application types is described below.

About mobile applications

Let’s start with mobile apps as the most accessible and most understandable for the average user. If we look closer at the descriptions of these apps, they usually talk about their great functionality, convenience, and even comparisons to the “slow” apps provided by automakers.

Description of a random application

An analysis of these descriptions showed that more than half the applications fail to mention that they use the owner’s account with the automaker’s native service.

Share of applications that don’t notify users on credential usage (download)

Yes, that’s right. The important thing to note here is that the second smaller share is made up of developers that explicitly state their apps do not store the user’s data, or store it in encrypted form or only use the credentials to obtain authorization tokens. But, to be clear, you are basically handing over your car keys to a complete stranger and taking them at their word, because there’s no way of verifying those statements.

Some of the developers also suggest using an authorization token instead of a username and password to look more credible. But the catch there is that this token makes it possible to access the car in the same way as user credentials. And, once again, the user should be aware that all this is at their own risk. Only 19% of developers feel the need to mention this fact and warn the user without hiding behind several screens of fine print.

Share of apps warning users about their liability (download)

The most common way for a user to contact the application developer is usually via feedback in the review section of the mobile app store. But what if the question is more serious and requires an immediate response? Here we can thank the application stores and their placement rules. The contact information for 86% of the app authors was found without much effort, although quite often it is just an email without any additional information. But for some applications the search can lead to a deleted social network page or a stub page with no contacts.

Share of apps with available contacts (download)

Based on this, it’s clear that most of these applications are developed by enthusiasts. Is that necessarily a bad thing? No. But there’s no onus on the enthusiast developer to care about your vehicle’s safety and data security to the same extent that state regulators demand of automakers.

Which vehicle brands are most often subject to control by third-party apps? In total, we counted 31 brands, with the top five shown below. Note, some applications enable control of more than one type of car brand, so the number of mentions is not equal to the total number of apps.

Top five affected automotive brands (download)

Tesla leads by a considerable margin, followed by Nissan. It appears that electric vehicle owners, who are usually car enthusiasts, are interested in these apps.

When it comes to the cost, 46 of the 69 apps are free of charge or at least have a demo mode. If a program can do cool tricks with a car and costs a lot of money, there may well be a free counterpart.

Free to paid allocation (download)

This, combined with the fact that such applications have been downloaded from Google Play more than 239,000 times, makes you wonder just how many people have given strangers free access to their cars.

Open-source API clients and web services

It is worth noting that slightly more advanced users tend to use software from GitHub. And indeed, it is pretty easy to check it to see if an API client is transferring sensitive information to third parties. But what if the source code is a bit more complicated? Would all the users check the code, and how thoroughly? And, of course, this won’t guarantee there are no vulnerabilities in the application itself or its components. The example in the first link of this article illustrates that rather well.

The third type of application in our selection is web services. These services are provided to users on a commercial basis. But even though they may be developed by organizations with highly skilled developers and well-established management, the authorization scheme is not that different. The user still needs to provide their credentials, but to a web form and not to a mobile application or API endpoint.

What didn’t fit our data?

One other type of application stands a little apart from the rest. That’s because unlike the regular add-ons or classic “give the username and password – get the token”, they are designed as full-fledged B2B solutions. B2B? Yes, that’s right. Take, for instance, a company that wants to sell an application or service to a user without diving deep into the specific implementations of different car manufacturers. And a B2B provider provides universal solutions that are capable of interacting with multiple automakers and facilitates their work, becoming an intermediate link.

Schematically, an example would be as follows:

• The user registers in an online third-party service like those mentioned in the previous section. That service helps estimate the optimal time and location to charge a vehicle.
• The system of the service has no direct access to the automaker’s API, so it passes the user’s credentials to the aforementioned B2B provider.
• In its turn, the B2B provider sends the credentials to the automaker’s API and gets an authorization token in return, allowing direct access to the user’s vehicle and its data.

Thus, the username and the password go to both the third-party application and the B2B provider at the same time. In this case, both the owner and developer “in the middle” are at risk because the security of the user data now depends on yet another company.

There is also some risk here for the automakers because these services process the data of lots of users. Yes, all of this only works with the end user’s consent, but, as recent events show, it is the car brand that makes the headlines, rather than the app name.

Conclusion

If you decide to stop using such apps after reading this article, there are a few things to consider:

• It’s not enough to just delete the app – some services require that you end the subscription or delete your account on their website;
• A password change is mandatory;
• Even after a password reset, it is better to try to revoke access via the manufacturer’s website (if there is such a feature) or customer support service.

Of course, not all these companion applications should be treated as insecure or untrusted. Some of them use specially designed solutions from automakers, which, for example, make it impossible to unlock the doors remotely for security reasons. Instead, access to the vehicle data is given via the manufacturer’s website, and there is no need to provide credentials to a particular application. Users can also revoke this access at any time. Unfortunately, there still aren’t many apps capable of this.

Hence, we urge the app developers to make user protection a priority and take precautionary measures so as not to compromise their customers or themselves. Instead of assuming their customers are prepared for potential threats, developers can proactively equip their apps with additional user-protection technologies.

Kaspersky recommends the following for application developers:

• Since supply-chain attacks through public repositories have become more frequent of late, the development process needs enhanced protection against outside interference. Adopt solutions that can secure the software development process by application control at runtime, scanning for vulnerabilities before deployment, routine security vetting of containers and anti-malware testing of the production artifacts. Kaspersky Hybrid Cloud Security meets development needs. It secures Docker and Windows containers and provides a ‘security-as-code’ approach, with containerization host memory protection, tasks for containers, image scanning and scriptable interfaces, so you can integrate security tasks into CI/CD pipelines without impacting the development process.
• Implement protection mechanisms into the app. Kaspersky Mobile SDK enables customer data protection, as well as malware detection, secure connectivity and more.