in

Dating : User Information Disclosure in Dating Apps

h2>Dating : User Information Disclosure in Dating Apps

Extracting user data from mobile apps to craft exploits.

Brendan Ortiz

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)

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:

Hinge

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.

Read also  Dating : Dark Futures

What do you think?

22 Points
Upvote Downvote

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *

POF : Clicking « Maybe » in MeetMe will pollute your Likes List

POF : Does anyone else get hate mail because of their preferences?