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

• Table of Contents
• What is LINK
• What Data is Exposed
  • Why This Is A Problem
    • Location Data
    • Phone Number & Name
    • Account Hijacking
• Vulnerabilities
  • Exposing Sensitive User Information
    • Mitigation
  • Account Hijacking
    • Mitigation
• Location Visualization
• LINK’s Response
• Takeaways

What is LINK

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’s Response

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 👀

I disclosed what I found to the YikYak team on April 11th 2022. Almost a month later on May 8th 2022 (1 day before public disclosure date), they responded by removing the user id being returned for posts and comments however this is not enough to protect privacy as it’s trivial to regain this information.

Edit (May 18th): YikYak has made what I consider substantial changes, more under the have things changed section.

Edit (May 11th): YikYak has made more changes detailed in the have things changed section.

Table of Contents

• What Is YikYak
• What Data Is Exposed
  • Why It’s a Problem
  • Mitigations Recommended
  • YikYak’s Response
• How I Discovered It
• Data Visualization
  • What The Data Tell Us
• What Can YikYak Users Do To Protect Themselves?
• Takeaways

What is YikYak

YikYak is a pseudonymous messaging board, where users can see posts within a radius of 5 miles. Each user has an emoji and color to distinguish individuals, these can be reset if the user chooses. This feature allows conversation chains to continue in comment sections where users can interact.

Each post has a location associated with it by design, and when viewing a post the app displays how far away they are from you. The main target audience for YikYak is college students on college campuses.

What Data Is Exposed

• On All Posts & Comments
  • Precise GPS Coordinates (accurate to within 10-15 ft)
  • A user id (persistent across posts even if a user resets their avatar)
    • After YikYak’s update on May 8th it takes maybe a few minutes of guessing to get this data back by manipulating the graphql query

Why It’s a Problem

Location data itself isn’t problematic for an app like this, it is problematic when the precise GPS coordinates are sent to the client and user ids are exposed. Combining these two pieces of information it is possible to de-anonymize users, since people are more likely to use their phones thus YikYak at home it’s possible to figure out the area where a user lives within 10-15 feet. This ability to de-anonymize is much more of a risk in low density rural areas where detached single-resident buildings are more than 10-15 feet apart, as a single GPS location narrows down a user to one address.

Since user ids are persistent it’s possible to figure out a user’s daily routine of when and where they post YikYaks from, this can be used to find out the daily routine of a particular YikYak user.

A non-exhaustive list of what a malicious actor could do with GPS data

• Break into a building when they know a YikYak user is somewhere else (on vacation or just not home)
• Stalk YikYak users by tracking the GPS location of their posts
• Unlawfully surveil and monitor users

Mitigations Recommended

In my email to the YikYak team I recommended some fixes they could implement in order to increase anonymity. I’ve ordered them from in my opinion what’s the most effective to the least effective.

1. Truncate the GPS coordinate to only use a few decimal places such as 2 or 3, as this makes the location inaccurate to 0.6 miles or 300 feet respectively according to Wiki GIS.
2. Change the API to calculate the distance from the client server-side, so that GPS coordinates are never sent to the client.
3. Don’t display how far the poster is from the client, or just randomly generate how far away people are from each other.
4. Don’t return user ids to the client when querying for posts/comments.

The most logical and efficient way to protect user privacy is to implement option number one, as this destroys the information ensuring nobody is ever able to recover the exact location again. The other options leave de-anonymization of users possible through other means. Despite this, on May 8th 2022 YikYak decided to go with option four after nearly a month to prepare for public disclosure.

YikYak’s Response

YikYak sent this a few days after my initial disclosure email to them.

We’re working on fixes to stop exposing user IDs to clients and soften how location is exposed

They then asked me to push back my initial disclosure date another 2 weeks to May 9th 2022, which I agreed to.

Have Things Changed

As of writing on May 9th things have not significantly changed. YikYak responded by removing the user id field being returned for posts and comments however this is not enough to protect user privacy. It’s still fairly trivial to access this information and would take only a few minutes to guess and check.

YikYak released a “Summer Spaceship” feature which allows users to save a GPS location and act as if they’re at that location when posting and viewing content on the app. This feature could allow for users who care about their privacy to set their location to be in a busy place to protect their anonymity. However, it does not appear that this feature is meant to protect user privacy and the branding around this feature does not reflect that this was the intention of the feature.

Edit May 18th: YikYak has rounded all GPS coordinates sent to the client, as well as the distances to various users. This is what I suggested to them, I’m assuming that the coordinates are only rendered server-side which is an improvement. Since the information isn’t destroyed, it is possible that some attack in the future could leave the exact coordinates exposed. Despite this, I’m glad that they finally changed things and the app is more secure for the privacy of individual users.

Edit (May 11th): YikYak has released version 1.4.3 which does calculate the distance to each post in feet, however since this is not rounded it’s still possible for trilateration the location of the post. Furthermore, it is still possible to get the user ID and exact location based on the API requests of older versions. This could be temporary to provide backwards compatibility with older versions of the app. If YikYak did take this more seriously they would restrict these fields from being returned and break older versions and force users to upgrade to a newer version of the app.

How I Discovered This

I intercepted the HTTP requests from the app by using mitmproxy, next I wrote some code that pretended to be the YikYak app to extract information from it. I then realized that YikYak was exposing the precise GPS coordinates of every poster and commenter to the client, which is when I started drafting up an email to YikYak and collecting some GPS coordinates to visualize some data.

Aside: If you want to learn how to intercept information like what this article is about, I’m working on a free YouTube series on David Teather Codes that will teach you how! So please subscribe, if that’s not your thing I’ve got a lot more content planned.

Data Visualization

I collected some of the exposed user data for a short amount of time after the disclosure to YikYak. I figured it would be a waste not to share a cool looking visualization.

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

• Randomized GPS Coordinates
• Restricted the radius of visualized points to only include high density blocks, so that individual points cannot be pinned to a particular address

What The Data Tell Us

• College students use YikYak the most
• Student dorms and libraries are the “hottest” areas
• Not much else to be honest

What Can YikYak Users Do To Protect Themselves?

Don’t use YikYak in a place where you wouldn’t broadcast your GPS coordinates to strangers.

If this isn’t a sacrifice you’re willing to make, YikYak introduced a “summer spaceship” feature which allows you to save your GPS location and act as if you were at that location. You could set this location to be in a public place like a campus union, so that it’s harder to de-anonymize you. I haven’t done my own analysis to see if this hides your actual GPS location, but if implemented properly it would let you mask your actual location, thus protecting your privacy.

Takeaways

• “Anonymous” messaging apps don’t exist
• Apps we use without thinking may be putting us at risk to malicious actors, when we have little knowledge or control over how securely our information is stored
• If you’re designing an app that sends sensitive information to a client, it’s best to not send it at all and when possible anonymize it

Hope you enjoyed :)