LINK.social Exposed Users' Sensitive Information & Mass Account Hijacking thumbnail

LINK.social Exposed Users' Sensitive Information & Mass Account Hijacking

July 14, 2022 David Teather

Table of Contents

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.

This is a crosspost blog from my other blog

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

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

Phone Number & Name
Account Hijacking

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.

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

Visualization of YikYak Location in Madison, WI

Visualization of LINK social locations across the US (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

Back to blog