- cross-posted to:
- [email protected]
- [email protected]
- cross-posted to:
- [email protected]
- [email protected]
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:
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.
What “should be done” is irrelevant - what matters is what “is done”. And plenty servers don’t enforce SPF, DKIM and DMARC. (In fact not even Google and Yahoo did it, before February of this year.)
And, when you know that your product has a flaw caused by a third party not doing the right thing, and you can reasonably solve it through your craft, not solving it is being irresponsible. Doubly true if it the flaw is related to security, as in this case.
Let us learn with Nanni: when Ea-nāṣir sold him shitty copper, instead of producing shitty armour, weapons and tools that might endanger Nanni’s customers, Nanni complained with Ea-nāṣir. Nanni is responsible, Zendesk isn’t. [Sorry, I couldn’t resist.]
[EDIT: can you muppets stop downvoting the comment above? Dave is right, Moonrise is trying to start a discussion, there’s nothing wrong with it.]
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.