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

381–390 of 437 posts

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

#381

Post by UncleMeat »

layer8 wrote: post #82
bsuvc wrote: post #3

It sounds like the author got stiffed by Zendesk on this bug, $0 due to email spoofing being out of scope. The $50k was from other bug bounties he was awarded on hackerone. It's too bad Zendesk basically said "thanks" but then refused to pay anything. That's a good way to get people not to bother with your big bounty program. It is often better to build goodwill than to be a stickler for rules and technicalities. Sid…

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

In a past life I was involved in a bug bounty program. I don't think the reasoning is as detailed.

When you stand up a bug bounty program you get a ton of "I opened developer tools, edited the js on your page, and now the page does something bad" submissions. "I can spoof some email headers and send an email to myself that looks like it is coming from you" isn't something I've specifically seen due to some weird details about my bounty program but it is something I would absolutely expect for many programs to see.

So you need a mechanism to reject this stuff. But if that mechanism is just "triage says this is dumb" you get problems. People scream at you for having their nonsense bug rejected. People submit dozens of very slightly altered "bugs" to try to say "you rejected the last one for reason X but this one does Y." So you create a general policy: anything involving email spoofing is out of scope.

So then a real bug ends up in front of the triage person. They are tired and busy and look at the report and see "oh this relies on email spoofing, close as out of scope." Sucks.

I think that Zendesk's follow up here is crap. They shouldn't be criticizing the author for writing about this bug. But I do very much understand how things end up with a $0 payout for the initial report.

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

#382

Post by mtlynch »

IAmGraydon wrote: post #315
mtlynch wrote: post #61

Earlier quoted context omitted.

I think that's pretty funny and not particularly malevolent. It's a fake alt rock band called Zendesk. It's obviously tongue-in-cheek and not going to deceive anyone. Also, anytime I search for "X alternative" the results are all AI-generated garbage anyway, so I'd welcome something quirky and original like this in my results.

> It's obviously tongue-in-cheek and not going to deceive anyone. Yes, that’s it. They paid their marketing team to do this to be funny.

It seems like you're being sarcastic, but I think that's really what happened. I think it's much more about getting press for doing something funny than it is about having a meaningful impact on cluttering search results.

It's the same reason why Google paid its marketing team to make a promo for Gmail Blue (back in 2013 when Google was still doing legitimately funny fake promos):

https://www.gmail.com/mail/help/intl/en/promos/blue/

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

#383

Post by hmottestad »

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.

Got a -1 on this comment. Must mean that I’m wrong and that it’s become part of the scope now!

Maybe someone wants to post a link?

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

#384

Post by OptionOfT »

bsuvc wrote: post #20

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.

In general it has become acceptable to create fake pages to get traffic to your website. E.g. this like: https://instatus.com/blog/best-open-source-status-page-servi... the 0th entry is taken by the service itself, and they're not open source...

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

#385

Post by arendtio »

Are you not allowed to discuss a vulnerability you found when it is considered out of scope?

I mean it sounds weird to argue that you won't pay, but do not allow the person to talk about it anyway. Even more so if the person communicated with affected companies instead of some darknet marketplace.

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

#386

Post by m11a »

paulpauper wrote: post #7
ldoughty wrote: post #4

I hate that Zendesk refused to pay out for this bug. The author made a good faith effort to report it. The author also tried to escalate it. After they decided not to work on it, they later came back and asked him for more information and treat it like a bug... Author should have gotten a reward. Did everything right if Zendesk claims it's not a in scope bug.

That is how it works. Do nothing so that the researcher breaks the rules innadvetedly as an excuse to not pay, and then fix the problem.

Doubtful. It's probably just incompetence, rather than malice.

The incident almost certainly cost Zendesk more in (according to the gist) lost contracts and reputational damage than it would've cost to pay the security researcher a bounty.

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

#387

Post by m11a »

kbolino wrote: post #97
twoodfin wrote: post #48

Slack seems to be getting off too easy here. The security—as implemented by Fortune 500 customers??—of an org-wide security domain (i.e. what everyone in an org can see) depends on whether any of the supported OAuth providers can be tricked into provisioning an account with @targetorg.com? This architecture makes 0 sense to me. Even if an org has totally outsourced its identity and auth management to Google (is this…

If you're using Google for identity and authentication, you can definitely control who has an active account in your domain. There can be some lag time before disabling or removing someone truly disables all their downstream accesses, but that's largely outside Google's control. The only way to trick your way into getting a corporate domain email address is to socially engineer a domain admin. Tangentially, this does…

This comment makes the most sense to me in this thread.

Further, IMO, sure it's a bug that one can say they control support@company.com. But IMO the real issue is lousy, permissive authorisation that gives access to anything simply by virtue of controlling a @company.com mail. Surely some HR/tech person, when an employee is being onboarded, should be enabling access to some core systems (probably by adding them to a group), and the default state for an account with no groups should be no access.

In any large enough organisation, IME there's a lot of ways to get a @org.com email, and too many people/systems have the ability to create an email than a single centralised IT team.

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

#388

Post by justusthane »

mmsc wrote: post #58
jeroenhd wrote: post #52

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.

>HackerOne declared the issue out of scope so I don't see why disclosure would make a difference here. Indeed, but just you wait for Zendesk to say "well, _we_ didn't mark it out of scope!" as if delegating it to h1 renegades all responsibility.

They did, though. The post also quotes a response from Zendesk declaring it out of scope.

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

#389

Post by Ylpertnodi »

Shank wrote: post #322
austinkhale wrote: post #266

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

In damage control mode, Zendesk can't pay a bounty out here? Come on. This is amateur hour. The reputational damage that comes from "the company that goes on the offensive and doesn't pay out legitimate bounties" impacts the overall results you get from a bug bounty program. "Pissing off the hackers" is not a way to keep people reporting credible bugs to your service. I don't understand what this tries to accomplish.…

>In damage control mode, Zendesk can't pay a bounty out here?

Reading all the many comments, it would appear the damage has been done. Good. But very unnecessary on zd's part.

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

#390

Post by crusty »

marcellus23 wrote: post #308
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…

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?

Now? nothing. I think this thinking is a relic of Google's status as seemingly the last remaining email provider to automatically create a Gmail account when signing up for a Google account. So using Google SSO meant using your Gmail account, and so control of the email address was nessissary for control of the Google account. If you lose the email account, you lose the Google account. This is not true anymore since you can sign up for a Google account with any email.

Whereas you can (and I believe always could*) create an apple ID with any old email address.

*Maybe this delinked situation only came about when they added the App Store to OS X, and figured they'd make less money if they require existing Mac users to get a new email account in order to buy programs in the manner which would grant them a cut.

Apple has a list of all the email addresses for its sole IDs, but it doesn't control them, and having one deleted doesn't nessisarilly affect the other.

Google and custom domain email have always been delinked from this perspective. You could create a Google account with a custom domain and then point the domain elsewhere or lose control of it, and you'd still retain conto of the account.

Basically, the required example essentially theoretical at this point - maybe it works for employers at companies that also happen to provide SSO services. So if you work at Facebook, Google, Apple, or github and have a me@FGAG.etc.com email dress, and you signed into slack through the SSO that affiliated with your company and the company email, but later don't work there and you've had your work account access revoked, you won't be able to use that SSO to sign into slack. That's what they mean by directory control or whatever.

In contrast, if you sign up to github with your work email account, unless it's a managed device managed by your work, your work doesn't actually control the account. They just vouched for your affiliation at sign up when you verified your email. So if you use a github SSO to sign up for a service that 'verifies' your work email address from github during the process, that won't change when you leave and the company revoked access to the email. Github SSO, in this case, isn't verifying you have an email account @company.com. They are verifying you once did, or at least once had, access to it. This is what they mean by the non-directory whatever.

Post reply on HN