Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

1 bug, $50k in bounties, a Zendesk backdoor

gist.github.com

Post reply on HN
Print view View original

361–370 of 437 posts

Re: 1 bug, $50k in bounties, a Zendesk backdoor

#361

Post by Ylpertnodi »

larkinrichards wrote: post #288

Exploit chain-- 1. zendesk allows you to add users to a support issue and view the complete issue history by sending a response email to a guessable support email from a person associated with an issue and cc'ing the person to add. 2. Zen desk depends on a spam check for inbound email validity. This check does not appear to catch instances where sender email is spoofed. Zendesk claims this is bdue to DKIM/SPF/DMARC c…

>it feels like an easy oversight for a 15 year old after getting rejected on the first round.

I'm not 15, but since you ignore(d) me - game over.

Re: 1 bug, $50k in bounties, a Zendesk backdoor

#362

Post by teddyh »

austinkhale wrote: post #266
eatbots wrote: post #64

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…

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

#363

Post by JonChesterfield »

austinkhale wrote: post #266
eatbots wrote: post #64

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…

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-...

We, the company that doesn't understand security, can't tell whether this was exploited, therefore we confidently assert that everything is fine. It's self consistent I suppose but I wouldn't personally choose to scream "we are incompetent and do not care" into the internet.

Re: 1 bug, $50k in bounties, a Zendesk backdoor

#364

Post by urbandw311er »

birdgoose wrote: post #343
rkharsan64 wrote: post #341

Earlier quoted context omitted.

Every time I've left an organization, they have swiftly deleted the company email address/revoked my access to it. I assume every reasonable organization will have processes in place to do this. I don't see this as a vulnerability: how is Google supposed to know that a person has left the company? You let them know by deleting the account.

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…

The example states that the user works at Example Co and email is @example.com

This is the confusion — it’s reasonable to assume that the email is not a personal address.

Re: 1 bug, $50k in bounties, a Zendesk backdoor

#365

Post by fweimer »

rkharsan64 wrote: post #341
quacksilver wrote: post #324

Earlier quoted context omitted.

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…

Every time I've left an organization, they have swiftly deleted the company email address/revoked my access to it. I assume every reasonable organization will have processes in place to do this. I don't see this as a vulnerability: how is Google supposed to know that a person has left the company? You let them know by deleting the account.

This no longer happens for services that have accounts that follow a social media style. For such accounts, employees are expected their own accounts (presumably with followers, reputation etc.) and keep it after leaving the company. For real social media, this is probably fine, but I don't understand why we accept this model for Github and Gitlab (and Sourceware before that). Even from an employee perspective, it's not great because it makes it unclear who owns what. Especially with services like Github which have rules about how many accounts you can create for one person, and under what circumstances.

I have no idea how this is supposed to work in practice for Github and Gitlab, where people gain access to non-public areas of those websites, but they are still expected to use their own accounts which they keep after leaving their employer.

(The enterprise-managed Github accounts do not address this because they prevent public, upstream collaboration.)

Re: 1 bug, $50k in bounties, a Zendesk backdoor

#366

Post by fweimer »

radlad wrote: post #240
Thorrez wrote: post #235

Earlier quoted context omitted.

I agree with your point, but that email's not the best example because it would have passed SPF/DMARC/DKIM. It's a step or two later that involved sending a spoofed email from appleid@id.apple.com : const sendmail = require('sendmail')(); // Assuming the ticket you created in step #2 was assigned a ticket ID of #453 // verification email landed somewhere near there const range = [448, 457]; for (let i = range[0]; i

This is exactly my point: if Apple has SPF/DKIM/DMARC configured correctly, then Zendesk should be validating the email sender. That they didn't is technically an SPF/DKIM/DMARC issue - a bug in Zendesk - but it is not a customer misconfiguration issue.

You don't want to too strict technical validations on your helpdesk contact points, though. It's supposed to be reachable when things are broken. So it's not as easy as just reconfiguring incoming mail relays. You might need separate domains for extended validation, or a reliable (!) way to relay authentication results to those mail endpoints that need it. Come to think of it, presenting email validation results to helpdesk staff might be a good idea in general.

Re: 1 bug, $50k in bounties, a Zendesk backdoor

#367

Post by fweimer »

bigiain wrote: post #329
thekevan wrote: post #295

Earlier quoted context omitted.

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.

He didn't even "go public" as that term is normally used in bug disclosure. He didn't write it up and release and exploit when Zendesk told him it was out of scope and didn't give him any indication they considered it a problem or were planning a fix. Instead he reached out to affected companies in at least a semi private way, and those companies considered the bug serious enough to pay him 50k collectively and in at…

Aren't such disputes about scope relatively common? Not sure what Hackerone can do about it.

For example, most Hackerone customers exclude denial-of-service issues because they don't want people to encourage to bring down their services with various kinds of flooding attacks. That doesn't mean that the same Hackerone customers (or their customers) wouldn't care about a single HTTP request bring down service for everyone for a couple of minutes. Email authentication issues are similar, I think: obviously on-path attacks against unencrypted email have to be out of scope, but if things are badly implemented that off-path attacks somehow work, too, then that really has to be fixed.

Of course, what you really shouldn't do as a Hackerone customer is using it as a complete replacement for your incoming security contact point. There are always going to be scope issues like that, or people unable to use Hackerone at all.

Re: 1 bug, $50k in bounties, a Zendesk backdoor

#368

Post by whstl »

bsbsjsusj wrote: post #348
whstl wrote: post #340

Earlier quoted context omitted.

We also had this problem in my previous company a few years ago, a 20-people company, but somehow we attracted much more attention. In one specific instance, we had 20 emails in a single month about a specific Wordpress PHP endpoint that had a vulnerability, in a separate market site in another domain. The thing is, it had already been replaced by our Wordpress contractor as part of the default install, but it was re…

Keep it as 200, then any reports you get about it can be added to a block list.

That's a much better idea than what we did. A honey pot for bug bounties!

Re: 1 bug, $50k in bounties, a Zendesk backdoor

#369

Post by dns_snek »

hmottestad wrote: post #270
tryauuum wrote: post #265

Earlier quoted context omitted.

if someone's reading this thread: yes, apple does have dmarc / spf $ dig id.apple.com TXT +short "v=spf1 include:_spf-txn.apple.com include:_spf-mkt.apple.com include:_spf.apple.com include:icloud.com ~all" $ dig _dmarc.id.apple.com TXT +short "v=DMARC1; p=reject; rua=mailto:d@rua.agari.com; ruf=mailto:d@ruf.agari.com;"

And it’s still out of scope for the HackerOne bug bounty program.

Future hackers, take note. If vulnerabilities you discover have any chance of being misinterpreted as "out of scope" by some bureaucrat at HackerOne, even though they're obviously applicable and dangerous, sell them on the market instead.

Re: 1 bug, $50k in bounties, a Zendesk backdoor

#370

Post by ryukoposting »

eatbots wrote: post #64

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…

Isn't the simplest solution here to not support SSO at all?

I get there's a convenience factor, but even more convenient is the password manager built into every modern browser and smartphone. If the client decides to use bad passwords, that's will hurt them whether or not they're using SSO.

Post reply on HN