Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

1 bug, $50k in bounties, a Zendesk backdoor

gist.github.com

Post reply on HN
Print view View original

181–190 of 437 posts

Re: 1 bug, $50k in bounties, a Zendesk backdoor

#181

Post by ozim »

mmsc wrote: post #167
wil421 wrote: post #161

Earlier quoted context omitted.

“2) seen as a cheaper alternative to someone who knows anything about security - "why hire someone that actually knows anything about security when we can just pay a pittance to strangers and believe every word they say?"” It doesn’t make sense, companies with less revenue aren’t the ones doing this. It’s usually the richer tech companies.

>It doesn’t make sense, companies with less revenue aren’t the ones doing this. It’s usually the richer tech companies. Because for some reason, it's larger tech companies that love to bean-count their way through security.

It is also larger tech companies that have basically infinite attack surface.

So my argument is that it does not matter how much they spend on security they will get hacked anyway, only thing they can do is keep spending in check and limit scope of hacks.

Re: 1 bug, $50k in bounties, a Zendesk backdoor

#182

Post by ozim »

MangoCoffee wrote: post #79
zer0x4d wrote: post #60

Earlier quoted context omitted.

This is worse than Docusign. What do 6000 people at Zendesk do? It's a simple ticket management software with maybe 10 features

I previously worked for a mortgage software startup that attracted interest from big banks. To ease concerns about our scalability and longevity, we move from a tiny office to an office with a lot of empty space. This strategic move supposes signaled to prospective corporate clients that we were committed to sustaining our solution over the long term, rather than just a few years but in the end the company went out o…

Yet the same corporate will eat anything that Google or MSFT does while we all know they kill projects just like anyone else or like any smaller company going out.

Re: 1 bug, $50k in bounties, a Zendesk backdoor

#183

Post by Aachen »

layer8 wrote: post #90
aftbit wrote: post #53

Wait... it looks like Zendesk only fixed the issue of Apple account verification emails being added to tickets, not actually the underlying issue? >In addition to this, we also implemented filters to automatically suspend the following classes of emails: User verification emails sent by Apple based on the Reply-To and Message-Id header values Non-transactional emails from from googleworkspace-noreply@google.com Over…

Only the customer domain owners can fix the underlying issue, which is a missing SPF/DMARC configuration.

They could make the ticket IDs unpredictable so you can't subscribe yourself to any existing ticket by sending it an email

Re: 1 bug, $50k in bounties, a Zendesk backdoor

#185

Post by nightpool »

radlad wrote: post #126
chabons wrote: post #111

Earlier quoted context omitted.

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.

In this case, that probably means that H1 had a Zoom or Slack convo with the team and is relaying their decision into text instead of making them write it down themselves.

Re: 1 bug, $50k in bounties, a Zendesk backdoor

#187

Post by Aachen »

gavingmiller wrote: post #28

The piece the author is missing, and why zendesk likely ignored this is impact, and it's something I continually see submissions lacking. As a researcher, if you can't demonstrate impact of your vulnerability, then it looks like just another bug. A public program like zendesk is going to be swamped with reports, and they're using hackerone triagers to augment that volume. The triage system reads through a lot of repo…

Exploit or no, the bug and potential impact are the same. I personally find it a waste of time to sink evenings into an exploit when they're going to fix the bug anyway if I simply tell them about the problem. They also know the system better than I do and can probably find a bigger impact anyway

Of course, this is only a good strategy if you're just wanting to do a good deed and not counting on getting more than a thank you note, but Zendesk or Hackerone (whoever you want to blame here) didn't even accept the bug in the first place. That's the problem here, not the omission of an exploit chain

Re: 1 bug, $50k in bounties, a Zendesk backdoor

#188

Post by mmsc »

dgoldstein0 wrote: post #153
ec109685 wrote: post #121

Earlier quoted context omitted.

I don’t agree. Bug bounties are taken seriously by at least some companies. Where I have worked, we received very useful reports, some very severe, via HackerOne. The company even ran special sessions where engineers and hackers were brought together to try to maximize the number of bugs found in a few week period. It resulted in more secure software at the end and a community of excited researchers trying to make so…

This feels like a case in the gray area. On the one hand, companies need to declare certain stuff out of scope - whether they know about it and are planning to work on it, or consider it acceptable risk, as the point for the company is to help them improve their security posture within the scope of the resources they have to run the bug bounty program. What's weird here is that the blog author found an email problem…

>Without a broader PoC to show how it could be weaponized, it's hard to say that Zendesk was egregiously wrong here

The implications of being able to read arbitrary email contents from arbitrary domains' support (or otherwise) addresses are well known, and any competent security personnel in ZenDesk's security team should know this is exactly what can happen.

Something similar has been discussed on HN before: https://news.ycombinator.com/item?id=38720544 but the overall attack vector of "get registration email send to somewhere an attacker can view it" is not novel at all; it's also how some police database websites have been popped in the past (register as @fbi.gov which automatically gives you access; somehow access the inbox of @fbi.gov due to some public forwarding, for example)

Re: 1 bug, $50k in bounties, a Zendesk backdoor

#189

Post by Aachen »

gavingmiller wrote: post #158
23B1 wrote: post #43

Earlier quoted context omitted.

"If you won't illustrate the impact of our mistake, we aren't obligated to listen to you" is peak CYA

Not even close to the point I was making: If you want to get taken seriously, write to audience.

The audience of a security contact point (be that Hackerone or security@') is a technical person

We add impact demonstrations to a few findings per pentest report because our audience is broader: the nontechnical people who decide to allocate the money need to understand why this is useful and that the devs/sysadmins need to get enough time to do things right (developers and sysadmins are often sufficiently skilled, but are under delivery pressure). A sufficiently technical team, when the bug is adequately explained, doesn't need a functional exploit to see it's real/impactful or not

Re: 1 bug, $50k in bounties, a Zendesk backdoor

#190

Post by nightpool »

layer8 wrote: post #82
bsuvc wrote: post #3

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. Sid…

> 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.

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
Post reply on HN