Reverse Engineering Bumble’s API (2020)

Reverse Engineering Bumble’s API

When you have too much time on your hands and want to dump out Bumble’s entire user base and bypass paying for premium Bumble Boost features.

As part of ISE Labs’ research into popular dating apps (see more here), we looked at Bumble’s web application and API. Continue reading as we will demonstrate how an attacker can bypass paying for access to some of Bumble Boost’s premium features. If that doesn’t seem interesting enough, learn how an attacker can dump Bumble’s entire user-base with basic user information and pictures even if the attacker is an unverified user with a locked account. Spoiler alert — ghosting is definitely a thing.

Updates — As of November 1, 2020, all the attacks mentioned in this blog still worked. When retesting for the following issues on November 11, 2020, certain issues had been partially mitigated. Bumble is no longer using sequential user ids and has updated its previous encryption scheme. This means that an attacker cannot dump Bumble’s entire user base anymore using the attack as described here. The API request does not provide distance in miles anymore — so tracking location via triangulation is no longer a possibility using this endpoint’s data response. An attacker can still use the endpoint to obtain information such as Facebook likes, pictures, and other profile information such as dating interests. This still works for an unvalidated, locked-out user, so an attacker can make unlimited fake accounts to dump user data. However, attackers can only do this for encrypted ids that they already have (which are made available for people near you). It is likely that Bumble will fix this too within the next few days. The attacks on bypassing payment for Bumble’s other premium features still work.

This research was covered by Forbes.

Reverse Engineering REST APIs

Developers use REST APIs to dictate how different parts of an application communicate with each other and can be configured to allow client-side applications to access data from internal servers and perform actions. For example, operations such as swiping on users, paying for premium features, and accessing user photos, occur via requests to Bumble’s API.

Since REST calls are stateless, it is important for each endpoint to check whether the request issuer is authorized to perform a given action. Additionally, even if client-side applications don’t normally send dangerous requests, attackers can automate and manipulate API calls to perform unintended actions and retrieve unauthorized data. This explains some of the potential flaws with Bumble’s API involving excessive data exposure and a lack of rate-limiting.

Since Bumble’s API is not publicly documented, we must reverse engineer their API calls to understand how the system treats user data and client-side requests, especially since our end goal is to trigger unintentional data leakage.

Normally, the first step would be to intercept the HTTP requests sent from the Bumble mobile app. However, since Bumble has a web application and shares the same API scheme as the mobile app, we’re going to take the easy route and intercept all incoming and outgoing requests through Burp Suite.

Exploring Bumble Boost

Bumble “Boost” premium services cost $9.99 per week. We will be focusing on finding workarounds for the following Boost features:

1. Unlimited Votes
2. Backtrack
3. Beeline
4. Unlimited Advanced Filtering — except we are also curious about ALL of Bumble’s active users, their interests, the kind of people they are interested in, and whether we can potentially triangulate their locations.

Unlimited Votes

Bumble’s mobile app has a limit on the number of right swipes (votes) you can use during the day. Once users hit their daily swipe limit (approximately 100 right swipes), they have to wait 24 hours for their swipes to reset and to be shown new potential matches. Votes are processed using the following request through the SERVER_ENCOUNTERS_VOTE user action where if:

• “vote”: 1 — The user has not voted.
• “vote”: 2 — The user has swiped right on the user with the person_id
• “vote”: 3 — The user has swiped left on the user with the person_id

SERVER_ENCOUNTERS_VOTE endpoint

On further examination, the only check on the swipe limit is through the mobile front-end which means that there is no check on the actual API request. As there is no check on the web application front-end, using the web application instead of the mobile app implies that users won’t ever run out of swipes. This peculiar frontend access control method introduces the other Bumble issues in this blog — several API endpoints are processed unchecked by the server.

Backtrack

Accidentally swiped left on someone? This is no longer an issue and you definitely don’t need Backtrack to undo your left swipe. Why? The SERVER_ENCOUNTERS_VOTE user action does not check if you have previously voted on someone. This means that if you send the API voting request directly, changing the “vote”: 3 parameter to “vote”: 2 you can “swipe right” on the user of your choice. This also means that users don’t have to worry about missed connections from 6 months ago because the API logic does not perform any sort of time check.

Beeline Part I

The Beeline is one of the main features of Bumble Boost as it allows users to view all the people who have swiped right on them.

When we studied the network traffic using the Developer Console, we found a SERVER_GET_ENCOUNTERS endpoint that displays all the users in our potential match feed. What’s interesting to note though, is that it also displays their vote and we can use this to differentiate between users who haven’t voted versus users who have swiped right.

from Hacker News https://ift.tt/2UyjWNk