Looks similar in concept to this finding from 2017: https://medium.com/intigriti/how-i-hacked-hundreds-of-compan...
It's linked in the post.
1 bug, $50k in bounties, a Zendesk backdoor
391–400 of 437 posts
Re: 1 bug, $50k in bounties, a Zendesk backdoor
#392Earlier quoted context omitted.
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-...
That article claims to have “0 comments”, but currently sits at a score of -7 (negative 7) votes of helpful/not helpful. I think they have turned off comments on that article, but aren’t willing to admit it. EDIT: It’s -11 (negative 11) now. Still “0 comments”.
Re: 1 bug, $50k in bounties, a Zendesk backdoor
#393Earlier quoted context omitted.
> Although the researcher did initially submit the vulnerability through our established process, they violated key ethical principles by directly contacting third parties about their report prior to remediation. This was in violation of bug bounty terms of service, which are industry standard and intended to protect the white hat community while also supporting responsible disclosure. This breach of trust resulted i…
Fwiw, I wouldn't be surprised if the author of this article is a bit upset that Daniel hackermondev gained a significant % of the income that the author makes a year. If this was "fixed" by Zendesk, they would have paid less than a few % from the 50k they actually made. Edit: to those downvoting, the fact of the matter is that Zendesk's maximum bounty is far lower than 50k; yet OP made 50k; meaning by definition the…
Re: 1 bug, $50k in bounties, a Zendesk backdoor
#394Earlier quoted context omitted.
In the above example, the Company doesn't have anything to do with the Google account that the user created themselves. I don't know if Google is the best example here. Apple might be a better one: 1. User's work email is user@company.com 2. User creates Apple ID using their work email. Their Apple ID is user@example.com 3. User gets fired and their company email is deleted 4. User can still sign in to the SaaS apps…
In the above example, the normal flow to get a Google address user@company.com relies on setting DNS records for company.com, both to prove control of the domain as well as to route email to that domain. There may be an exploit/bypass I'm not seeing, but I legitimately don't see any way a user who has a legitimate user@company.com email address hosted somewhere besides Google workspace could then setup a user@company…
Re: 1 bug, $50k in bounties, a Zendesk backdoor
#395Reported 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…
I do web app testing and report a similar issue as a risk rather often to my clients. You can replace Google below with many other identity providers. Imagine Bob works at Example Inc. and has email address bob@example.com Bob can get a Google account with primary email address bob@example.com. He can legitimately pass verification. Bob then gets fired for fraud or sexual harassment or something else gross misconduct…
Re: 1 bug, $50k in bounties, a Zendesk backdoor
#396Earlier quoted context omitted.
> The unfortunate thing about bug bounties is that you will be hammered with crawlers you mean your product will be hammered by people testing to find holes, thus garner the bounty? or some other reason?
Yes. Crawlers, security scanners, ... Eg. Testing all vulnerable wp plugin paths on all domains. Multiple times a minute
Re: 1 bug, $50k in bounties, a Zendesk backdoor
#397Earlier quoted context omitted.
The Slack takeover exploit is a problem on Slack's end (and sounds more like a configuration issue than a bug) so Zendesk would not be responsible for that anyway though.
I disagree, the problem is clearly on Zendesks end.
But simultaneously you should not be able to get into a company Slack by simply having an account with a @company.com email address created by a third-party SSO provider.
In other words, even in Zendesk fixed their problem, Slack would still have a problem on their end.
Re: 1 bug, $50k in bounties, a Zendesk backdoor
#398In 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
#399Earlier 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…
HackerOne is an awful company with a terrible product. Not the first time I’ve heard of their triage process or software getting in the way of actual bug bounty.
The company did fix the issue a few months later, so there's that.
Re: 1 bug, $50k in bounties, a Zendesk backdoor
#400Earlier quoted context omitted.
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-...
So when the researcher said it was a bug, they said, "No, it's fine. No bug bounty, sorry." THEN the researcher eventually goes public. Later, Zendesk announces the bug and the fix and says there will be no bug bounty because the researcher went public. Is that how it went? I mean if so, that's one way to save on bug bounties.