September 1, 2023

Moovit API Vulnerability - letting attackers move free of charge

During Defcon, a security researcher presented his findings from assessing a global transportation system called Moovit. He successfully identified and exploited vulnerabilities that would allow anyone to get free rides and access the PII of customers via APIs.

At Defcon, the biggest information security conference in the world, SafeBreach’s Omer Attias presented a number of vulnerabilities he found in Moovit’s API, which allowed any attacker to get free rides and access the PII of customers.

About Moovit

Moovit is an Israeli company which provides public transportation payment and planning systems. This kind of operation run by companies is called Mobility-as-a-service (MaaS). MaaS allows users to “plan, book, and pay for multiple types of mobility services all in one mobile application”. That makes Moovit a MaaS operator.

In this article we’ll give an overview of the vulnerabilities found and presented in Defcon that allowed payment bypass and access to customer data via Moovit’s API.

Vulnerability #1: Adding the attacker’s phone to the victim’s account

This vulnerability would allow an attacker to add their phone to the victim’s account and pose as an extra device of the victim. This means the victim would pay for the rides of the attacker.

To achieve this, an attacker:

Uses the CreateUser API request
Gets a UserKey from the response
Adds their device to the victims account by providing the victim’s phone number and the UserKey to the appropriate API request
Bruteforce the OTP the victim receives

This comes with some problems for the attacker. They must know the victim’s number and the victim disconnects from their account during the attack, which can be an indicator of compromise. Later we’ll see how this problem can be solved.

Vulnerability #2: Token similarities allows bruteforcing of victims’ UserKeys

Moovit was using Oracle’s SYS_GUID tokens as the users’ UserKeys. SYS_GUID tokens are built based on some constants and guessable variables, which reduces the amount of effort needed by an attacker to guess the UserKey of a victim or to generate all possible UserKeys to a realistic level of approach. For each user the UserKey also plays an identifying role. Thus, by reaching the appropriate API call and providing it the correct UserKey, an attacker can get the phone number that belongs to the user with that specific UserKey. This eliminates an important constraint in exploiting Moovit’s API service.

Vulnerability #3: Unauthorized access to users’ accounts

In the third and final vulnerability, an attacker can get unauthorized access to a victim’s account by obtaining their Access Token. This can be achieved through the device setup steps.

Specifically, the attacker:

Uses the CreatUser API request
Gets a UserKey from the response
Registers the device to the victim's account by submitting the OTP received
Receives a Token
Make the VerifyCustomToken API call, which validates the user by submitting the UserKey and the Token the attacker received
Finally gets the Access Token that allows them to access the victim’s account

This results in unauthorized access to users’ PII, which includes full names, email addresses, credit cards and their current ride.

Assessment

The attack vectors for all three vulnerabilities are part of the OWASP API Top 10 2023 list. The most commonly occurring risk in all of the three vulnerabilities is API2:2023 Broken Authentication.

In the case of Vulnerability #1, Moovit doesn’t validate the ownership of the device that the attacker adds to the victim’s account. This lack of authentication mechanism allows the attacker to use transportation while the victim is paying the fares, as if the victim is riding. Even if an OTP is sent to the victim’s phone to allow the new device, the device is being added anyway.

Fix: Moovit should first notify the victim and wait for their confirmation to allow a new phone to access the account.

In Vulnerability #2, we again see violation of the authentication process, specifically because of the “use of weak or predictable tokens to enforce authentication”, referring of course to the weak Oracle SYS_GUID UserKeys. Also, allowing the bruteforce of the UserKey, plays a big role (if not the biggest) in the exploitation path. Both issues fall under the OWASP API Top 10 category. First API2:2023 - Broken Authentication, because of its use of “weak or predictable tokens to enforce authentication” and API6:2023 - Unrestricted Access to Sensitive Business Flows, because of its lack of rate-limiting mechanisms.

Fix: Instead, the use of UUID v4 or v5 should be enforced for truly pseudo-random key generation. And a defense mechanism against bruteforcing that will limit the amount of requests per second sent to the endpoint.

The third vulnerability is the combination of the previous two vulnerabilities, that allow the attacker to connect to the victim’s account. That means that this is also the product of broken authentication.

How can FireTail help?

For companies building their own API-based service offerings, there are a few crucial considerations:

Do the API providers have good design principles on key data structures sitting behind those APIs?
Are the API providers checking traffic for indications of attacks?

FireTail provides full visibility onto APIs - where they are in cloud environments, what configurations and specifications they have, as well as what utilization. FireTail can help API providers understand these risks, both from a consumption and coding standpoint, in advance of breaches.