Elijah's Blog

A Story of Cannabis and Security
A Story of Cannabis and Security

Earlier this year (April 20th to be exact) an article appeared on Google news from Mic.com that piqued my interest. The news website reached out to cybersecurity firm Synack, asking them to take a look at a mobile application called HighThere. HighThere’s mission from their website is:

As the only global network for cannabis enthusiasts, we’re driven to create a virtual smoking room for the world. Our goal, is to foster a social platform capable of connecting the cannabis culture, sustaining its community, and serving as the definitive outlet for mainstream plugs. In other words, we’ve gone green. And there’s a worldwide community filled with people just like us. You’ve got more friends than you think. And it starts, when you say HighThere!

In essence, they are “Tinder for tokers”; a place where you can find your next smoking buddy. Personally not my cup of tea, however, what Synack found was very interesting. They didn’t provide any substantial details behind their findings, which then raised the question, “did they actually find what they claimed?” This article answers that question and provides the details.

As a side note, Mic.com contacted HighThere in April about what was found and the app maker essentially said, “Yeah, we know our security sucks and we leak user information but we’re working on it.” Three months later and nothing has changed; my hope is that this post will give HighThere the kick in the pants they need to keep their users’ data secure.

This is a somewhat technical article but I tried to write it so that anyone could understand what was going on.

Synack found HighThere sending users’ precise location data directly to the app. This location data was then used to calculate the distance between two users. Since they were doing this, I figured HighThere was using other poor security practices — spoiler alert: they were.

My first task was to create a new account using a fake email address. Unfortunately there was an error saying I was using a “wrong email”. Far from discouraged I fired up Charles Proxy and looked at the traffic being sent when I was trying to create an account. My guess was that when creating an account, the app was doing some sort of verification to make sure I wasn’t using a temporary email service. This turned out to be true, however the verification was done from the app itself. Every time I tried to create an account it was sending a request to kickbox.io checking the validity of the email address. As expected, kickbox sent back a response saying the email was “risky” and “low quality”.


After taking a look at the kickbox.io documentation, it was easy to see what a valid response would look like. I then modified the response from kickbox to be valid and the account was created!

after editing the response

I finished updating my fake profile while watching what web traffic was being generated. That’s when another large issue appeared, all data sent to and from the HighThere server was unencrypted. Not a single request used https.

Looking more at the traffic revealed an interesting endpoint that was simply “aws”. The thought had crossed my mind that HighThere was using AWS to host their website, so it was intriguing why they had an API endpoint named after the web service provider. Even more interesting was that a request was being sent there just before updating the profile image. It’s truly unbelievable to be able to access an unencrypted, no-authentication-required, API endpoint that essentially provides a username (access key) and password (secret key) to AWS.

the “aws” endpoint

The only good thing is that the access key and secret key are on a separate AWS account with limited permissions; only able to upload files. This is pretty huge though, it would mean that anyone could upload anything to their AWS S3 bucket and cause their costs to skyrocket.

Seeing enough, I decided to dive into the nitty-gritty details of their Android application by decompiling it. After using Jadx, it was clear HighThere hadn’t used any obfuscation software like ProGaurd. A couple minutes of searching revealed a class called ApiClient that contained methods to access the various API endpoints using Retrofit.

the ApiClient class

To be fair, their API is very nice and easy to use. The problem starts when we take a look at what data is returned when meeting other users.

the “meet” endpoint JSON response

The “meet” endpoint returns information about a user and most is expected since it needs to be displayed in the app; the scary part is that it also returns a user’s latitude and longitude. I searched some of the locations with Google Maps and it was accurate down to the house in most cases. In addition to latitude and longitude, the API was also returning information you were told other users wouldn’t be able to see. These include: last name, email, birth day and password.

On the bright side, they aren’t returning each user’s password and email address. Unfortunately HighThere has another feature called “Joints” where users can post pictures and such. After looking at this endpoint, it was clear HighThere was not taking any care to keep their users’ information secure.

a typical JSON response for the top Joints for the day

The Joints endpoint returns an abundance of sensitive information including: email address, latitude, longitude, city, state, country & Facebook information…absolutely unreal.

It’s astounding that the people who created this app, for something that is still illegal in most parts of the world, thought it would be OK to return so much information about their users unencrypted. I would not recommend this app to anyone until HighThere increases their security and stops sending sensitive data directly to the client.

If we take a step back now, and think for a moment…how could this have been prevented?

To start, validation on the client side is acceptable as long as you also do validation server side before saving to the database. As you saw, we could send whatever email we wanted to the server and there was no validation done.

Secondly, don’t EVER send the location information of other users to the client. This was brought up in the Mic.com article but it needs to be reiterated. The distance should be calculated server side and then sent to the client. This is how popular dating app Tinder operates.

Similarly, don’t send so much information about other users to the client; some is inevitable such as avatar URLs and names, but location data and emails are unacceptable. HighThere appears to be running Ruby on Rails, so if you are too, Rails has this nice feature where you can exclude fields when rendering JSON/XML for your API.

HighThere isn’t just a small mobile application built at a college hackathon. It is a venture backed company that has raised $700,000 and is valued at $5M according to Crunchbase.

In 2016, a mobile application this insecure is simply unacceptable. We are in an era where people value their privacy and security more than ever. When you sign up and give your personal information to an app like HighThere, you expect for it to be secure.

In the time since the Mic.com article I have been running a script to gather aggregate information about the people using HighThere and it seemed like an interesting way to end this post.

Out of 160,897 users queried:

The lowest id found was “1”, and the highest was “218,280”.


Ingestion Method

Is Verified


Interests (note: multiple interests can be selected by a single user)

The moral of the story is that making a mobile application is easy, but making a secure mobile application can be time consuming. More now than ever, information and tutorials are only a quick search away. While the secure application may take longer to create, it will be worth it for both you and your users in the long run.