A GAPing Security Vulnerability
In early November 2020, we uncovered a series of critical security vulnerabilities relating to the mobile dating application ‘Gaper‘ . There are approximately 800,000 users of the Gaper mobile application, with the majority of users being from either the United Kingdom or United States of America.
Taken from Google Play store, Gaper describe their application as:
“The best alternative craigslist personals app for seeking age gap arrangement. This is an age gap dating and social networking app, specifically designed for older men dating younger women and older women dating younger men to build a long term & serious relationship.”
Alongside various smaller risk security and privacy issues, we identified that it was possible to compromise any account on the application, within a 10 minute timeframe.
With Gaper being a dating focused mobile application, we knew that large amounts of sensitive information would be processed as part of its standard use. We wanted to make sure that this data was suitably secure.
TL;DR – It wasn’t.
We started with looking at the builds for both Android and iOS at a static level.
We first used various mobile testing tools including Frida and Objection to identify if there were any hardcoded keys or credentials that were used to connect to the backend services. After briefly looking through the builds, we were able to find a handful of keys, but nothing of any particular interest.
We then created an account on the application and looked again for keys and other data that may now be stored within the keychain or other areas of the builds. Again, nothing of particular interest – but always worth a look for potential quick wins.
With our newly created account we started identifying key areas of functionality within the app. We found various functionality to ‘like’ other users, upload photos and manage our profile. Functions such as sending messages were locked behind a paywall, so this was never looked at in any depth.
Certificate pinning had not been enforced within the application, allowing us to utilise a HTTP proxy (BurpSuite) to ‘man in the middle’ the HTTPS traffic and easily enumerate functionality.
A function that stood out to us was the ‘info’ function. This function could be accessed via the follow GET request:
This function takes the current users session token (denoted by the xxx…) and an argument of a user ID. This request allows any authenticated user to query the data of any other user, providing they know their user_id value. Fortunately for us, this user_id value is set upon signup and is simply incremented by 1 each time a new user is created.
For the example we created a new account, with fake details and identified its user_id was 788991.
The response of this function can be seen below:
“name”: “United Kingdom”,
From this response we can see that a substantial amount of data can be retrieved from the API. Data such as email address, date of birth, location and even gender orientation can be obtained. This information should not accessible for users to retrieve from the API, especially dates of birth and email addresses.
An attacker could iterate through the user_id’s to retrieve an extensive list of sensitive information that could be used in further targeted attacks against all users of the application.
Furthermore, user uploaded images are stored within a publicly accessible, unauthenticated database – potentially leading to extortion-like situations.
With the obtained email addresses from above, we then looked at how we could gain unauthorised access to another account. It would have been trivial to perform a brute force attack against the login function of the application, using the list of email addresses, combined with a set of commonly used passwords.
This attack however could have potentially locked every user of the application out, which would have caused a huge amount of noise and to us felt quite ‘skiddy’.
Instead, we opted for a ‘cleaner’ approach – abusing the forgotten password feature.
The forgotten password API takes the following format:
If a valid email address is used, the API will respond with a 200 OK and will send an email to the user containing a 4 digit PIN number. The user would then submit this, with their new password and their password would subsequently be changed.
The issue we identified here was a lack of rate limiting / brute force protection on the actual password change API. As a result of this, it was possible to first request a PIN number for a valid email address and then rapidly send multiple requests to the password change API each containing a variation of a 4 digit PIN.
(Formatting and current pin appear off due to threading, don’t hate us 😀 )
This ultimately leads to a complete compromise of arbitrary user accounts, as only a single factor of authentication is required to log in.
In summary we have highlighted how a lack of: access controls, brute force protection and multi-factor authentication ultimately led to a complete compromise of arbitrary user accounts within the Gaper application.
This was not an attack based upon 0-day exploits or advanced techniques and we would not be surprised if this had not been previously exploited in the wild.
If you feel your organisation may benefit from mobile application penetration testing, do read more about our service here.
We reached out to Gaper multiple times via Email – which was their only support channel. We unfortunately never heard back from them. As a result, we have waited 90 days in line with Google’s responsible disclosure policy before releasing details of these issues.
Talk To Us!
Get in Touch To Discuss Your Requirements.
© 2021 Ruptura InfoSecurity Limited. All rights reserved.
Company No 11644559 | Suite 122, Milton Keynes Business Center, Linford Wood, Milton Keynes, MK14 6GD