1 bug, $50k in bounties, a Zendesk backdoor
gist.github.com
gist.github.com
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 in June.
Non-directory SSO should not have equal trust vs. directory SSO. If you have a Google account and use Google SSO, Google can attest that you control that account. Same with Okta and Okta SSO.
SIWA, GitHub Auth, etc are not doing this. They rely on a weaker proof, usually just control of email at a single point in time.
SSO providers are not fungible, even if the email address is the same. You need to take this into account when designing your trust model. Most services do not.
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-y and leaves his employer on bad terms.
Bob still has access to the Google account bob@example.com. It didn't get revoked when they fired him and locked his accounts on company systems. He can use the account indefinitely to get Google to attest for his identity.
Example Inc. subscribes to several SaaS apps, that offer Google as an identity provider for SSO. The SaaS app validates that he can get a trusted provider to authenticate that he has an @example.com email address and adds him to the list of permitted users. Bob can use these SaaS apps years later and pull data from them despite having left the company on bad terms. This is bad.
I think the only way for Example Inc. to stop this in the case of Google would be to create a workspace account and use the option to prove domain ownership and force accounts that are unmanaged to either become managed or change their address by a certain date. https://support.google.com/a/answer/6178640?hl=en
Other providers may not even offer something like this, and it relies on Example Inc. seeking out the identity providers, which seems unreasonable. How do you stop your corporate users signing up for the hot new InstaTwitch gaming app or Grinderble dating service that you have never heard of and using that to authenticate to your sales CRM full of customer data?
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.
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.
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 using SIWA and their "company" Apple ID
It's worth noting that OAuth providers - like Apple - include information such as if they are authoratitive or not over a particular account.
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.)
https://support.google.com/accounts/answer/176347?hl=en&co=G...
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.
https://support.zendesk.com/hc/en-us/articles/8187090244506-...
Wow... there was no indication that they even intended on fixing the issue, what was Daniel hackermondev supposed to do? Disclosing this to the affected users probably was the most ethical thing to do. I don't think he posted the vulnerability publicly until after the fix. "Forfeiture of their award" -- they said multiple times that it didn't qualify, they had no intention of ever giving a reward.
For some of our bugs given on h1, we openly say, "Hey, we need to see a POC in order to get this to be triaged." We do not provide test accounts for H1 users, so, if they exploit someone's instance, we'll not only take the amount that the customer paid off of their renewal price, we'll also pay the bounty hunter.
Heads I win, tails you lose.
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 value of the vulnerability was at least 50k.
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.
I am 100% certain that every one of the companies that paid the researched would consider the way this was handled by that researched "the best alternative to HackerOne rules 'ethical disclosure' in the face of a vendor trying to cover up serious flaws".
In an ideal world, in my opinion HackerOne should publicly revoke Zendesk's account for abusing the rules and rejecting obviously valid bug payouts.
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.
He should have said since its not going to be fixed, he will just inform the individual companies.
I'll note he did go to the effort of having the first stab at that sort of resolution, when he pushed back on HackerOne's inaccurate triage of the bug as an SPF/DKIM/DMARC email issue. He clearly understood the need for triage for programs like this, and that the HackerOne internal triage team didn't understand the actual problem, but again was rebuffed.
EDIT: It’s -11 (negative 11) now. Still “0 comments”.
I don't understand what this tries to accomplish. The problem is bad, botching the triage is bad, and the bounty is relatively cheap. I understand that this feels bad from an egg-on-face perspective, but I would much rather be told by a penetration tester about a bug in a third-party service provider than not be told at all just to respect a program's bug bounty policy.
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 is why companies so often try to stop this by any means.
Reading all the many comments, it would appear the damage has been done. Good. But very unnecessary on zd's part.
Another example of impotent PMs, private equity firms meddling and modern software engineering taking a back seat to business interests. Truly pathetic. Truly truly pathetic.
Directory SSO: These are systems like Google Workspace or Okta, which maintain a central directory of users and their access rights.
Non-directory SSO: These are services like "Sign in with Apple" (SIWA) or GitHub authentication, which don't maintain such a directory.
IdentityServer4 [0] is no longer maintained [1] but had SSO support and the source is still on github.
[0] - https://identityserver4.readthedocs.io/en/latest/
[1] - They had to go commercial to stay afloat, there wasn't enough contributions from community/etc. That said it's pretty cheap for what it does in the .NET space.
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.
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.
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?
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.
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.
Side note: I'm not too surprised, as I had one of the worst experiences ever interviewing with Zendesk a few years back. I have never come away from an interview hating a company, except for Zendesk.
And possibly to have blackhats to start looking more closely, since they now know both 1) that whitehats are likely to be focusing elsewhere leaving more available un-reviewed attack surface, and 2) that Zendesk appears to be the sort of company who'll ignore and/or hide known vulnerabilities, giving exploits a much longer effective working time.
If "the bad guys" discovered this (or if it had been discovered by a less ethically developed 15 year old who'd boasted about it in some Discord or hacker channel) I wonder just how many companies would have had interlopers in their Slack channels harvesting social engineering intelligence or even passwords/secrets/API keys freely shared in Slack channels? And I wonder how many other widely (or even narrowly) used 3rd party SaaS platforms can be exploited via Zendesk in exactly the same way. Pretty much any service that uses the email domain to "prove" someone works for a particular company and then grants them some level of access based on that would be vulnerable to having ZenDesk leak email confirmations to anybody who knows this bug.
Hell, I suspect it'd work to harvest password reset tokens too. That could give you account takeover for anything not using 2FA (which is, to a first approximation over the whole internet, everything).
As an aside, I wonder if those bounties in general reflect the real value of those bugs. The economic damage could be way higher, given that people share logins in support tickets. I would have expected that the price on the black market for these kind of bugs are several figures larger.
Also the bit about SPF, DKIM and DMARC seems to show a misunderstanding of the issue: these are typically excluded because large companies aren't able to do full enforcement on their email domains due to legacy. It's a common bug report.
In this case, the problem was that Zendesk wasn't validating emails from external systems.
Correct, the replies seem to have come from H1 triage and H1 mediation staff.
They often miss the mark like this. I opened a H1 account to report that I'd found privileged access tokens for a company's GitHub org. H1 triage refused to notify the company because they didn't think it was a security issue and ignored my messages.
While it's unclear at which stage Zendesk became involved, in the "aftermath" section it's clear they knew of the H1 report, since they responded there. And later on the post says:
"Despite fixing the issue, Zendesk ultimately chose not to award a bounty for my report. Their reasoning? I had broken HackerOne's disclosure guidelines by sharing the vulnerability with affected companies."
The best care scenario as I see it is that Zendesk has a problem they need to fix with their H1 triage process and/or their in and out of scope rules there. And _none_ of that is the researcher's problem.
The worst (and in my opinion most likely) scenario, is that Zendesk did get notified when the researcher asked H1 to escalate their badly triaged denial to Zendesk for review, and Zendesk chose to deny any bounty and tried to hide their vulnerability.
> As an aside, I wonder if those bounties in general reflect the real value of those bugs. The economic damage could be way higher, given that people share logins in support tickets.
I think it's way worse than that, since internal teams often share logins/secrets/API keys (and details of architecture and networking that a smart blackhat would _love_ to have access to) in thei supposedly "internal" Slack channels. I think the fact that non Zendesk "affected companies" paid out $50k sets that as the absolute lower bound of "the real value of those bugs. And it's _obvious_ that the researcher didn't contact _every_ vulnerable Slack-using organisation. I wonder how much more he could have made by disclosing this to 10 or 100 times as many Slack using organisations, and delaying/stalling revealing his exploit POC to Zendesk while that money kept rolling in?
I'll be interested to see if HackerOne react to this, to avoid the next researcher going for this "second level" of bug bounty payouts by not bothering with H1 or the vulnerable company, and instead disclosing to companies affected by the vulnerability instead of the companies with the vulnerability? It's kinda well known that H1 buy bounties are relatively small, compared to the effort required to craft a tricky POC. But people disclose there anyway, presumably party out of ethical concerns and partly for the reputation boost. But now we know you can probably get an order of magnitude more money by approaching 3rd party affected companies instead of cheapskate or outright abusive companies with H1 bounties that they choose to downvalue and not pay out on.
I think it's just laziness. Plus they hire previous famous reporter as the people triaging the reports, those famous people know other famous people first hand, they usually think "hmm, unknown guy, must have ran a script and submitted this"
I have stopped reporting stuff since last 5 years due to the frustration. And it seems the situation is still the same even after so many years.
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.
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.
Zendesk wasn't validating the email senders.
Strictly, $0 because he disclosed to customers. But he only disclosed to customers since Zendesk said it was out of scope.
Bad showings all around, for both HackerOne and Zendesk.
Same thing happened to me years ago. Interviewed with them and it was the worst “screening” experience I ever had. After getting a rejection email, I thanked them for their time and said I had feedback about the interview should they want to hear it. They said yes, please.
Sent my feedback, never heard from them again.
Proper response would be to update your program to triage these vulns and thank the researcher for not going public straight away. This current approach is burning a tremendous amount of goodwill.
I don’t care if you’re the only company in the market, I’ll still blackball you for this in my recommendations.
Zendesk should pay up, apologize and correct their bug bounty program. After doing so, they should kindly ask the finder to add an update to this post, because otherwise it will follow them around like dogshit under their shoe.
If a company loses 120 million a year to security bounties, they will take into account the cost of scrumming/rapid widget delivery.
They should absolutely inform a client company of a perceived threat, when they agree on the threat
Most of the person’s post and responses here are about Zendesk’s issue, but Zendesk was never informed
for a better PR response, I think now Zendesk could reward this after realizing it wouldnt have been disclosed first, and admonish HackerOne for not informing them and the current policies there
If you are a new user expect your first couple reports to be butchered. It seems to me only reports from well known hackers gets carefully analysed.
It's not clear whether they were informed. The mediator's email says "after consultations with *the team*", which is likely referring to Zendesk's security team.
Incredible. This must be some kind of "damaged ego" or ass-covering, as it's clearly not a rational decision.
Edit: Another user here has pointed out the reasoning
> It's owned by private equity. Slowly cutting costs and bleeding the brand dry
1) created for the purpose of either PR/marketing, or a checklist ("auditing"), 2) seen as a cheaper alternative to someone who knows anything about security - "why hire someone that actually knows anything about security when we can just pay a pittance to strangers and believe every word they say?"
The amusing and ironic thing about the second point is that by doing so, you waste time with the constant spam of people begging for bounties and reporting things that are not even bugs let alone security issues, and your attention is therefore taken away from real security benefits which could be realized elsewhere by talented staff members.
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 some money and fame on our behalf.
The root cause in this case seems to be that they couldn’t get by HackerOne’s triage process because Zendesk excluded email from being in scope. This seems more like incompetence than malice on both of their parts. Good that the researcher showed how foolish they were.
- handled with priority, but sometimes it takes a couple of weeks for a more definite fix
- handled by the security department within the company ( to forward to relevant PO's and to follow up)
The unfortunate thing about bug bounties is that you will be hammered with crawlers that would sometimes even resemble a DDOS
It doesn’t make sense, companies with less revenue aren’t the ones doing this. It’s usually the richer tech companies.
A great blog post on the matter https://www.troyhunt.com/beg-bounties/
I'll give an "another side" perspective. My company was much smaller. Out of 10+ "I found a vulnerability" emails I got last year, all were something like mass-produced emails generated based on an automated vulnerability scanning tool.
Investigating all of those for "is it really an issue" is more work than it seems. For many companies looking to improve security, there are higher ROI things to do than investigating all of those emails.
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 returning 200.
But being a static page didn't stop the people running scanners from asking us from money even after they were informed of the above.
The solution? Delete it altogether to return 404.
The logic being that any actual security-researcher with even minimal levels of competency will know to check the security.txt file and can follow basic instructions; while if any of our actual (paying) users find a security issue then they’ll go through our internal ticket site and not public e-mail anyway - so all that’s left are low-effort vuln-scanner reports - and it’s always the same non-issues like clickjacking (but only when using IE9 for some reason, even though it’s 2024 now…) or people who think their browser’s Web Inspector is a “hacking tool” that allows anyone to edit any data in our system…
And FWIW, I’ve never received a genuine security issue report with an admission of kitchen refrigeration of fruit in the 18 months we’ve had a security.txt file - it’s almost as-if qualified competent professionals don’t operate like an embarrassingly pathetic shakedown.
But after the PoC that showed the severity in a way that anyone could understand, they still didn't pay. That's the issue. The whole investigation was done for them.
Later
I wrote this comment before rereading the original post and realizing that they had literally submitted a DKIM report (albeit a rare instance of a meaningful one). Just to be clear: in my original comment, I did not mean to suggest this bug was silly; only that in the world of security bug bounties, DKIM reports are universally viewed as silly.
>In addition to this, we also implemented filters to automatically suspend the following classes of emails: User verification emails sent by Apple based on the Reply-To and Message-Id header values Non-transactional emails from from googleworkspace-noreply@google.com Over the coming months, we will continue to look into opportunities to strengthen our Sender Authentication functionality and provide customers with more gradual and advanced security controls over the types of emails that get suspended or rejected.
So is it still possible to hijack anyone's support tickets using the default configuration of Zendesk if you just happen to know their email and ticket ID?
Zendesk is very well aware of SPF/DMARC, from their support pages.
https://gist.github.com/hackermondev/68ec8ed145fcee49d2f5e2b...
[1] https://gist.github.com/hackermondev/68ec8ed145fcee49d2f5e2b...
Yes, the researcher could have tee'd himself up better, but this says way more about zendesk than it does about the 15-year-old researcher.
It's possible that some chains could have credentials or other sensitive information in ticket chains.
Clearly Zendesk needs to change things so that the email address that is created for a ticket isn’t guessable.
Of course, this is only a good strategy if you're just wanting to do a good deed and not counting on getting more than a thank you note, but Zendesk or Hackerone (whoever you want to blame here) didn't even accept the bug in the first place. That's the problem here, not the omission of an exploit chain
We add impact demonstrations to a few findings per pentest report because our audience is broader: the nontechnical people who decide to allocate the money need to understand why this is useful and that the devs/sysadmins need to get enough time to do things right (developers and sysadmins are often sufficiently skilled, but are under delivery pressure). A sufficiently technical team, when the bug is adequately explained, doesn't need a functional exploit to see it's real/impactful or not
The reason people don't do this is because they think they have something that can be modified into another bug. Which is exactly what happened here.
White hat hackers do not require companies to pay them in exchange for not revealing a bug---the reveal of a bug only happens if a company doesn't fix that bug. Companies can be jerks and refuse to pay anything. That doesn't give you the right to blackmail them---you and other security researchers can just refuse to help them in the future.
A refusal to fix the vulnerability is what happened in the original blogpost, so it was fair game for release since the company doesn't care.
Hackers that don't care about ethics or legality won't bother blackmailing companies with vulnerabilities. They'll sell or use the vulnerability to steal more important data, and blackmail companies for millions of dollars in crypto.
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.
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.
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.
But also, SECURITY culture concerns beat culture culture. Companies should def consider ditching them for this lapse and their poor form in making it right.
If Zendesk is smart, they should hop on this thread and pay this kid out while everyone is still paying attention in one place, rather than later, when everyone is quietly making business decisions in a thousand little alcoves of the internet.
Otherwise, this is the best thing to happen to the Zendesk Alternatives in a long time
I'm actually pretty annoyed at the stupidity, it's the kind of thing that even a shitty search engine won't be fooled by and hey when I search for Zendesk alternatives I don't see any brand called Zendesk alternative in first few results.
I mean it's like they're too stupid to do what every other weaselly scumbag does, get some fake reviews up comparing your brand to alternatives with the reviews carefully weighted so your target customer base will be uh, I guess Zendesk is really what we want then.
Or at least buy an ad words for the search - with the words Zendesk - There is No Alternative showing up before all the alternatives.
It's ok Zendesk if you use my clever slogan because you can't think of one on your own - I'm not expecting you to pay me for it.
Searching `Zendesk alternative` (no s, no quotes):
- Google shows it in the top 5 results.
- Bing shows it on the second page.
- Brave shows it in the middle of the first page.
- DDG doesn't show it.
- Yahoo shows it on page 3
- Yandex doesn't show it
So no harm, no foul, right?
Calling yourself 'charmed' by an insecurity-driven marketing shtick that denies rational competition is certainly one reaction.
"The book burning was abhorrent, in principle. But the lights were so calm and the fire was so warm... I was actually kinda charmed!"
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.
Yes, that’s it. They paid their marketing team to do this to be funny.
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):
That's evil!
I wouldn't read too much into this because one unmaintained old website will not going to make or break the SEO game of others.
Takes me back to a more innocent time of the Internet.
Search engine chaff has been in the toolbag of "reputation management" PR firms for a while. Boris Johnson (former UK PM) deployed it many years ago to drown out a viral picture of him in front of a red bus bearing an ad he no longer wanted to associated with, so he was coached to tell an interviewer he has a hobby of painting model buses red.
And in 2027, Zendesk finds that the strategy worked. A little too well! Now the top search result for Zendesk is the rock band, and if you ask an AI about Zendesk, the AI starts yappin about a rock band too! Hahaha
that is hilarious, but also the most non punk rock thing I've ever read. if Apple did it, every one here would be fawning over how genius of a move it were
I love the self report :^)
Edit: Why don’t they seem to value their credibility?
Ironically, the domain was given to DDG from Google.
To Daniel/hackermondev: whatever you're doing, keep it up!
This architecture makes 0 sense to me. Even if an org has totally outsourced its identity and auth management to Google (is this possible?), presumably that would include controls over how new @targetorg.com identities are created on the Google end.
No F500 companies are using Apple as an identity provider since they definitely don't sell such services. So why would an F500 company configure Slack to allow Apple OAuth & introduce this vulnerability?
Tangentially, this does raise one of my big issues with using OAuth2 for single-sign-on though, which is that it really doesn't address the third-party authorization problem well. Ok, you're bob@example.com, Google has verified that, and example.com is our domain, so we're letting you into our app Foobar. Now what? The scopes you requested were for Google APIs only and have nothing to do with Foobar really. So now we need to implement an authorization system in Foobar that decides what bob@example.com can actually do. This part, and how to do it right, gets glossed over (at best!) by discussions on OAuth2. It also gets glossed over by product and security when they want things "SSO-enabled", which means development time doesn't get budgeted for it. Even just using groups to control coarse access levels requires integration with provider-specific APIs. OAuth2 is great for identity and authentication, but far too little attention has been paid to doing authorization right.
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.
But even so, there's another mechanism, which is that when you create an OAuth2-enabled project in Google's console, you can specify that only known users in your domain are allowed to authenticate through it. This would lock out any personal account anyway.
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: my email archives show some emails from Zendesk using the integer and other emails using a random alphanumeric string. It seems to vary by company so it might be some sort of configuration setting?)
2. Slack allows third-party domain-wide logins via Sign in with Apple without additional verification that the email belongs to a real person. Here the author of the article pretends to be support@company.com to Slack and Slack lets them into the company.com channel, despite the fact that support@company.com does not actually represent a real user and is only intended to be a receiving email address that forwards into Zendesk. (This sounds more like a configuration problem than anything else though.)
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
Zendesk deserve a lot of flack here, especially after they already realized this is real. However, just to empathize a bit: the amount of spam SPF, DKIM, DMARC "security" reports anyone running a service gets is absolutely insane. So it's very easy to accidentally misclassify what this reporter originally discovered as that by accident.
Zendesk gave me a tshirt but not any money for it. C'est la vie.
Huh? I don't think you can read page contents unless the origin matches exactly (scheme://host:port).
So for this to work still, you need to bypass a spam filter.
They should just force DMARC and SPF like Google has done, and say "your fault if you misconfigure". Also default-off for the CC thing would be a good idea, too, with a warning of what could happen if they turn it on. Alternatively making a non-guessable id for the email.
EDIT: they absolutley should not use an autoincrementing int as a "support-chain token" though, that's a workaround they could easily do.
I checked my email archives and some (but not all) of the emails I've received from Zendesk have arbitrary alphanumeric ids in the Reply-To header instead of integers. Seems to depend on the company, perhaps this is a configuration issue?
Though his pondering of 'why do companies use third party support systems instead of rolling their own' gave his age away :)
What was the planned response for addressing the vulnerability reported through the Bug Bounty program, and how did the plan change after the researcher escalated the issue directly to Zendesk before remediation was completed?
According to the researcher, they only contacted 3rd parties after Zendesk rejected the disclosure as out of scope, as they are free to do.
If this timeline is incorrect, Zendesk should immediately correct the record. As it stands, accusing the researcher of violating ethical principles looks very bad for Zendesk. Perhaps even libelous.
That it affected Slack was a side-effect of the original bug, and not a new, previously undisclosed bug. Zendesk fixed the original bug, after rejecting the disclosure. Given all that, Zendesk is still ethically bound to honor the bounty, 3rd party disclosures notwithstanding.
Are you yourself not at fault for forcing him to violate the terms in order to protect your customers?
2. "they violated key ethical principles by directly contacting third parties about their report prior to remediation", what is a violation of ethical principles is to know about a security failure in your application and ignore it, leaving customers at risk, can't wait for some law to pass so people who behave like that face consequences.
3. "We have no evidence that this vulnerability was exploited by a bad actor.", tldr, it don't fixed it until some vendor dropped us, because before that happened, it was cheaper to ignore it.
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.
The original is:
”1 bug, $50,000+ in bounties, how Zendesk intentionally left a backdoor in hundreds of Fortune 500 companies”
A better edit might be something like:
“The $50k bug where Zendesk backdoored Fortune 500 companies”
50k corresponds to the money they made with unrelated bug bounties.
I wish they would fix the title so that it properly calls out zendesk refused to pay for a serious bug.
1 bug, 50k:
I don't know why the "1" got dropped.
If you submit "Why I care" it'll decide that you meant 'I care".
If you submit "10 More Secrets in Pokemon" it'll decide you meamt "More Secrets in Pokemon".
Conversely, there's an entire cottage industry focused on writing attention-catching headlines, which results in patterns like what HN mangles.
If it's annoying, OP can edit immediately after submitting to overwrite the mangled title with the correct one.
"SPF, DKIM, and DMARC issues" is absolutely and positively intended to mean "we don't care if we are missing these headers on our domains", in part because this is 99.9% of drive-by beg bounties (if you are tired of getting "I HAVE FOUND A SERIOUS SECURITY ISSUE IN YOUR WEBSITE" cc'ing security@, legal@, privacy@, and your CEO on a monthly cadence, just set up a DKIM record :P)
Yes, this is technically a bug which is in the space of SPF, DKIM, and/or DMARC. But this is absolutely NOT WHAT THE EXCLUSION IS FOR. Hacker One triage teams should know better, and it's frankly embarrassing that they don't. And it's frankly mortifying that their mediation team also didn't pick up on this.
But it checks out.
This is one of the reasons I will not use Hacker One ever. Bugcrowd is slightly better. Intigriti has (so far) been pretty good. I'm not affiliated with any of them, just have been a customer of all three.
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.
I generally refuse to go through platforms now (also because I really hate being subject to the psychological pressure of a "social credit system", even though I understand why the platforms do it), so if your company doesn't have an alternative reporting form, or refuses bug bounty payouts when a valid issue was reported directly through them instead of through a platform (hello, Backblaze!), I'm not doing free labor for you and you will likely hear about the bug when either someone else finds it or I include it in a public write-up (if it's a bug affecting multiple companies).
You're better off not bothering contacting them.
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 config but I have trouble imagining that 50% of Fortune 500 would get this wrong. There are many automated checks available.
3) Apple issues an Apple ID account to anyone who can receive a verification email Sent to the mailing address (support@company.com)
4) Slack allows you to sign in to a workspace using any Apple ID associated with the workspace domain (e.g. support@company.com)
This researcher reported #2 to hackerone and was declined. Researcher later discovered full exploit with 3 and 4. Did not update hackerone, contacted affected companies directly.
it would have been prudent to update hackerone on the additional finding, but it feels like an easy oversight for a 15 year old after getting rejected on the first round.
Zendesk should take the higher ground and recognize the mistake and correct it. Not get all "ethical mumbo jumbo."
I'm not 15, but since you ignore(d) me - game over.
Do you find it surprising that they use Microsoft Office too? Paying someone else to handle things like this is cheaper than paying developers and hosting a service like this.
And also that being brilliant doesn’t magically correlate with being knowledgeable.
For some reason this like cracked me up. Sounds exactly like something 15 year old me might say :-).
Let’s build our own ticketing system! How hard could it be?
H1 should restrict ZD from their platform.
It is challenging for Zendesk to enforce or fix DKIM, SPF, and DMARC issues across all client domains so better to just ignore it :grimace:
The irony is that they have the worst support and one of the worst response times to issues reported. You will find many experiences on LinkedIn reporting this.
For a company built on email, they're not good at it.
I thought this was mainly mitigated by invalidating the assumption that “only authorized employees can control a company email” – it used to be common 5-10 years ago to verify “that you’re an employee” that way, but I just assumed that kind of stopped in favor of whatever SSO/SAML stuff that became popular with enterprise.
Is this the same thing? Or a variation?
If you value your time and your health, don't use these platforms. If platforms want security, they can hire people by the hour/day and pay them the relevant wages.
So the hacks put in place to deal with Google SSO hadn’t been put in place for Apple’s.
Also, what Fortune 500 company is leaving slack’s email based login feature enabled? Why wouldn’t they all be using a corporate SSO solution tied to their company’s slack directory?
Also I think this is a good reminder that using sequential IDs for anything public facing is almost always a bad idea (or at the very least something you should think very hard about). It would be pretty easy to make ticket ID, for example, a sequential 5 digit number followed by 4 random alphanumeric characters. Everyone could still easily refer to the ticket number, but it wouldn't be guessable.
Nothing changes for them even if they ignore one report, especially from an unknown researcher.
It exposes pretty sad state of the industry. Who said enterprise?
I.e. you have domain support.example.com, CNAMEd to Zendesk, so you cannot add any other DNS record to it, but Zendesk should do it on their side. But they refuse, and force you to put CAA to your root domain example.com.
https://medium.com/intigriti/how-i-hacked-hundreds-of-compan...
Wait - how is that workflow possible and supported?
In my head, authorization under @company.com would be delegated to a central directory, instead of relying on Apple ID. It is effectively an authentication bypass.
I would add that HackerOne could also take an action and influence in the positive outcome and not being just a MiM.
Why do they even have a bounty program if they do this?
I like this kid
No responsibilities and all the time in the world to learn with the right circumstances, they can go far.
Older devs who are experts in this area are already busy making money and working on their employer's security.
Ah, yes, why do laymen always think this?
I mean, I get it, Krupp and mining towns used to be a thing, so it is possible.
But every big company should build a ticketing system? Why not an email solution, OS, network routers too?
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.
Come on, honor your bug bounty. Especially when it can bite you in the ass hard enough to plummet stock prices if a bug of this caliber is exploited in the companies you serve
That this hurts Zendesk is too bad, it's still the morally correct thing to do and Zendesk probably understands that, too