Big surprise that companies which outsource everything to India and other countries are hacked. No, not really. GL HF
1 bug, $50k in bounties, a Zendesk backdoor
301–310 of 437 posts
Re: 1 bug, $50k in bounties, a Zendesk backdoor
#302Re: 1 bug, $50k in bounties, a Zendesk backdoor
#303Our team at Zendesk has posted some more details about this bug here: https://support.zendesk.com/hc/en-us/articles/8187090244506-...
This response looks really bad for ZenDesk.
This is blatant dishonesty- the post documented in detail that the reward had already been denied, and the issue ignored multiple times before they contacted 3rd parties. That is not an ethical violation but an ethical necessity- after ZenDesk refused to act, they had an ethical responsibility to inform everyone affected.
This alone is a huge red flag that ZenDesk isn't a trustworthy organization, on top of trying to hide rather than correct security issues unless they get bad press.
If I were ZenDesk, I would pay out the bounty to this kid immediately, and release a detailed public apology explaining how the entire bounty review system has been revamped to take things like this much more seriously in the future.
Re: 1 bug, $50k in bounties, a Zendesk backdoor
#304Earlier 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 am actually seriously interested in what people there do day to day. I’m wondering this about a lot of very large companies, I would definitely watch a documentary about that.
At some point, most of your engineering time is spent on trying to understand what the previous team did. There's probably some engineer at Zendesk banging his head on the table because his boss wouldn't let him fix the sequential ticket IDs when he found them two months ago.
Re: 1 bug, $50k in bounties, a Zendesk backdoor
#305Reported 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…
Presumably one of the PMs you’re referring to has posted this article for additional information. Feels like they’re doubling down on their initial position. https://support.zendesk.com/hc/en-us/articles/8187090244506-...
[deleted]
Re: 1 bug, $50k in bounties, a Zendesk backdoor
#306In case it's not clear these are the two separate vulnerabilities: 1. Zendesk allows you to add a CC to any existing support ticket by sending a (spoofed) reply from the original requestor's email address to that ticket's Reply-To address and including a CC in the email. In some circumstances the Reply-To address is based on an auto-incrementing integer so it can be guessed. (Although this may not alway be the case:…
IMHO the second problem goes deeper:
Sign In with Apple is allowing you to "create an account"(author's words) on @company.com, which should not be supported in the firat place. Instead, it should rely in a central directory controlled by company.com for authentication
Re: 1 bug, $50k in bounties, a Zendesk backdoor
#307Looks similar in concept to this finding from 2017: https://medium.com/intigriti/how-i-hacked-hundreds-of-compan...
It's linked in the post.
Re: 1 bug, $50k in bounties, a Zendesk backdoor
#308Reported 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…
Can you explain a bit more what makes Sign in with Apple different from Google Sign-in? Apple certainly does maintain a list of users with accounts. So what does "non-directory" mean here exactly? Why can Apple not attest that you control that account at sign-in time?
Re: 1 bug, $50k in bounties, a Zendesk backdoor
#309Reported 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…
Can you explain a bit more what makes Sign in with Apple different from Google Sign-in? Apple certainly does maintain a list of users with accounts. So what does "non-directory" mean here exactly? Why can Apple not attest that you control that account at sign-in time?
I think what he means is, if you have an @gmail.com account via Google, that is pretty good proof of control. But if you have any other e-mail (e.g. a custom domain) via Google, it's not.
Similar with Apple, if you were signing in with an @icloud.com, it's pretty good proof, but if you have an Apple ID with a third-party e-mail it's not proof of current control of that e-mail.
That's my guess.
Re: 1 bug, $50k in bounties, a Zendesk backdoor
#310Earlier quoted context omitted.
Can you explain a bit more what makes Sign in with Apple different from Google Sign-in? Apple certainly does maintain a list of users with accounts. So what does "non-directory" mean here exactly? Why can Apple not attest that you control that account at sign-in time?
I think what he means is, if you have an @gmail.com account via Google, that is pretty good proof of control. But if you have any other e-mail (e.g. a custom domain) via Google, it's not. Similar with Apple, if you were signing in with an @icloud.com, it's pretty good proof, but if you have an Apple ID with a third-party e-mail it's not proof of current control of that e-mail. That's my guess.
That helps, but I still don't have a full picture. What's the threat here? Is it that: if a hacker gains temporary access to Bob's email bob@example.com, they can create an Apple account attached to it, and use that account to sign in with a service ABC, then that hacker gains access to Bob's private info in service ABC? But if the hacker already has email access, can't he just log into service ABC directly anyway?
Also, is it impossible to have a Google account with a non-gmail address? The original poster seemed to be saying that Google _is_ a directory SSO and Apple _is not_ categorically. But if you can have a Google account without a Gmail-ran email account, wouldn't Google have the same vulnerability?