I know where you rode last summer: Uncovering the security issues of shared scooter services

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:

  1. An API server that communicates with the other two elements and functions as the brain of the system.
  2. 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.
  3. 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:

application request

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

scooter 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.

    1. Personal privacy is loose. We could list all the trips made by a particular scooter and even try to estimate the routes taken with help from Google Maps, as shown below:scooter trip

 

  1. Business intelligence. We could obtain information on factors such as average ride distance and time, the number of rides a scooter completes per day, and the busiest time and locations. While this has little impact on user privacy, data like this is of enormous value to competing businesses.

Taking a five-day sample comprising more than 6,000 rides, we found that the average ride time was around 20 minutes. In the histogram of these ride times below, you can see that most rides were between five and 20 minutes:

try {
jQuery(function($){
Highcharts.chart(“graph 1”, {
chart: {
type: “column”,
},
title: {
text: “”
},
xAxis: {
categories: [“Less than 5″,”5-10″,”10-15″,”15-20″,”20-25″,”25-30″,”30-35″,”35-40″,”40-45″,”45-50″,”More than 50”],gridLineWidth: 1,

},
yAxis: {
min: 0,
tickInterval: 200,
title: {
text: “”
}
},
legend: {
symbolRadius: 0,
align: “center”,
verticalAlign: “top”,
layout: “horizontal”,
x: 0,
y: 0,
},
exporting: {
enabled: false,
},
plotOptions: {
series: {
dataLabels: {
enabled: false
},
},
pie: {
allowPointSelect: true,
cursor: “pointer”,
dataLabels: {
enabled: false
},
showInLegend: true,
colors: []},
series: {
label: {
connectorAllowed: false
},
},

},tooltip: {
headerFormat: “{point.key}

“,
pointFormat: “

“+

” +

“,
footerFormat: “

{series.name}: {point.y:.1f}

“,
shared: true,
useHTML: true,
},series: [
{name: “Ride time in minutes”, data: [395,1570,1840,1010,570,410,220,190,170,100,550],color: “#2e5dde”},
],
responsive: {
rules: [{
condition: {
maxWidth: 500
},
chartOptions: {
legend: {
layout: “horizontal”,
align: “center”,
verticalAlign: “bottom”
}
}
}] }

});
});
} catch(err) {
console.error(“Faild to initial HighChart id graph 1”, err);
}

We also found that – as expected – most rides were in the range of two to three kilometers, as shown in the histogram below:

try {
jQuery(function($){
Highcharts.chart(“graph 2”, {
chart: {
type: “column”,
},
title: {
text: “”
},
xAxis: {
categories: [“Less than 500″,”500-1000″,”1000-1500″,”1500-2000″,”2000-2500″,”2500-3000″,”3000-3500″,”3500-4000″,”4000-4500″,”4500-5000″,”More than 5000”],gridLineWidth: 1,

},
yAxis: {
min: 0,
tickInterval: 200,
title: {
text: “”
}
},
legend: {
symbolRadius: 0,
align: “center”,
verticalAlign: “top”,
layout: “horizontal”,
x: 0,
y: 0,
},
exporting: {
enabled: false,
},
plotOptions: {
series: {
dataLabels: {
enabled: false
},
},
pie: {
allowPointSelect: true,
cursor: “pointer”,
dataLabels: {
enabled: false
},
showInLegend: true,
colors: []},
series: {
label: {
connectorAllowed: false
},
},

},tooltip: {
headerFormat: “{point.key}

“,
pointFormat: “

“+

” +

“,
footerFormat: “

{series.name}: {point.y:.1f}

“,
shared: true,
useHTML: true,
},series: [
{name: “Scooter ride distance in meters”, data: [860,1550,1350,990,770,550,365,200,100,80,120],color: “#2e5dde”},
],
responsive: {
rules: [{
condition: {
maxWidth: 500
},
chartOptions: {
legend: {
layout: “horizontal”,
align: “center”,
verticalAlign: “bottom”
}
}
}] }

});
});
} catch(err) {
console.error(“Faild to initial HighChart id graph 2”, err);
}

Our data samples were from 6 a.m. to 7 p.m., from which we discovered that the peak service time was between 1 p.m. and 2 p.m., as shown in the chart below:

 

service busiest times

In addition, we uncovered a further – unusually noisy – weakness. By sending a scooter’s ID to the service, the API can trigger that scooter to ring its bell, enabling it to be identified when it’s nearby but out of sight. However, we found that, after overcoming the rate limit mechanism explained above, it was possible to ring many scooters’ bells at the same time.

Securing scooters for greater safety and privacy

There’s no doubt that the aim of scooter-sharing services is to improve our lives and our environment. But a shared scooter is, fundamentally, an IoT device and, as with any other IoT device, it has its own risks.

Remotely ringing scooters’ bells is, at worst, irritating. But when you consider the effect of similar remote actions on connected cars, the impact is considerably more dangerous. Manufacturers and vendors must, therefore, ensure robust security is built into the systems to prevent anyone gaining unwanted and illegal access.

And, as I’ve shown in this blog, there’s a serious impact to privacy when using a scooter sharing service – an impact that could also be relevant to other services that expose trackable IDs over APIs.

Vendors must therefore also take steps to protect the privacy of their users – and of their own business data. OWASP API security Top 10 – API3 is about just that – Excessive Data Exposure.

At the very least, providing as little information as possible to the mobile app, and changing the ID used by the app itself after each ride will go some way to preventing anyone tracking their scooters.

Users of scooter-sharing services should be mindful of the potential risks involved. It’s perhaps an unfortunate statement on life today but, just as you would – hopefully – understand the ramifications of granting an app permissions to access resources on your smartphone, so too should you understand the possible implications of using a scooter-sharing service.

The popularity of scooter-sharing looks set to grow over the coming years. The hope is that, with the right precautions in place, more people will benefit from its advantages and enjoy the freedom it offers, without the risk of physical harm, and without suffering the same fate as my unfortunate hypothetical neighbor.

Ride safely and watch your back!

The post I know where you rode last summer: Uncovering the security issues of shared scooter services appeared first on Blog.


Source: imperva

Recommended Posts

Leave a Comment