We recently discovered flaws in the security of shared electric scooter services that have worrying implications for the safety and privacy of their users. Not only is it possible to remotely ring the bells of scooters all over the world, but external parties are able to track the location and journeys of those scooters.

In the video below, we show our researcher remotely ringing the bells and flashing the lights of scooters in public on February 5.

If you live in a major city you’ve probably noticed electric scooters springing up like mushrooms over the past couple of years as part of the new green micro-mobility revolution aiming to reduce car traffic and improve air quality. And scooter-sharing is hugely popular. Such services have attracted billions of dollars in funding and the market is expected to reach between $40 and $50 billion by 2025.

But there are issues with the security of some electric scooters. In early 2019, for example, it was reported that hackers were able to exploit a flaw within one particular scooter’s operating software and insert malware that gave them complete control of the vehicle – allowing them to accelerate and brake remotely, and even change the electronic bell sound to an embarrassing expletive.

There are worrying implications for privacy too, as I found out from my own research. Not only is the private location data of people using the service at risk, but scooter-sharing services providers could steal a march on their competitors by analyzing valuable business information using publicly accessible information from the vendors’ mobile application and API.

In this blog I’m going to show how, by exploiting a weakness I’d uncovered in the services, I was able to list and track all the trips made by an electric scooter – and why you should care.

Track and trace

As a security researcher who uses scooter-sharing services from time to time, and given the explosion in their popularity, I was curious about how secure these services actually are. We’ll begin with a hypothetical situation which I think illustrates the severity of the situation.

Let’s imagine my neighbor from down the street was meeting her friends in the park. When the meetup was finished, my neighbor pulled out her phone and approached one of the shared electric scooters. She put on her helmet, unlocked the scooter, and started riding home.

Everything looked completely ordinary – there was certainly no reason to suspect the guy on the nearby bench looking at his phone and who, moments later, got up and left the park.

But later that day, I heard that someone had broken into my neighbor’s house. Somehow, that man from the park had been able to trace her – but how? She didn’t seem to know him, and she had a few minutes’ head start before he left the park.

Starting with the basics

To understand how this was possible, it’s important to note that all scooter-sharing services are built upon three main building blocks:

An API server that communicates with the other two elements and functions as the brain of the system. The scooter itself is effectively an IoT device that communicates with the API server, reporting its location and taking commands from the server to unlock and/or lock itself. A mobile application that enables users to interact with the service, allowing them to find a scooter, and unlock or lock it.

Conducting our research

While these three components are common to scooter-sharing services all around the globe, we chose to carry out our research on globally available services which also operate in Tel-Aviv, and began by installing their applications on an Android emulator.

All traffic between the emulator and the application API gateway was proxied through BurpSuite for further analysis. In order to exploit the weakness we found, we wrote a small Python application that communicates with the API server and mimics the application side.

When we monitored the application API calls via Burp we noticed one API that is commonly used to locate nearby scooters.

Here’s how it works. The application sends the geo-location of the mobile device to the server, which then replies with a list of available scooters in an accessible radius. This is what that request looks like:

When we examined the server response containing the list of scooters, we found that each scooter has a unique identifier:

Given the ability to locate all the available scooters in Tel-Aviv, and the ability to identify each individual scooter, we were able to start tracking when and where each scooter went. And, while it’s not possible to correlate a scooter to a particular user when taking advantage of this weakness, if we were to visually track a person using the service, we would be able to follow their route or at least know where they ended their ride. Spooky isn’t it?

We decided to write an application that sent different geo-locations in Tel-Aviv and captured all of the scooters in the midtown area. We had a starting geo-location and created a matrix of locations, with a distance of 500 meters between each one. We then saved all the scooter IDs and information, and issued another polling cycle.

This way we could track scooters which were unavailable, probably because they were in use, and we also could see when these scooters were returned to service – meaning we knew when and where each ride ended.

We found that this API call had a rate limit, but we easily overcame this obstacle by using several users and rotating them between each API call.

With all the information about scooter movements in and around the city we were able to extract some interesting conclusions.