Below is the response, containing GPS coordinates as well as the user’s birthday:
The other scenario we encountered is where a developer returned the same verbose user model data for multiple request types, picking and choosing the parts to consume within the application with each response. In this scenario, they return more than they need to simply out of convenience. These developers may not have fully understood that an attacker could still intercept and view this data if it was being leaked back to the client even if their application did not display it directly to the user. Intercepting proxies such as Burp and ZAP allow an attacker to intercept all web traffic between a mobile app and a backend web service, even if SSL is in place. There are techniques such as certificate pinning that make this type of self-interception more difficult, but generally these techniques can be bypassed.
The distance between yourself and another user can be used to triangulate their actual location even if the application doesn’t return their GPS coordinates. As an example, the Skout application returns a user’s exact distance with very high precision from you within their public profile:
How is it possible to turn the distance into an exact location? The distance is calculated from your current position. If your position changes, so will the distance between you and your target user. By manipulating your position and triangulating each point, you can narrow the person’s location down to a range of only a few feet. This issue was pretty prevalent within the set of applications we looked at, and in most cases, very similar, if not identical to an issue found on Tinder a few months ago. As it appears, no one must have been paying attention.
Another method for figuring out a user’s location and potentially their identity is to use EXIF information extracted from their uploaded images. EXIF information typically includes data such as the time a picture was taken, the type of camera, geolocation, and many other fields. By default, the iPhone and some Android phones geotag pictures taken with your phone. When these images are uploaded, this information isn’t always stripped, allowing for someone to extract the location the picture was taken. There are plenty of open source and free tools that can extract this information in an easily readable format.
Transport Layer Protection
Insufficient Transport Layer Protection was another issue found to be pretty prevalent within the pool of mobile dating apps we examined. This is described well by OWASP. Most of the issues we found fell into a few different areas:
However, clearly that’s not the case:
Many apps also implemented ad networks and analytics tools. A considerable amount of these libraries leaked identifying information about the users to third parties, often over an insecure communication channel. The majority of apps leaked at least one piece of identifying information to a third party, including:
- Your actual credentials
- Geolocation data
- Your MAC address
- Your device ID
- Your sexual preference Here is an example of the Skout application sending your GPS coordinates to an ad network in plain text:
In the case where an application did use SSL, the implementations weren’t always perfect. Certificate exceptions were frequently handled by silently ignoring the errors, both within iOS and Android applications. This issue usually pops up as a result of a developer trying to use a self-signed certificate in development and not understanding the impact of doing this in a production environment. An example of this was found within the Jaumo app on Android. The code below shows their TrustManager implementation:
In addition to SSL implementation vulnerabilities, we also discovered several best practices to be completely absent across the board. Certificate Pinning wasn’t in use anywhere. Perfect Forward Secrecy wasn’t deployed anywhere.
In addition to being able de-anonymize you as well as intercept your data, a significant amount of information about you is stored on your device. This includes your credentials, location history, message databases, and more. Some of the apps we found to be the worst culprits include:
- Ashley Madison
- Singles Around Me We found very few applications that implemented a local app passcode lock. The purpose of having this in place is to try to prevent your significant other or anyone curious from reading your data if you left your phone unlocked or if they knew your passcode. This could be implemented as a 4 digit pin or a longer string. An implementation of this concept for iOS can be found here.
The Ashley Madison Black Book app is used for being “discreet” by using a disposable phone number, “private” text messages, and a “confidential” contacts list. This is the type of app that says “I’m up to no good”, basically.
Black Book was one of the few applications that used a local app passcode lock, and we found a bunch of implementation flaws. It has a local app passcode lock that’s 4 digits in length.
While this is certainly a decent deterrent against the lazy or non-technical, someone with enough motivation and skill plus physical access to your device will likely win. I know for a fact that if my wife ever found this app on my phone, she would try to guess the password until her fingers hurt. Or, maybe she would use a robot.
First, the application doesn’t wipe your data after an excessive amount of failed unlock attempts, nor does it give you the option to. This means your spouse who thinks (and is probably right) that you are up to no good can try again and again and again to unlock this data. I’d recommend not using your anniversary as your passcode.
Second, both your local passcode as well as your account credentials are stored locally. Your account credentials are stored in plain text, while the app attempts to encrypt your stored local passcode. If you are one of those cool kids who uses a rooted or jailbroken device, you make it even easier to recover this information. The internet is filled with tutorials and 1-click tools to make this easy for anyone semi-technical and motivated.
Your local passcode is stored encrypted on the device. While this is only a 4-digit pin, changing this to a longer, more complex value would still be a degraded solution because it is symmetrically encrypted with AES with a hardcoded key. Here is decompiled code from the com.hushed.base.providers.SecurityProvider.java class:
Within apps like Skout, your password is stored in plain text within both iOS .plist files as well as Android’s SharedPreferences:
We also found a bunch of Plain Text Offenders who email your credentials to you in plain text. What this means is if they are sending your password to you in plain text, they are also storing it in plain text within their database or with a symmetric encryption algorithm. These culprits certainly have some room to tighten up their approach to secure password storage. Here is an example of Match.com emailing a plain text password:
These are just a few examples of the many problems we found. In our opinion, the current crop of mobile dating apps puts user privacy and safety at great risk. While we can argue that users should read an app’s terms and conditions as well as the end user licensing agreement, in reality, most users don’t read them nor would they understand most of the intentionally vague legalese. Hence, it is up to the developers of these applications to be responsible with the data they collect and how they protect it.
As a user of these applications, we recommend a few ways to stay safe:
Review the app’s settings and opt out of things that seem questionable
Download the full-sized infographic here.