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

411–420 of 437 posts

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

#411

Post by johnnyanmac »

eloisant wrote: post #400
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.

We have 2 conflicting sides of the story, who knows which one is bullshiting.

Probably the one that got mad at clients being dropped over an issue "not serious enough to triage".

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

#412

Post by johnnyanmac »

teddyh wrote: post #372
Shank wrote: post #322

Earlier quoted context omitted.

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

> "Pissing off the hackers" is not a way to keep people reporting credible bugs to your service. That doesn’t matter if your goal with a bug bounty program is not to have people reporting bugs, but instead to have the company appear to care about security. If your only aim is to appear serious about security, it doesn’t matter what you actually do with any bug reports. Until the bugs are made public, of course, which…

sounds like a great way to get a bunch of black hats to target you after pissing off the white hats. Playing nice with people this smart should be precisely to prevent this kind of damage to a company that results in losing clients.

But I geuss corporations ignoring security for more immediately profitable ventures on the quarterly report is a tale as old as software.

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

#413

Post by nodamage »

marcellus23 wrote: post #310
lathiat wrote: post #309

Earlier quoted context omitted.

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? A…

I think the most likely threat in this case is with ex-employees. If Bob has access to bob@example.com and creates an Apple account with it, then subsequently gets fired from example.com, they might delete his email address but his Apple account will still allow him to login to services using Sign in with Apple. (Because Apple only checks ownership of the email address when the Apple account is being created.)

Google accounts have the exact same issue so I don't understand the distinction made by the OP though.

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

#414

Post by jokethrowaway »

jazz9k wrote: post #249

I've been making money finding bugs for H1 and have made >100k. I finally stopped when two large companies have stopped communicating with me over the last year (all bugs have been triaged on the H1 side). They owe me a total of around 30k. H1 can't do anything about it. It seems there is no actual contract in place to protect researchers.

Name and shame the companies

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

#415

Post by philipwhiuk »

ZendeskTeam wrote: post #248

Our team at Zendesk has posted some more details about this bug here: https://support.zendesk.com/hc/en-us/articles/8187090244506-...

Other than violating the Bug Reporting program how else would it have been fixed given you failed to recognise the issue?

Are you yourself not at fault for forcing him to violate the terms in order to protect your customers?

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

#416

Post by smithstreet »

This vulnerability in ZD appears to be made worse by ZD's Suspended/Spam feature. There is no indication in the spam queue that there is someone CC'd on the email. So an agent may see a ticket from their customer and approve it. Even when you then view the ticket, there is still no indication there is a CC'd third party unless you 'View original' on the email.

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

#417

Post by mjomaa »

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…

You mean automatic account linking with unverified emails?

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

#418

Post by [deleted] »

laz wrote: post #375
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…

You don't need full blown workspace, which costs money, you can set up "cloud identity free" and claim the domain. When you're setting it up, you can choose what to do with any existing accounts that are part of your domain: kick them out or merge them in.

[deleted]

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

#419

Post by hennell »

zrobotics wrote: post #354
birdgoose wrote: post #343

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

You can sign up for google with an existing email. So if example.com is all on MS365 that's where the admins control stuff. No google workspace at all, no DNS records or proof of domain to anyone but MS.

So anyone with an example.com email can make a google account using that email as their login. Verify they have the email and that's their login. A common system for users who need to use google ads or analytics.

But when the company disables 365 login the google account remains. And if you use something third party that offers a "Sign in with google" then assumes because you have a google account ending "example.com" you are verified as "example.com" you've got access even if that account is disabled.

If you have the google admin portal this doesn't work as you're controlling it there. But signing up for Microsoft or Apple accounts with that google workspace address might have the same loophole.

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

#420

Post by oliwary »

quacksilver wrote: post #324
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…

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…

Perhaps the following could be a solution to this issue?

Any OAuth provider should send a flag called "attest_identity_ownership" (false, true) as part of the uaht flow, which is set to true if the account is a workspace account or gmail (or the equivalent for other services), and false if the email is an outside email. Thus, the service handling the login could decide whether to trust the login or proceed otherwise, e.g. by telling the user to use a different OAuth service/internal mechanism where the identity is attested.

Post reply on HN