User Information Disclosure in Dating Apps

Extracting user data from mobile apps to craft exploits.

This blog post documents the bugs and security findings identified while analyzing two mobile dating applications. Through an OPSEC lens, these apps pose a significant tradeoff on privacy for social interaction; nonetheless they are extremely popular. When using these apps, people may not consider whether their private information is being handled securely. The following research on the mobile applications Hinge and 3ndr(3Date) will show how user information extracted from these applications can be leveraged in real world attack scenarios.

Users of any application — mobile or not — should think carefully about the information they post online. Just because an application is approved for use in the Apple or Android app store, does not indicate whether it has been thoroughly assessed for security vulnerabilities.

Downloading apps from your phone’s native store is routine and you probably don’t think twice about it.

3ndr(3Date/3way)

The first finding we’ll discuss involves several verbose error messages in the 3ndr application.

The 3ndr application returns very verbose messages that allows attackers to extract information that may increase the attack surface of the application. See the code snippet below for an example:

In this code block, we can identify pieces of information in the response that leak information about the API. For example, the server name and its version are returned. This may allow attackers to identify unpatched software.

The response also indicates that the password we entered is incorrect, allowing the attacker to determine that an account has been registered with that email address.

Another issue we identified involves sensitive user information returned by the API. When a user’s profile is requested by a normal authenticated user, the API response is similar to the following:

In this response, attackers can view the following information:

• User Emails
• Usernames
• Mobile Numbers if available
• User ID’s (Sequential Integers)
• GPS Longitude and Latitude
• Birthday
• Last Login Time

An important thing to note is that this request is not rate-limited and user identifiers are sequential, allowing attackers to enumerate this data for many users.

Another interesting bug found in the application leads to the identification of the backend web server software running on the system:

By using an HTTP request method that was unexpected by the web server, the Apache TomCat software responded with default behavior, which shows us the server software version. If this version was vulnerable to an attack we would have no problem finding and using an exploit.

The 3ndr application has a subscription-based service that makes a user ‘gold status’. To match and chat with other users, you must subscribe to this service.

Another bug found in 3ndr allows you to force matches with other users if you don’t have gold status in the application. This attack requires the user to have liked you already, however, if you don’t have gold status you can’t match with them.

To perform the attack do the following:

1. Navigate to your ‘likes’ page to view profile ID’s of users that have liked you
2. Then request a match using the ‘match/like’ endpoint with the UserID previously extracted.

The attack looks like the following:

Finally, I will discuss why 3ndr not implementing rate limiting implementation is concerning under these circumstances.

3ndr’s application has several design / implementation level vulnerabilities that allow anyone to extract user information. Additionally, there are no defense mechanisms in place to slow down attackers. This combination allows attackers of any skill level to abuse 3ndr’s user base. Performing this attack would require the following steps:

1. Create a user account in the 3ndr application (free and easy)
2. Go to a user’s page by clicking on another user’s profile
3. Extract that request & repeat it, replacing that user’s ID with a lower one incrementing the value on each successive request
4. Extract the user’s information from each request that you deem necessary to carry out further attacks such as an email address
5. Brute force login attempts using targeted user’s email addresses
6. Attempt to login using the credentials identified in this process in other applications

I performed this attack using test accounts to prove this can be done. Total time of the attack was less than 3 hours.

The above photo is a successful brute force of a test account in the 3ndr application using Hydra. In a real attack scenario, the attacker would now attempt to use those credentials to login to other applications such as banking platforms, social media, etc.

To top it off, I was able to identify what appeared to be an admin account for the 3ndr application. However, I believe it was a fake admin account used for in-app phishing scams. The 3ndr application does not validate email addresses and has insecure password setting requirements. The former, allows any user to make an account using an email such as ‘3ndr-Admin@3ndr.com’, and the latter, allows for attackers to easily credential stuff or brute force passwords.

Hinge

Next, we will discuss an issue in the Hinge dating application that allows attackers to view content that has been posted to users’ Instagram profiles.

In Hinge, users can link their dating profile to their Instagram which allows Hinge to pull content from Instagram. Whenever a user with a linked Instagram is presented as a potential match, a request is made that requests the latest 27 posts from the matched user’s Instagram and adds it to the potential matches’ profile. However, the number of posts to extract is a request parameter that can be controlled by an attacker. Because Hinge is granted extra permissions to the victim’s Instagram account, an attacker can use the Hinge API to obtain an arbitrary number of Instagram posts, even if the victim’s Instagram profile is private.

In this scenario, we are using Hinge and its enhanced access to Instagram as a proxy to view private content. The data returned from this request can be seen below:

1. A signed link, which expires after a few days, to view the Instagram photo
2. The ID of the photo
3. Timestamp of when the photo was uploaded to Instagram
4. The caption that was uploaded with the photo
5. The type of media content: video or photo.

The following is an example of how to use Hinge’s API to retrieve this information, and a sample response showing the data returned:

It is difficult to enumerate content for all users however, as user identifiers are non-sequential.

There are additional factors to consider. Since this is a dating application, the users most likely to be targeted are based on geographic proximity, which can range from 1 to 50 miles. using extracted Instagram content, the attacker could then perform reverse image lookups or manual analysis of the Instagram images in order to find out information that could be dangerous to the legitimate user. Examples include pictures in near or inside homes, in or outside of areas of work, or even with clubs and groups.

ISE would like to thank Hinge for working with us during this disclosure process. Their security team was easy to reach and kept in touch with us throughout the process.

Coordinated Disclosure Timelines

3ndr(3Date/3way)

• April 17, 2020: Contacted 3ndr about sending vulnerabilities over.
• June 24, 2020: Contacted 3ndr about sending vulnerabilities over.
• July 8, 2020: Contacted 3ndr about sending vulnerabilities over.

3ndr has not responded to any of ISE’s emails.

Hinge

• June 10, 2020: Contacted Hinge Support about sending vulnerabilities over.
• June 17, 2020: Contacted Hinge Security Team about disclosing vulnerabilities. Received a reply the same day.
• June 23, 2020: Disclosed the vulnerability to the Match Group Security Team.
• July 9, 2020: Vulnerability mitigation confirmed.

Brendan Ortiz is an Associate Security Analyst at Independent Security Evaluators, a firm of security specialists that provide a wide range of services including custom security assessments and software development. ISE also runs IoT Village, which hosts talks by expert security researchers who dissect real-world exploits and hacking contests consisting of off-the-shelf IoT devices.

Twitter: @ISESecurity

Sign up to get our latest blogs.