Comment by bsuvc
4 months ago
It sounds like the author got stiffed by Zendesk on this bug, $0 due to email spoofing being out of scope.
The $50k was from other bug bounties he was awarded on hackerone.
It's too bad Zendesk basically said "thanks" but then refused to pay anything. That's a good way to get people not to bother with your big bounty program. It is often better to build goodwill than to be a stickler for rules and technicalities.
Side note: I'm not too surprised, as I had one of the worst experiences ever interviewing with Zendesk a few years back. I have never come away from an interview hating a company, except for Zendesk.
> That's a good way to get people not to bother with your big bounty program.
And possibly to have blackhats to start looking more closely, since they now know both 1) that whitehats are likely to be focusing elsewhere leaving more available un-reviewed attack surface, and 2) that Zendesk appears to be the sort of company who'll ignore and/or hide known vulnerabilities, giving exploits a much longer effective working time.
If "the bad guys" discovered this (or if it had been discovered by a less ethically developed 15 year old who'd boasted about it in some Discord or hacker channel) I wonder just how many companies would have had interlopers in their Slack channels harvesting social engineering intelligence or even passwords/secrets/API keys freely shared in Slack channels? And I wonder how many other widely (or even narrowly) used 3rd party SaaS platforms can be exploited via Zendesk in exactly the same way. Pretty much any service that uses the email domain to "prove" someone works for a particular company and then grants them some level of access based on that would be vulnerable to having ZenDesk leak email confirmations to anybody who knows this bug.
Hell, I suspect it'd work to harvest password reset tokens too. That could give you account takeover for anything not using 2FA (which is, to a first approximation over the whole internet, everything).
If I am not mistaken, it wasn't zendesk that didn't want to recognize the bug, but HackerOne that did not escalate to Zendesk that they should reconsider the exclusion ground in this case.
As an aside, I wonder if those bounties in general reflect the real value of those bugs. The economic damage could be way higher, given that people share logins in support tickets. I would have expected that the price on the black market for these kind of bugs are several figures larger.
The author specifically stated: "Realizing this, I asked for the report to be forwarded to an actual Zendesk staff member for review", before getting another reply for H1. I read this as they escalated it to Zendesk directly, who directed it back to HackerOne.
It wasn't clear to me as even at that point it was an "H1 Mediator" who responded.
Also the bit about SPF, DKIM and DMARC seems to show a misunderstanding of the issue: these are typically excluded because large companies aren't able to do full enforcement on their email domains due to legacy. It's a common bug report.
In this case, the problem was that Zendesk wasn't validating emails from external systems.
4 replies →
> If I am not mistaken, it wasn't zendesk that didn't want to recognize the bug, but HackerOne that did not escalate to Zendesk that they should reconsider the exclusion ground in this case.
Correct, the replies seem to have come from H1 triage and H1 mediation staff.
They often miss the mark like this. I opened a H1 account to report that I'd found privileged access tokens for a company's GitHub org. H1 triage refused to notify the company because they didn't think it was a security issue and ignored my messages.
> If I am not mistaken, it wasn't zendesk that didn't want to recognize the bug
While it's unclear at which stage Zendesk became involved, in the "aftermath" section it's clear they knew of the H1 report, since they responded there. And later on the post says:
"Despite fixing the issue, Zendesk ultimately chose not to award a bounty for my report. Their reasoning? I had broken HackerOne's disclosure guidelines by sharing the vulnerability with affected companies."
The best care scenario as I see it is that Zendesk has a problem they need to fix with their H1 triage process and/or their in and out of scope rules there. And _none_ of that is the researcher's problem.
The worst (and in my opinion most likely) scenario, is that Zendesk did get notified when the researcher asked H1 to escalate their badly triaged denial to Zendesk for review, and Zendesk chose to deny any bounty and tried to hide their vulnerability.
> As an aside, I wonder if those bounties in general reflect the real value of those bugs. The economic damage could be way higher, given that people share logins in support tickets.
I think it's way worse than that, since internal teams often share logins/secrets/API keys (and details of architecture and networking that a smart blackhat would _love_ to have access to) in thei supposedly "internal" Slack channels. I think the fact that non Zendesk "affected companies" paid out $50k sets that as the absolute lower bound of "the real value of those bugs. And it's _obvious_ that the researcher didn't contact _every_ vulnerable Slack-using organisation. I wonder how much more he could have made by disclosing this to 10 or 100 times as many Slack using organisations, and delaying/stalling revealing his exploit POC to Zendesk while that money kept rolling in?
I'll be interested to see if HackerOne react to this, to avoid the next researcher going for this "second level" of bug bounty payouts by not bothering with H1 or the vulnerable company, and instead disclosing to companies affected by the vulnerability instead of the companies with the vulnerability? It's kinda well known that H1 buy bounties are relatively small, compared to the effort required to craft a tricky POC. But people disclose there anyway, presumably party out of ethical concerns and partly for the reputation boost. But now we know you can probably get an order of magnitude more money by approaching 3rd party affected companies instead of cheapskate or outright abusive companies with H1 bounties that they choose to downvalue and not pay out on.
Hackerone staffs are not that good. They usually mark anything from a non famous person as a duplicate (even if it differs in nuances, which eventually lead to much more impact) or straight out of scope.
I think it's just laziness. Plus they hire previous famous reporter as the people triaging the reports, those famous people know other famous people first hand, they usually think "hmm, unknown guy, must have ran a script and submitted this"
I have stopped reporting stuff since last 5 years due to the frustration. And it seems the situation is still the same even after so many years.
> due to email spoofing being out of scope.
I believe their logic was that only the domain owner can adequately prevent email spoofing by proper SPF/DMARC configuration, and that it’s the customers’ fault if they don’t do that. Which isn’t entirely wrong.
In a past life I was involved in a bug bounty program. I don't think the reasoning is as detailed.
When you stand up a bug bounty program you get a ton of "I opened developer tools, edited the js on your page, and now the page does something bad" submissions. "I can spoof some email headers and send an email to myself that looks like it is coming from you" isn't something I've specifically seen due to some weird details about my bounty program but it is something I would absolutely expect for many programs to see.
So you need a mechanism to reject this stuff. But if that mechanism is just "triage says this is dumb" you get problems. People scream at you for having their nonsense bug rejected. People submit dozens of very slightly altered "bugs" to try to say "you rejected the last one for reason X but this one does Y." So you create a general policy: anything involving email spoofing is out of scope.
So then a real bug ends up in front of the triage person. They are tired and busy and look at the report and see "oh this relies on email spoofing, close as out of scope." Sucks.
I think that Zendesk's follow up here is crap. They shouldn't be criticizing the author for writing about this bug. But I do very much understand how things end up with a $0 payout for the initial report.
Right, but I would be really shocked if Zendesk's internal email handler was doing any SPF/DKIM/DMARC validation at all. So even if a domain has DMARC set up, Zendesk is probably ignoring it. Which is probably pretty reasonable given how rare DMARC reject/quarantine has been historically
Are Google and Apple not doing proper SPF/DMARC/DKIM? I think they probably are - but this attack worked anyway.
Zendesk wasn't validating the email senders.
Apple and Google weren’t involved as email sender addresses.
11 replies →
> $0 due to email spoofing being out of scope.
Strictly, $0 because he disclosed to customers. But he only disclosed to customers since Zendesk said it was out of scope.
HackerOne declared the issue out of scope so I don't see why disclosure would make a difference here. Had this person not notified different companies, they still wouldn't get a dime from HackerOne.
Bad showings all around, for both HackerOne and Zendesk.
>HackerOne declared the issue out of scope so I don't see why disclosure would make a difference here.
Indeed, but just you wait for Zendesk to say "well, _we_ didn't mark it out of scope!" as if delegating it to h1 renegades all responsibility.
1 reply →
(There's a not-very-convincing argument that they declared the ability to view support tickets as out of scope, but were not given a chance to assess the Slack takeover exploit's scope.)
3 replies →
I too had the worst interview experience with zendesk. The people I talked to were pretty senior folks too. They just seem to have a very petty and toxic work culture.
That is why a black market exists for this stuff.
The black market also exists because the potential payout for serious 0days by official programs is almost always less than what a third-party adversary will pay (if the target(s) for them are worth it).
The price for 0days is highly variable according to this presentation (starting slide 65):
https://github.com/mdowd79/presentations/blob/main/bluehat20...
The same presentation also mentions (starting slide 17) how the requirements of 0days differs from public research, which is why some vulnerabilities would be difficult to sell.
This. Fortunately the law makes it that it’s inconvenient (possible prison time) to use the black market, which is a big thumb on the balance, but bug bounties are also often only $3000…
11 replies →
Seems a pattern: https://www.reddit.com/r/sales/comments/1eck30a/terrible_zen...
> Side note: I'm not too surprised, as I had one of the worst experiences ever interviewing with Zendesk a few years back. I have never come away from an interview hating a company, except for Zendesk.
Same thing happened to me years ago. Interviewed with them and it was the worst “screening” experience I ever had. After getting a rejection email, I thanked them for their time and said I had feedback about the interview should they want to hear it. They said yes, please.
Sent my feedback, never heard from them again.
Same it was time-wasting interview experience. They seem interested and not interested at the same time. They pinged me for a different role after passing me up for the first role, but didn't get any response later..
This is a common problem with HackerOne and the likes. It's absolutely awful for anything even a tiny bit more unique or rare.
Blame beg bounty hunters for this
Beg bounty hunters are not to blame for utterly abysmal responses by these platforms. Especially after they ghost the researcher and then moan about publication.
Proper response would be to update your program to triage these vulns and thank the researcher for not going public straight away. This current approach is burning a tremendous amount of goodwill.
1 reply →
Mind giving details abut the interview? Must've been pretty bad!