I wonder how they are sure of this.
In their logs, there would be no difference between a legitimate password reset and a malicious one, given that even a legitimate flow would result in an initial request from some IP address, then when the user receives the email with the reset link they will most likely click on that from the same computer, thus the same IP address showing up on the logs. In case of a malicious attempt the same pattern would be seen - there is no way for them to know whether the user obtained the reset token from the e-mail (as they should) or directly from the password reset endpoint itself.
Bi men who live straight lives with a wife and family are ridiculously common. The ability to blackmail those people is extremely valuable to certain state organizations.
They could detect mass malicious activity if a single IP was resetting thousands of accounts. But I'm skeptical they even checked based on the horrible initial flaw and specious response.
You might also have a few emails from users...
Furthermore, for dormant accounts (where the user is no longer using the app - potentially because they are now in a relationship) the user will not notice anything either, and the notification email is likely to get lost in the endless newsletter spam the non-technical majority has in their inbox.
They don’t mention any, so this is the most positive sounding but still truthful position they can take.
Best I can think of is geolocating IPs of the reset requests and then seeing if the real owner (near original location) does a second reset later to take the account back, but that’s not convincing especially if you know where the account you’re targeting lives and went through a VPN in the same city to match.
They are supposed to be the experts (in the eyes of non-technical people) and if you don't have the skills to understand how the attack works it's reasonable (or at least used to be reasonable) to consider that the risk is minimal if "experts" do not believe it's bad.
This response lures their users into a false sense of security.
In any case, it is better/safer to cause some slight inconvenience to prevent data leak.
Of course, not all email clients allow send these events.
I'm not exaggerating when I say this bug may have gotten people locked up, or been the lever for corporate/government espionage.
I'm also concerned about antagonist nation state that gets the personal emails of top officials at Department of Defense. Goes through a targeted list in an attempt to find out who's a member. And if a match found, then engage in a blackmail scheme for secret information.
Blackmail wise, there is an even bigger difference. "I know you use grindr" vs "this is your last conversation on grindr". These have very different credibility and impact when leaked.
I'm not even sure that would constitute a "back door" - it's more of an "additional front door with no lock whatsoever".
I'm so glad I've gone social media free, all the big players in this space have shown repeatedly they don't care about the safety of their users. Grindr was already caught sharing HIV status information with 3rd parties. Eventually these horrible companies will be regulated, but tons of people are going to be harmed before that happens.
Reaching out to their CTO, who I found on LinkedIn, and firstname.lastname@grindr.com got a reply in 8 minutes.
Sad to see they still haven't upped their security game.
Bug bounties are are well and good, but a basic pen test would have picked that up. They aren’t that expensive and for a business trading in data that can get you killed in some parts of the world, should be mandatory.
Grindr doesn't store your chat history, so logging in on a new device won't show your old chat messages. Phew.
Grindr is particularly bad at security. It was fairly easy to triangulate users locations until fairly recently and some users were being harassed, and grindr ignored their reports for a long time.
It was also fairly easy to use fake locations until fairly recently which was also causing problems for non-users.
Grindr regularly shuts down accounts with no process. It's very easy to lose your contacts.
Grindr lies about what information they retain. They claim to hold very little information, which they provide when your account is shut down. However they must retain a list of your blocks and favorites in order to function. They lie and say they don't retain this info.
Because of the nature of their service, they should be on top of all this stuff, but they are really bad at it.
One thing I did notice, though: The timestamps on the Twitter DMs, which were used as evidence to assert that they're unresponsive in DMs, cover a time period of 90 minutes. The language the twitter client is set to is also not english (maybe French? the original discovery was made by someone who lives in France. I don't know), which introduces the possibility that it wasn't even daytime in the US when those were sent.
I'm all for publicly announcing these things (in a responsible way) and forcing a quicker response from the company, and its also likely that Troy tried to reach out on his own, but I just think that screenshot is a bad example of a company not responding to DMs. If it had been 48 hours to a week, then I'd be in the concerned camp.
The person who forwarded this vulnerability ... provided full details ... on September 24. ... after 5 days of waiting and not receiving a response, contacted me. He also shared a screenshot of his attempt to reach Grindr via Twitter DM
Severe, yes. It doesn't seem that strange.
You could have a flow like:
Reset page receives email address and passes it to some backend functionality. The backend checks whether the email address corresponds to an account on the site. It does, so the backend generates a reset token and emails it to the address on the affected account.
All of that is supposed to happen. What's also happening is that the reset token is being returned to the reset page, where the person requesting the reset can see it. This is very bad, but it seems likely to have come from some sort of automatic connect-your-frontend-pages-to-backend-services framework solution.
At some point, a different developer was told to consume this endpoint, send the related email, and tell the end user (browser client) that the email was sent. This second developer is not part of the "senior services team" who designed the above API, which is perfectly valid. Instead, this is a junior developer taking on their first task at the company. "Take this password reset API endpoint, and integrate it". In addition to queuing the password reset email with the token embedded within it, they also accidentally proxy the password reset service's payload to the browser. No intermediate or senior develop reviewed this new employee's PR; if they did bother to look at it, they only checked for coding standard violations (eg. indentation), without taking the effort to understand the logic of the code.
This is actually extremely common, unfortunately. The server-side layer that directly interacts with clients (ie. browsers) is generally delegated to the most junior developers, because it's menial and uninteresting work to connect the backend services to the browser. The current senior developers spent years working on that kind of garbage already, and they'd rather work on the "more interesting/advanced" backend work. Thus, the junior developers whose skills aren't yet honed are stuck–typically unsupervised–working on the front-facing components.
Also, this routinely happens at companies which rush every feature out the door with modern "agile" practices. The sprint is almost over! Quick, deliver all features by tomorrow to keep up our velocity and avoid a sprint review with negative feedback! Just merge it and push to prod without QA on a Friday at 4pm!
If only the above was a comedy routine, rather than what it truly is: the genuine reality at a large number of companies.
Sooo... what's the one thing we need this token to be. Secret.
OK, let's just return it to the one person in the whole world we don't want to have it.
Mmmm is it lunchtime...?
Issue #2141 - implement password reset: After answering secret question user should see password reset link.
Issue #2534 - send email with password reset link.
Issue #2743 - remove password reset link from web page
Issue #3892 - replace secret question with email address input
Again, yes, the bug is very bad. Software is complex, and humans are humans, and it's not difficult to imagine how these bugs occur.
This is also compounded by the drive to artificially complicate software stacks (microservices, etc) and "silo" developers into their own little bubble where they only work on a small aspect of the system and never have a need (nor the mental capacity - due to intentionally complicated stacks with dozens of microservices in various languages) to look at the big picture.
But seriously, I'm sure it was made by people that just didn't stop to think about security and "it works, so we're done here" Then, as a business you're not going to try and fix it if the software already works. That would be pure cost.
> Lol
I can understand this is most probably a private lol by a surprised. But how about we at least stop making these are you gay? Lol! a public moment worth screenshooting?
An Ashley Madison data leak is a national embarrassment whereas a Grindr one, a "national security threat" [1]. Being on AM is just a vaudevillian indiscretion, being on Grindr is bro lol that feeds hate and wrecks lives.
[1] https://www.theverge.com/interface/2019/3/28/18285274/grindr...
[0] https://www.independent.co.uk/news/world/middle-east/egypt-l...
Update: I decided to make the same point in the comments on his post and he responded in about the douchiest low-key homophobic way imaginable: http://disq.us/p/2c9pnno Tech has a long way to go on homophobia :(
* I'm even inclined to say you are kind of abusing these Big Words, but not care to start argument.
He starts out by saying:
"The photo, however, is the one most consistent with others I saw on Grindr during this exercise." and then continues to agree with the following statement: "... you didn't choose this pose by looking at typical Grindr profile photos."
So, as a thought exercise, how do you make an app like this more secure? Harm reduction is the name of the game. What are the best practices for this? Is it 2FA? Is it encryption keys linked to one device? Is it copying principles from Signal? Is it just having competent developers?
Other steps are nice to think about, but ensuring basic security measures would preempt 99% of data breaches and "hacks".
Where should the password reset token be?
Just gaming out ideas in my head. I have friends from rather more repressive countries, namely China, where being gay is still a grey area in terms of legality and acceptance, and I’m just thinking of better ways to structure a system.
I do what I can in terms of promoting certain ideas, creating informational resources, etc. But I am just one person and yadda.
As long as it is okay to jail or kill people merely for being gay, no amount of security will ever really make it safe.
In the meantime, perhaps someone should blog about "dating security best practices for the LGBTQ crowd" or something like that. (It won't be me. I'm just tossing the idea out there.)
The problem here is the profiles, which can't be E2E encrypted because the server need to run matching algorithms on them. This is where hiring competent developers comes in, along with semi-regular security audits.
Regarding this issue specifically: as far as I'm concerned, a password reset endpoint should return absolutely no information, which should be enforced by an integration test. And I don't only mean the HTTP body here - even the return time of the request (check db, send email if user exists) could be a user enumeration exploit, which for a gay dating app already sounds like a big problem. Throw the email into a queue and return immediately. Have a background worker deal with asynchronously. Add a random sleep() if you can afford it. if resp.code == 200: "If the address was correct, you will receive a reset link"
In many parts of the world, you could be risking people's lives by having a side-channel user enumeration bug, let alone this level stupidity. But I doubt your average overworked "full-stack" JS dev would even think about this, and the incentive structure simply isn't there for a for-profit company to hire people that would.
This year there have been a few months where your own profile data would not load, making you think you'd lost your profile data and having to create it all again. Yet all you needed to do was to restart the app ~10 times to get it to load.
Sometimes messages just... get lost in the ether.
The "online now" notification is flaky.
Grindr Online (web browser) is a whole new mess. I haven't used it in a long while, but the first months it felt as "professional" as an interns side project. Also you need to keep Grindr open on the phone while using it, kind of beating the purpose.
The setting to use the metric system still resets to imperial regularly.
The app is full of fakers, yet they still have no identity validation feature.
Still a pretty bad vulnerability and pretty awful that grindr was ignoring it.
Not only that, but emails are very easy to find these days with tools like apollo.io.
This also makes it very easy to lose conversations/content.
I doubt that; I bet most users use whatever Gmail/etc personal address they use for other non-work accounts.
I know of very few friends who go through the process of creating a burner email account to sign up for Grindr. Now, maybe that’s different in other countries, but at least in the States, I would bet good money you can guess their Gmail address.
Don't most systems hand roll their own password reset? Using any backend tech, I mean. This isn't crypto, where hand rolling your own solution is almost always a mistake.
"Oh you were smart enough to open the dev tools and see that, that won't happen irl"
"oh users don't have important enough info stored on this account so it won't hurt to have someone access it" (<- literally a reasoning used by a site I used in defense of poor security. "the attacker only gets access to your last name and the last 4 digits of your credit card, that's not bad enough to need more security")
Don't put it past an incompetent/lazy/underfunded tech lead to dismiss even a one-click account takeover script.
Our digital infrastructure is ludicrously insecure and open to abuse. The stable door is wide open, and has been for over a decade.
Imagine another rare issue - say I want to speak to the board of directors to give them a buyout offer... Would I manage that though in-app chat?
When you're dealing with a target that doesn't have halfway competent security response the only option is to actually have an equivocal demo that there's a hole which means you need to break into somebody else's account.
Anything else they'll most likely gaslight you and their users. "No, there was no hole, Troy just accessed his own account, nothing to see, fake news".
It's a hard thing to Google, but I follow him on Twitter and I thought that was the case. If so, this is a hilarious event for some other rapper to dunk on.
the outcome of this runaround was that grindr stated they will create a bug bounty program
proving once again that the "market based bug bounty program" has better aligned incentives and results in solving the same thing, vulnerabilities that should have been fixed to begin with were fixed.
A framework like this should not be used.
Think he'll do a legit job either way but it seems like a gamble to me. Investigative stuff is well...more murky
