e-Ticketing is an emerging type of mobile application that allows users to take public transport without requiring them to choose the destination and transport type in advance. Instead, user location is tracked along their route, and once this is stopped, the traveled distance is used to bill the user.
We identify this type of application to be fundamentally vulnerable to an attack which we call FreeRide. As a proof of concept, we demonstrate that a malicious user can travel for free across Switzerland by crafting fake locations (Fig. 1). Because the issued ticket becomes immediately valid, it was deemed as valid when it was checked by the ticket controllers. In the paper, we describe how to mitigate FreeRide with PayRide, a novel mitigation that preserves the link between the location of the user and that of the smartphone. We refer you to our paper that provides more details about FreeRide and PayRide.
Disclaimer
We would like to point out that using public transport without a valid ticket in Switzerland has consequences under criminal law. During our experiments with FreeRide, we therefore always carried a valid ticket.
Fig. 1: FreeRide local. A malicious user is on public transport. The application backend receives location updates corresponding to walking, providing the malicious user with a free but valid ticket.
How does FreeRide work?
Smartphone applications like EasyRide request the smartphone location from the operating system. For high accuracy, the operating system returns the position obtained via GPS. However, there is no guarantee that this location corresponds to the real user location.
For example, the operating system can be changed to provide the application with fake positions of walking patterns. Alternatively, the GPS signal can be spoofed or the application can be manipulated.
FreeRide uses fake positions to trick the e-Ticketing application. While the tracking functionality is active, the user has a valid ticket. However, the data used to bill the user is generated to appear as if the malicious user is walking (walking with a valid ticket does not incur a charge). We call the attack based on modifying the location locally on the smartphone, FreeRide Local. In the paper, we also discuss FreeRide Remote which bypasses GPS-signed locations.
What is FreeRide Remote?
Currently, the GPS data is not signed. In other words, applications cannot know if the operating system has maliciously modified the data. However, even in the presence of GPS signing, FreeRide attacks would still be possible. We call this type of attack, FreeRide Remote as shown in Fig. 2.
The application requires a signed location data. In this case, the malicious user redirects the request to a different device in a different location, which signs the GPS value and returns it to the malicious phone.
Alternatively, a malicious user could also spoof the GPS signal to bypass integrity, but that might be unwanted and it is a much more technical attack. In a similar way, wormhole attacks could be employed, where the location signal is replayed at a different location.
Fig. 2: FreeRide remote. An online server requests the user’s location. The malicious user forwards the request from the first to the second device. The second device is used to sign a different location (B) with its TEE and sends the signed location back.
How does PayRide work?
PayRide is our proposed mitigation against both types of FreeRide attacks. It is based on four requirements:
- Rely on the deployed infrastructure.
- Avoid relying on other users to achieve security.
- Assume that the reported location is untrusted.
- Do not rely on the ticket controller to verify the location.
The mitigation is conceptually simple (Fig.3). The user location must be sent periodically to the backend. When the ticket controller checks the EasyRide ticket, the server compares the transport location to the user location. If they differ more than by an allowed margin, the user is fined.Because the location can be sampled only periodically and the transport moves, the comparison happens with stale data. Further, GPS positions can have a low accuracy. We carefully studied their effects and included them in the design of PayRide.
Please read the paper for a detailed explanation!
Fig. 3: PayRide protocol. The user’s phone sends periodic GPS updates to the server backend, at most every T_GPS seconds. During a ticket inspection, the ticket inspector triggers the comparison of the user’s location with the transport location on the server by sending the user’s ID. If the user’s location does not match the transport location within an allowed margin, the user is fined.
How does the attack scale to non-technical users?
In the paper, we demonstrate that a malicious user can implement a Location-spoofing-as-a-Service (LSaaS) by emulating devices on Android studio. The emulator (based on QEMU) allows for the generation of GPS signals that are interpreted as real by applications such as EasyRide. Multiple device clones are generated to create free tickets for different users, organized by an automated orchestrator. A non-technical user would simply connect to a webpage to get a free ticket.
Fig. 14: Location-spoofing-as-a-Service (LSaaS) allows scaling the attack to non-technical users.
Responsible disclosure
We coordinated a responsible disclosure with SBB and were able to discuss FreeRide and its mitigation PayRide in a meeting with the company. SBB has assured us that effective measures have since been implemented to prevent the use of FreeRide.
More information
Our paper, PayRide, is available now and will officially be presented at DIMVA 2024 in Lausanne, Switzerland.
FAQs
Following, we provide answers to the most frequently asked questions about our work.
- What phone did you use?
We used a rooted Pixel 5.
- How did you find this vulnerability?
We were sitting on the tram on our way back from our yearly retreat, when we started wondering how EasyRide actually works. We thought relying on GPS data must be difficult, since it is inherently untrusted and it would be interesting to find out how EasyRide is doing it. This led to the initial version of the FreeRide attack performed by Jason Zibung as part of his bachelor thesis.
- Why did you not solve FreeRide in this X way?
We are sure you have many valuable ideas and that there are multiple ways that FreeRide could be addressed. We proposed PayRide based on four requirements: (1) using deployed infrastructure, (2) avoiding relying on other users for security, (3) not trusting the reported location, and (4) not relying on the ticket controller to manually check the location. The paper has an extensive discussion on why existing mitigations fail to meet these requirements.
- Should I worry?
No.
- Are FreeRide Remote attacks practical?
Depending on the deployed mitigation, the technical requirements for FreeRide Remote attacks can vary substantially. We believe if future technology implements PayRide (or a similar variant), tampering with the location will be very difficult to do in a stealthy manner.
Acknowledgments
This work was supported by the Swiss National Science Foundation under NCCR Automation, grant agreement 51NF40 180545, and the Swiss State Secretariat for Education, Research and Innovation under contract number MB22.00057 (ERC-StG PROMISE).