Bug bounty denied? Hmmm ... OK, let's see ...
hi, i'm daniel. i'm a 15-year-old with some programming experience and i do a little bug hunting in my free time. here's the insane story of how I found a single bug that affected over half of all Fortune 500 companies:
https://gist.github.com/hackermondev/68ec8ed145fcee49d2f5e2b9d2cf2e52Open linkView original on lemmy.world
21 replies
Regardless of everything else they should be kicked out from HackerOne since it's clearly Zendesk not being truthful here.
"Sorry, but per your own guidelines this is out of scope. Because of this, this bug is not part of the agreement and guidelines on Hackerone. You can find my full disclosure, that I wrote after your dismissal here: " /s
I mean, that still allows zendesk to reply with "oh yeah that's also why we're not paying the bounty"
Well, they did it anyways, so...
Also this might work as an answer to "yeah, it's a bug, but we won't pay you"
Sounds like they just didn't want to pay this guy. That is so dumb as if they lose even a few customers they are going to be in negative. They should of paid him and then turned this into a PR positive.
The best part of this is how Zendesk's blog post claims that Zendesk discovered the issue, and then blamed the 15 year old for not following ethical principles.
I specially liked the part where he collected $50k by clueing the affected companies.
At the end of the day tens of thousands for companies is a small price to pay for something that could cost millions. As bonus this person now has a foothold in big companies. Sounds like a great way to get a well paying job.
That was a great read, thank you for posting it here.
Zendesk commented on the GitHub post with this:
I didn't understand how the OP did this:
Is that just a spoofed email? What would be the steps to do that?
They aren't trying to actually send from that email, they are trying to create an Apple ID that lets them log in using that email effectively as a username. And Slack will add people to the internal Slack if the email is a company email address.
To open that account, they need to prove to Apple they own the account. They sign up with Apple and say their email address is [email protected], then Apple sends them a code to verify it's their email.
They can't actually receive the verification email, because it's not their email. That's where the exploit comes in. It's very important that this email address is the one that forwards emails to Zendesk. The verification email from Apple goes to Zendesk, then they use the exploit to see the history of the zendesk ticket, which includes the verification code.
Thanks, that's a useful description.
Pretty ingenious.
Surprise a massive company everyone thinks is the best is not "wasting" money on security or best practices.
The best option is to leave Zendesk. We need a trend where companies lose customers when they have such bad practices
Is it you, lemmy, brigading that GitHub gist? @ZendeskTeam is being is already dead, but don't worry, you can still come and give them another kick.
Someone on the Github mentioned that @Zendeskteam may not even be official.
I doubt most of those comments are from Lemmy. Probably Reddit and other places.
Trying to do the devil's advocate: Zendesk isn't a mail server and all it's doing is to organize a million messages sent to a specific address in a neater way. A spam filter is also present because every email client needs it, but spoofed mails should be rejected by the mail server, not the clients.
Sorry you've been downvoted for trying to start a discussion.
Is this not the swiss cheese thing? No control is perfect, so you layer them. If there is no reason why Zendesk should let this happen, then it shouldn't happen.
They absolutely can and should fix it, but in the end, IMHO, it's a mail server misconfiguration coupled with a slack issue, not a Zendesk security issue
I can see both angles of this. Especially since the original disclosure didn't have the full detail of how it could be exploited to access company systems, and they (the writeup author) never disclosed that update.
You can see how a large company (Zendesk) could miss this in the multitude of people trying to claim bug bounties. I fully believe that had they understood the issue they should have fixed it, since it's within their power and basically a service to their clients. But I can understand how the limited detail in the original disclosure demonstrated a much lower level risk than the end exploit that was never reported.
Nah, zendesk should absolutely have recognised that gaining unauthorised read access to support ticket email chains is a massive security issue. Firstly "support email chains" accounts for proportionately nearly all the data zendesk is handling, so a vulnerability there is core to the product, not at all peripheral, and secondly, who on earth is working in tech today that doesn't know that your email is they key to all your online accounts?
Zendesk here were blatantly either stupid or in denial and treated a bug reporter as a low life enemy instead of an asset. The kid did right by any plausible moral viewpoint.