Unfortunately the headline makes it look like Zendesk paid a bounty, when they did not. Clearly they have a doofus in charge of security.
1 bug, $50k in bounties, a Zendesk backdoor
151–160 of 437 posts
Re: 1 bug, $50k in bounties, a Zendesk backdoor
#152Earlier quoted context omitted.
> 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.
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.
Re: 1 bug, $50k in bounties, a Zendesk backdoor
#153Earlier quoted context omitted.
It all makes sense if you consider bug bounties are largely: 1) created for the purpose of either PR/marketing, or a checklist ("auditing"), 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?" The amusing and ironic thing about the second point is tha…
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 that wasn't really in that DKIM/SPF etc area, and Zendesk claimed that exemption covered it. Without a broader PoC to show how it could be weaponized, it's hard to say that Zendesk was egregiously wrong here - the person triaging just lacked the imagination to figure out that it would be a real problem. Hell, later in the write up we learn Zendesk does do spam filtering on the inbound emails, and so it's not crazy to think a security engineer reading the report may assume that stuff would cover their butts, when it failed miserably here. (A good Engineer would check that assumption though)
That said putting my security hat on, I have to ask - who thought that sequential ticket ids in the reply-to email address were a good idea? they really ought to be using long random nonces; at which point the "guess the right id to become part of the support thread" falls apart. Classic enumeration+IDOR. So it sounds like there's still a potential for abuse here, if you can sneak stuff by their filters.
Re: 1 bug, $50k in bounties, a Zendesk backdoor
#154Earlier quoted context omitted.
Only the customer domain owners can fix the underlying issue, which is a missing SPF/DMARC configuration.
That doesn't sound right. Aren't these @zendesk.com addresses?
The spoofed addresses were support@company.com, is my understanding.
Zendesk is very well aware of SPF/DMARC, from their support pages.
Re: 1 bug, $50k in bounties, a Zendesk backdoor
#155Earlier quoted context omitted.
Requiring their customers to implement SPF and DMARC as a hard technical requirement is probably bad for business. And as mentioned in TFA, they do note issues regarding SPF/DMARC in their policy.
I think in this case it's the customers of their customers, e.g. people sending emails to support@acme-corp.com. In that light requiring all emails coming into support@acme-corp.com to have SPF and DMARC is bad for business indeed, not only for Zendesk but probably also for the fictional ACME corp. EDIT: they absolutley should not use an autoincrementing int as a "support-chain token" though, that's a workaround they…
> EDIT: they absolutley should not use an autoincrementing int as a "support-chain token" though, that's a workaround they could easily do.
I checked my email archives and some (but not all) of the emails I've received from Zendesk have arbitrary alphanumeric ids in the Reply-To header instead of integers. Seems to depend on the company, perhaps this is a configuration issue?
Re: 1 bug, $50k in bounties, a Zendesk backdoor
#156Earlier quoted context omitted.
That title is also completely misleading because the author did not in fact get paid. 50k corresponds to the money they made with unrelated bug bounties. I wish they would fix the title so that it properly calls out zendesk refused to pay for a serious bug.
"Unrelated" doesn't sound right. Zendesk refused to pay for the vulnerability, so the researcher used it against downstream customers of Zendesk, who did pay the researcher for the impact of that Zendesk vulnerability against their own company.
Indeed - I misspoke.
Re: 1 bug, $50k in bounties, a Zendesk backdoor
#157Earlier 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
If it's anything like ServiceNow, they have insane feature bloat and poor overall software architecture.
What's interesting is that Frank Slootman touts this transformation as a huge success in his book and talks at length about his conflict with Fred Luddy (who originally authored the simple ticketing incarnation of the ServiceNow monsterblob). The focus on keeping things simple is highlighted as an example of nerds' nearsighted thinking.
Re: 1 bug, $50k in bounties, a Zendesk backdoor
#158The 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…
"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.
Re: 1 bug, $50k in bounties, a Zendesk backdoor
#159Reported this exact bug to Zendesk, Apple, and Slack in June 2024, both through HackerOne and by escalating directly to engs or PMs at each company. I doubt we were the first. That is presumably the reason they failed to pay out. The real issue is that non-directory SSO options like Sign in with Apple (SIWA) have been incorrectly implemented almost everywhere, including by Slack and other large companies we alerted i…
Out of curiosity, do you know of open source projects or any resources that someone less familiar with SSO can use/read to properly implement SSO?
Something like Keycloak?
Re: 1 bug, $50k in bounties, a Zendesk backdoor
#160Earlier quoted context omitted.
> you waste time with the constant spam of people begging for bounties A great blog post on the matter https://www.troyhunt.com/beg-bounties/
It's a great read, but it looks like a number of the screenshots are missing.
That's strange, I don't see any missing images. Perhaps the Twitter embeds are breaking intermittently?
Edit: nevermind, I see what you mean. Twitter embeds work, direct images don't.