On July 9th I was able to access sensitive information from every account on link.social’s app. This information includes: phone number, last location (accurate to within 10-15 feet), birthday, and if they verified their identity with a government photo ID card, and some other less sensitive fields. In addition to this, I found a simple exploit that allows me to hijack any account on the platform.

I disclosed what I found to the LINK team on July 10th 2022, the next day early on Monday on July 11th they responded and said they were working on a fix. On the 12th they thanked me for bringing it to their attention and sent me $500 (which was nice) and they updated their app to fix it, although trilateration to find location might still possible.

Table of Contents

LINK is another social media startup app that enables you to meet people local to you with the same hobbies as you in a group setting. They’re currently in a beta stage with testing on the iOS test flight app. Despite being in beta, they’re running social media campaigns trying to get people to use the test flight app and have around 6.5K users while writing this.

Each user has a profile where you can select different hobbies that you have and you’ll be given other people with your hobbies in your local area as defined by your range limit. If both users select to “link/connect” with each other they’ll be able to talk in the app.

I discovered this app when as a part of their social media marketing campaign they requested to follow me on Instagram and I decided to check out their system a little.

What Data is Exposed

  • Personal Sensitive Information (on every user, even if you’re not logged in as that user)
    • phone number
    • birthday
    • last known location
    • full name
      • Not sensitive by itself, but in combination with other information can be damaging
    • id verified
      • The app asks users to verify with their government issued ID using a 3rd party (not required though)
      • Can use this to see if the account is really who they’re claiming to be
  • Account hijacking
    • If you know the user id (easy to find) you can hijack any account and get authorization tokens for it
    • Do anything that typically requires a user to be logged in
      • Profile changes
      • Send/read messages
      • Update user’s saved location

Why This Is A Problem

Location Data

I won’t go into too much detail, but checkout my article about YikYak Is Exposing User Location Data for some deeper location data specific comments. However, this is much more dangerous than YikYak as not only were precise locations (accurate to within 10-15 feet) exposed but full names were associated with the location. This escalates the dangers compared to YikYak as it really enables targeted attacks using a person’s location data.

Some things a malicious attacker could use this for

  • Stalking a particular user who might’ve denied their link request on the app
  • Knowing when a particular individual might be home or not
  • Using the other personal information to reverse search that user and find out their exact address to escalate this stalking potential
  • An abusive partner could use this data to find the location of a former partner trying to escape and hide from them
  • Unlawfully surveil people across time (accuracy depends on how frequently they open the app)
  • I’m sure you could come up with some other potential consequences
Phone Number & Name
  • Reverse person search to find even more information about a particular individual
  • Telemarketers could utilize this information
    • Access to birthdays could target older people using the app for scams
    • Hobby information is also included in the app, so highly targeted ads towards hobbies of a user could be used in this direct texting marketing campaign
Account Hijacking
  • Tons of options here but not as dangerous as the sensitive information above
  • Can delete any account
  • Marketers could change profile/bio to advertise a service
  • Huge volumes of spam could arise
  • Any consequence having someone take over your account

Vulnerabilities

Exposing Sensitive User Information

This is another case of an app sending back ALL information about a specific user rather than just the information needed in the client. This sensitive information is never exposed to the end user since the app itself filters it down, however this unnecessary sensitive information should never be sent to the app itself, as it’s typically easy to intercept this information.

All of this information is returned on the “feed” page where you can view the accounts you haven’t interacted with so far. This data is also returned when you view a user’s profile which the endpoint for that looks like {user_id}.json. The user ids in the database just increment themselves by 1, so it’s extremely easy to write a script that iterates over every user in the database and just makes a request to this endpoint to retrieve all the user data.

Mitigation

The best way to fix this, is ensuring that only the information needed in the app is actually sent to it. For example: If the developers wanted an option in the app to get a person’s phone number they should ensure that this field is only sent after both parties have hit that button. Sending unnecessary information that should never be needed like birthday, precise last location, and other strange things like the phone confirmation number, should never be sent to the client. It’s typically extremely easy to intercept this information and you should assume that any information that’s sent out of your API server is accessible to the end user.

For ensuring that exact location isn’t visible or calculable, check out my YikYak mitigation recommendations for more details but here’s what I recommend.

  • Truncate the GPS coordinates on the app itself so that when the location is sent to the server it’s not super accurate.
    • I recommend cutting it off around the 2nd decimal place, as this will make the data inaccurate to within ~3 miles (Wiki GIS) which should protect user privacy
  • The API should never return an exact location, rounding the distance should be done on the server to be accurate to within a few miles
    • This could also be randomized every time a user requests the location from a profile by a few hundred feet just for more protection

Account Hijacking

This is where it gets fun :)

The ordering of the API requests to create an account within the app was the following

  1. /create
    • body
      • phone number
    • returns
      • user id
  2. /users/{user_id}/code/{confirmation_token}
    • body
      • confirmation number from text
    • returns
      • user information for that particular user_id if successful, or a failure message if token invalid
  3. /user/get_token?userId={user_id}
    • no body
    • headers 
        {
      "userid": "null",
      "accept": "application/json",
      "user-agent": "Link-Production/239 CFNetwork/1333.0.4 Darwin/21.5.0",
      "accept-language": "en-US,en;q=0.9",
      "authorization": f"Bearer null",
      "accept-encoding": "gzip, deflate, br",
  }
    • oh no
    • returns
      • auth_token
      • refresh_token

If you don’t see it, in the headers of step 3, there is NO AUTHORIZATION REQUIRED to get auth tokens for ANY USER. This allows us to arbitrarily put in any user id into the url parameter of userId and we get auth tokens for that user. This allows anyone in the world to interact with any account as if they were signed in as that user.

The auth token is used by the server to ensure that only the correct person is able to modify some resource. Like if a person is trying to modify their profile bio, then the server ensures that the profile they’re trying to modify has the same user id that the auth token was generated from. So in most ways, auth tokens are actually even more dangerous to have than a password as these days two factor authentication stops most unauthorized logins.

Mitigation

Despite this huge security oversight, it’s not too difficult to fix. When creating an account it should return the authorization tokens for that account. This way, only the person who created (or signed in) with that account has the tokens. The auth token should then be passed to every subsequent request and verified that the user data it’s trying to modify aligns with that auth token.

Location Visualization

I collected some of the exposed locations for a short amount of time after the disclosure. I figured it would be a waste not to share a visualization.

Note: I’ve taken steps to protect the privacy and safety of LINK users

  • Randomizing coordinates in the magnitude of tens of miles.
  • Restricting locations to be in North America, as most users are from America and I don’t wanna look at GDPR laws.
LINK User Locations
Visualization of LINK user locations (click for interactive map)

They were relatively prompt with fixing the app and the issues that I mentioned, and fixed it by the end of the 2nd business day. The one bit of information still exposed is the birthday of a user, which isn’t that big of a deal however it would be nice to see it calculated server-side.

I think the response from them was great, however I do find it concerning how insecure their system was while storing tons of user data.

Takeaways

  • Always assume that the information you’re sending away from your database can be viewed by the client and consider the risk of that
    • If it’s an app, imagine the end user is able to see all that information for themselves
  • Ensure that authorization tokens are only sent back when you know for sure that the person requesting them is really that user
    • They should only be sent back after a successful login or an account creation
    • Should never be able to get an auth token without providing credentials or making a new account
  • Always analyze and ensure that your system is secure even if you were to provide the public with the exact API documentation of your app
  • Be cautious of what data you’re giving to apps especially new ones
    • The app was using a 3rd party service to verify identities using photos of photo ID cards
    • As far as I know there wasn’t any data leaks around this, but based on how insecure their servers were I personally wouldn’t trust an app to manage my ID
  • Don’t follow security researchers on Instagram as part of a marketing campaign if your app isn’t secure
    • But what you can do is follow a security researcher (myself) on Twitter or LinkedIn :)
    • If you have any recommendations to what apps/websites I investigate next please let me know 👀

If you enjoyed consider subscribing
Check out my Twitter or my other socials