141–150 of 437 posts
Another example of how weasley Zendesk can be: They created a fake band called "Zendesk Alternative" just in an attempt to pollute the Google results if you search for an alternative to Zendesk. http://zendeskalternative.com/ While not illegal, it shows the way they think, a sort of manipulative pettiness.
Earlier 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.
Earlier quoted context omitted.
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…
I’m not clear on that. If the support requestor doesn’t need to be from the company, then I don’t understand why the email sender has to be spoofed in the first place.
Reported 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…
The edited title on HN is incomprehensible. The original is: ”1 bug, $50,000+ in bounties, how Zendesk intentionally left a backdoor in hundreds of Fortune 500 companies” A better edit might be something like: “The $50k bug where Zendesk backdoored Fortune 500 companies”
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.
Earlier quoted context omitted.
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…
I’m not clear on that. If the support requestor doesn’t need to be from the company, then I don’t understand why the email sender has to be spoofed in the first place.
Earlier quoted context omitted.
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.
(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.)
Earlier quoted context omitted.
I’m not clear on that. If the support requestor doesn’t need to be from the company, then I don’t understand why the email sender has to be spoofed in the first place.
The attack requires getting yourself CC’d on a support ticket. In this case to show how bad that is, it was a support ticket that had an oauth ticket to log into slack as “support@company.com”.