18 ms·

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

• gtirloni 2y ago
  I never understood these technicalities in HackerOne. Oh, you hacked us in a way we said we don't like? Sure, the blackhats will abide.
• pavlov 2y ago
  The edited title on HN is incomprehensible. 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”
  • mmsc 2y ago
    It was supposed to be 1 bug, 50k: I don't know why the "1" got dropped.
    • deleted 2y ago
      [deleted]
    • deleted 2y ago
      [deleted]
    • some_furry 2y ago
      HN mangles submission titles. 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.
  • gouggoug 2y ago
    That title is also completely misleading because the author did not in fact get paid. 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.
    • masfuerte 2y ago
      I understood it to mean that he received $50K from enterprises using Zendesk who were vulnerable to this bug, but it's not entirely clear.
    • cjbprime 2y ago
      "Unrelated" doesn't sound right. Zendesk refused to pay for the vulnerability, so the researcher used it against downstream customers of Zendesk, who did pay the researcher for the impact of that Zendesk vulnerability against their own company.
      • gouggoug 2y ago
        Indeed - I misspoke.
• ciabattabread 2y ago
  A demonstration of the ol’ adage that in order to solve a problem, make it someone else’s problem.
  • mnau 2y ago
    Isn't that the the usual workflow of security researchers?
• bsuvc 2y ago
  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. 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.
  • paulpauper 2y ago
    That is why a black market exists for this stuff.
    • c0balt 2y ago
      The black market also exists because the potential payout for serious 0days by official programs is almost always less than what a third-party adversary will pay (if the target(s) for them are worth it).
      • omoikane 2y ago
        The price for 0days is highly variable according to this presentation (starting slide 65): https://github.com/mdowd79/presentations/blob/main/bluehat2023-mdowd-final.pdf https://github.com/mdowd79/presentations/blob/main/bluehat20... The same presentation also mentions (starting slide 17) how the requirements of 0days differs from public research, which is why some vulnerabilities would be difficult to sell.
      • eastbound 2y ago
        This. Fortunately the law makes it that it’s inconvenient (possible prison time) to use the black market, which is a big thumb on the balance, but bug bounties are also often only $3000…
        • 2y ago
• ldoughty 2y ago
  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.
  • paulpauper 2y ago
    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.
    • m11a 2y ago
      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.
      • paulpauper 2y ago
        Or just fix the problem and not pay the bounty. Why pay at all if you can find a way not to?
        • m11a 2y ago
          Risk of bad rep when the researcher reports to HN or makes some noise. Then future security researchers don’t try find issues on your platform, and it’s more insecure as a result. For a sensible large company, it’s not worth being stingy over (relative) pennies. They waste money like it’s water. They might as well spend where it matters. Bug bounties won’t even show on their bottom line, but cleanup for an exploited issue will.
• paulpauper 2y ago
  lol $0 Companies cutting corners on security also skimp on paying bounties. No surprise there. The only possible exception are crypto bounties. Those are much bigger and a greater willingness to pay due to the stakes.
• napsterbr 2y ago
  It's unbelievable that he received no bounty from Zendesk on this one. If it was out of scope, then surely he could have published it anywhere?
• yfw 2y ago
  It's owned by private equity. Slowly cutting costs and bleeding the brand dry
  • 8b16380d 2y ago
    I mean, this existed long before acquisition. Maybe the response could have been different in the past, but there is nothing to indicate that would be true.
• maeil 2y ago
  A $1.3 billion revenue company being too tight to pay this after all, even on their 2nd chance, is so short-sighted it's absurd. They're putting out a huge sign saying "When you find a vuln, definitely contact all our clients because we won't be giving you a penny!". 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
  • paulpauper 2y ago
    If the bounty is big enough you basically need to retain a lawyer so the whole thing is done right and prevent being scammed.
    • gavingmiller 2y ago
      zendesk is 6k employees, they have general council on staff
      • genter 2y ago
        I think paulpauper is saying the researcher that finds the vulnerability needs a lawyer.
        • pphysch 2y ago
          I thought the point of bug bounties was to incentivize whitehat behavior, not scare them off with legal BS. Lol.
          • hinkley 2y ago
            Tarpit?
        • paulpauper 2y ago
          correct
• deadliftdouche 2y ago
  Nice writeup and fuck Zendesk, this could have done so much damage.
  • zer0x4d 2y ago
    We don't know if it hasn't to be honest. State actors and exploit sellers could have known about this bug for years and exploited it before it was found by this white hat
• segmondy 2y ago
  Once I started reading the post, I said to myself, Deja vu.
• chc4 2y ago
  Years ago I had a similar train of thought: Zendesk is used by a ton of companies for their support site, and back then HTTPOnly cookies and javascript site isolation were much less of a thing. I found an XSS bug on Zendesk, which also translates into XSS on any site that used it as `support.fortune500.com` subdomain (which was a lot). You could then use it to exploit the main site, either by leaking user cookies or reading CSRF tokens from page contents because it was a subdomain. Zendesk gave me a tshirt but not any money for it. C'est la vie.
  • Thorrez 2y ago
    >reading CSRF tokens from page contents because it was a subdomain. Huh? I don't think you can read page contents unless the origin matches exactly (scheme://host:port).
• sova 2y ago
  Zendesk pay the man. He disclosed only after you waved it off as a nonthreat. Pay. The. Man.
  • Aachen 2y ago
    Not even really 'disclosing' but just reporting to affected parties that they've got a problem That this hurts Zendesk is too bad, it's still the morally correct thing to do and Zendesk probably understands that, too
• RicoElectrico 2y ago
  Based on experience of my friend I am inclined to believe that Zendesk is full of shit. She's had bad experience with their Polish site which she described as cultish employer.
• bsuvc 2y ago
  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/ http://zendeskalternative.com/ While not illegal, it shows the way they think, a sort of manipulative pettiness.
  • josu 2y ago
    I have a similar conspiracy theory for DDG, the rapper. I used to go to DuckDuckGo by typing "ddg" in Google. Now, it's all mentions to DDG the rapper.
    • tiffanyh 2y ago
      https://duck.com https://duck.com works. Ironically, the domain was given to DDG from Google.
      • therein 2y ago
        Here is a gift, let's make your brand less searchable.
      • codetrotter 2y ago
        https://ddg.co https://ddg.co works as well.
    • mkl 2y ago
      ddg.gg will take you straight there and is just as quick to type (of course, it's simpler to set it as default).
    • Elinvynia 2y ago
      To be fair, his name is Darryl Dwayne Granberry
  • realusername 2y ago
    Interesting technique but on my side I see it at the very bottom of the second page of Google so I don't think it's very effective.
• junto 2y ago
  I help corporates evaluate and buy software. Having an ineffective bug bounty program, especially one that rewards black market activity on a terms & conditions technicality like this, is enough for me to put a black mark on your software services. 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.
  • exceptione 2y ago
    Yes, I think bounties in this class and with this impact should at least be six figures. If a company loses 120 million a year to security bounties, they will take into account the cost of scrumming/rapid widget delivery.
  • moritonal 2y ago
    Would love to see the parts of the market where you've marked off every current option, given each would represent new business opportunities.
    • xyst 2y ago
      Probably any SK company. Bounties are awful and only paid out to SK citizens. Everyone else gets a pat on the back for being a sucker.
  • yieldcrv 2y ago
    HackerOne’s mediator dropped the ball here 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
    • richbell 2y ago
• klabb3 2y ago
  I swear I’ve seen this vuln years ago. I thought it was already well known that attacker controlled input for email-bridged ticketing systems means attackers can access at least one @company.com email. 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?
  • mmsc 2y ago
    It's a common thing: https://www.google.com/search?q=slack+google+saml+vulnerability https://www.google.com/search?q=slack+google+saml+vulnerabil...
• gavingmiller 2y ago
  The piece the author is missing, and why zendesk likely ignored this is impact, and it's something I continually see submissions lacking. As a researcher, if you can't demonstrate impact of your vulnerability, then it looks like just another bug. A public program like zendesk is going to be swamped with reports, and they're using hackerone triagers to augment that volume. The triage system reads through a lot of reports - without clear impact, lots of vulnerabilities look like "just another bug". Notice that Zendesk took notice once mondev was able to escalate to an ATO[1]. That's impact, and that gets noticed! [1] https://gist.github.com/hackermondev/68ec8ed145fcee49d2f5e2b9d2cf2e52#aftermath https://gist.github.com/hackermondev/68ec8ed145fcee49d2f5e2b...
  • patcon 2y ago
    Yes. But respectfully (residual frustration at zendesk might make me curt here) if their security triage team can't see how dangerous it is for an attacker to get access to an arbitrary thread on a their CLIENT's corporate email chains (in this world of email logins and SSO), then they have a big lapse in security culture, no? 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.
  • 23B1 2y ago
    "If you won't illustrate the impact of our mistake, we aren't obligated to listen to you" is peak CYA
    • gavingmiller 2y ago
      Not even close to the point I was making: If you want to get taken seriously, write to audience.
      • Aachen 2y ago
        The audience of a security contact point (be that Hackerone or security@') is a technical person 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
• oarla 2y ago
  The worse part:"We kindly request you keep this report between you and Zendesk". After being notified of a problem on their side, them ignoring it, now they want to keep things hush hush? That's exactly what the author did in the first place, but they chose to brush it aside. That itself is highly unprofessional. With such an attitude, I'm not surprised that they did not pay out the bounty.
  • op00to 2y ago
    “I will consider not disclosing if you compensate me for my time.”
    • jjmarr 2y ago
      You can't ask for money in exchange for not revealing a bug. That's blackmail which is illegal and ethically dubious. 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.
      • op00to 2y ago
        Gotcha. The moment you attach a monetary condition it can be seen as extortion. In that case I believe the only responsible thing to do is disclose using customary, reasonable waiting periods.
      • tptacek 2y ago
        I don't think this is true. I'm not a lawyer and this is not legal advice, but I think it's hard to fit the elements of an extortion statute to a "threat" to disclose the results of technical research work you yourself did. Moreover, if a vendor is working with HackerOne, they've already implicitly consented to their norm of non-disclosure in exchange for payment. Further, in something like 15 years of bounty programs, I haven't heard of any cases like this having been filed --- and bounty researchers threaten to publish all the time. I also disagree that there's anything ethically dubious about it.
• kachapopopow 2y ago
  And this is how whitehats get turned into blackhats and just choose to use this information to perform social engineering or exploit devices.
  • kachapopopow 2y ago
    I've seen this go from -2 points to 2 points, now back to 1. Interesting how people are so divided on this when people I've brought up this topic to all agree that good people often get taken advantage off especially in cases like this.
• yapyap 2y ago
  Welp, they’re basically begging people to sell 0 days to a 3 letter agency // out of state groups (NSO, etc) 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
• zx8080 2y ago
  ”Too big to pay.” 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?
• mmsc 2y ago
  From what I can tell, the vulnerability wasn't even fixed: they just.. changed their spam filter? Whatever that means. 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.
  • vitus 2y ago
    Hey, now you have to bypass two spam filters, and also email verification from Apple is now marked as likely-spam. Which addresses the very specific Slack infiltration attack, but doesn't address the underlying issue.
  • layer8 2y ago
    Requiring their customers to implement SPF and DMARC as a hard technical requirement is probably bad for business. And as mentioned in TFA, they do note issues regarding SPF/DMARC in their policy.
    • madisp 2y ago
      I think in this case it's the customers of their customers, e.g. people sending emails to support@acme-corp.com. In that light requiring all emails coming into support@acme-corp.com to have SPF and DMARC is bad for business indeed, not only for Zendesk but probably also for the fictional ACME corp. EDIT: they absolutley should not use an autoincrementing int as a "support-chain token" though, that's a workaround they could easily do.
      • layer8 2y ago
        I’m not clear on that. If the support requestor doesn’t need to be from the company, then I don’t understand why the email sender has to be spoofed in the first place.
        • madisp 2y ago
• tasn 2y ago
  This is clever hack and a reminder of how a chain of smaller security issues (guessable ticket IDs, email spoofing, automatically adding emails to tickets, etc.) can lead to larger ones. 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.
• twoodfin 2y ago
  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 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?
  • tryauuum 2y ago
    I'm not sure (maybe it's the case only with email auth, not oauth). But there's a setting on slack to not automatically allow people with your company email address. So the tools are there to stop the attack
  • autarch 2y ago
    I'm pretty sure you can configure your corporate Slack to only allow authentication providers you choose. So if you have a corporate SSO you can just allow that.
  • kbolino 2y ago
    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 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.
• Kwpolska 2y ago
  > Personally, I’ve always found it surprising that these massive companies, worth billions, rely on third-party tools like Zendesk instead of building their own in-house ticketing systems. 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.
  • npsomaratna 2y ago
    I’d give the author a break-he’s just 15, after all. I was far less savvy at his age.
    • zharknado 2y ago
      Agreed, I smiled a this line. Good reminder that you don’t have to be super experienced to have big insights and impact. And also that being brilliant doesn’t magically correlate with being knowledgeable. https://xkcd.com/1053 https://xkcd.com/1053
• aftbit 2y ago
  Wait... it looks like Zendesk only fixed the issue of Apple account verification emails being added to tickets, not actually the underlying issue? >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?
  • vitus 2y ago
    Yeah. Zendesk only put a bandaid in place to prevent this particular attack vector for the Slack infiltration attack, and did nothing for the initially reported issue.
  • layer8 2y ago
    Only the customer domain owners can fix the underlying issue, which is a missing SPF/DMARC configuration.
    • cjbprime 2y ago
      That doesn't sound right. Aren't these @zendesk.com addresses?
      • layer8 2y ago
        The spoofed addresses were support@company.com, is my understanding. Zendesk is very well aware of SPF/DMARC, from their support pages.
        • Thorrez 2y ago
          The spoofed address was appleid@id.apple.com . support+id@company.com was the to address, not the from address. https://gist.github.com/hackermondev/68ec8ed145fcee49d2f5e2b9d2cf2e52#reproduction-steps-apple---zendesk---slack https://gist.github.com/hackermondev/68ec8ed145fcee49d2f5e2b...
• eatbots 2y ago
  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 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.
  • cxcorp 2y ago
    This is very important to keep in mind when implementing OAuth authentication! Not every SSO provider is the same. Even if the SSO provider tells you that the user's email is X, they might not even have confirmed that email address! Don't trust it and confirm the email yourself!
    • hmottestad 2y ago
      And remember to add a random unique id to the reply-to email, otherwise you’ve fallen into the same trap.
  • harrisonjackson 2y ago
    Ah, that makes a lot of sense. This is a foot gun that you can run into even with an auth provider like Auth0 or Clerk let alone rolling your own. 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.
  • ec109685 2y ago
    Not only is Apple non-directory, they are non-discretionary as well, so foisted on services and handled poorly as a result.
• xyst 2y ago
  Zendesk is a piece of shit company for not paying out this researcher. H1 should restrict ZD from their platform.
• ericbarrett 2y ago
  This was a great writeup, really clear and engagingly written, about an interesting and subtle bug. If the author hadn't mentioned they were 15 I would have assumed it was from a seasoned security professional. To Daniel/hackermondev: whatever you're doing, keep it up!
  • kmoser 2y ago
    Agreed, if I was hiring and the author applied, I would base most of my decision on the quality of this article alone. Just goes to show how engaging communication beats whiteboard interviews, at least for me.
• namaria 2y ago
  The amount of software that could have been some spreadsheets and an email chain and companies pay enormous amounts of money for and create glaring vulnerabilities in their systems is a big reason why I'll never understand or thrive in a corporate setting.
• mgaunard 2y ago
  In my experience, telling people you've found a vulnerability in their system is met with denial or lack of care, and when you demonstrate the exploit for them to take it seriously, they sue you. You're better off not bothering contacting them.
• harrisonjackson 2y ago
  Crazy that a company/product that depends so much on email as an interface would have policies to dismiss a bug like this. 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:
• pheatherlite 2y ago
  And I thought I was once a clever 15 year old... this was brilliant. Sharp kid. Though his pondering of 'why do companies use third party support systems instead of rolling their own' gave his age away :)
• hk-hater420 2y ago
  [flagged]
• wglass 2y ago
  Seems to me this is just as much a problem with Slack and its configuration as with Zendesk.
• 29athrowaway 2y ago
  Why would a security researcher risk doing a significant amount of free work for Zendesk in the future? Why do they even have a bounty program if they do this?
• ec109685 2y ago
  While obviously Zendesk leaving such a huge hole was the main reason for this exploit (you should obviously fail closed when email signals suggest it’s an unauthenticated address), a contributing factor is that Apple forced themselves to be added as an SSO provider. 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?
• yieldcrv 2y ago
  > "out of scope," said no attacker ever I like this kid
• failedrequest 2y ago
  Zendesk handles customer data and says its a great customer support platform. 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.
• bronco21016 2y ago
  You probably didn't speak with a human since Zendesk only allows you to speak to a bot unless you give them several thousand/month.
• deleted 2y ago
  [deleted]
• natch 2y ago
  Unfortunately the headline makes it look like Zendesk paid a bounty, when they did not. Clearly they have a doofus in charge of security.
• lifeisstillgood 2y ago
  I have been thinking about it for a while, but I no longer think email is worth the trouble. I am flooded with spam, the vulnerabilities are everywhere and locking them down near impossible.
• chias 2y ago
  The dumb thing is that this "out of scope" thing is 100% a Hacker One failure, and exactly the kind of thing I've grown to expect from these triage teams. "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.
• josephh 2y ago
  A more sensible thing that should've been done is to tokenize the case ID so that you can't just guess it with a numerical range. Also important that you don't leak your key business metrics (# of support cases over time).
• atum47 2y ago
  I once found a neat trick to highjack Facebook accounts; after MSN message died a lot of hotmail accounts were left to die also but a lot of people created their Facebook account using the @hotmail address. I tipped them about that they basically said F you.
• brainzap 2y ago
  when I tested zendesk for potential ticket system I felt that this is half abandoned, there are probably more security issues to find
• nodamage 2y ago
  In 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: 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.)
  • kidbomb 2y ago
    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
    • robbiet480 2y ago
      Those with Apple Business or School Manager can now claim domain names which blocks sign ups under claimed domain names.
    • nodamage 2y ago
      Apparently so do Google and Github according to the other comments in this thread. Seems like a potential design flaw in these SSO implementations.
• Rugu16 2y ago
  Its all because someone’s ego was hurt that their security was breached by 15 year old kid. Sometimes the simplest explanation is the right one.
• Eumenes 2y ago
  Zendesk paid me $500 4 years after I submitted a vulnerability to their bounty program on hackerone. It was a shock. There were default settings indexing internal docs/knowledgebase info to search engines.
• wslh 2y ago
  This is where despite the bug bounty rules someone at Zendesk (a CXO?) should take action and pay. I would add that HackerOne could also take an action and influence in the positive outcome and not being just a MiM.
• tptacek 2y ago
  If you want to understand the dynamics of what happened here, a very important detail is that the bounty hunter's report implicated DKIM and SPF, and no bug bounty program in the world takes DKIM reports seriously. DKIM is the archetypical beg bounty. You could find DKIM RCE and HackerOne would still round file your report.
• heraldgeezer 2y ago
  >Personally, I’ve always found it surprising that these massive companies, worth billions, rely on third-party tools like Zendesk instead of building their own in-house ticketing systems. 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?
  • lukeh 2y ago
    As someone else mentioned, he is 15. I would have thought the same thing when I was his age.
    • heraldgeezer 2y ago
      When I was 15 I was jerking off and playing Flyff, not thinking about ticket systems.
• matrix12 2y ago
  I blame @otterly for bringing in the ex yahoo people who locked devs out environments. Causing them to add backdoors for debugging.
• heraldgeezer 2y ago
  Would this work with Jira, Servicenow, Spiceworks etc...? :x hehe
• ZendeskTeam 2y ago
  Our team at Zendesk has posted some more details about this bug here: https://support.zendesk.com/hc/en-us/articles/8187090244506-Email-user-verification-bug-bounty-report-retrospective https://support.zendesk.com/hc/en-us/articles/8187090244506-...
  • bredren 2y ago
    > We also want to address the Bug Bounty program associated with this case. 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. 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?
  • whatthefk 2y ago
    1. "While this specific issue has been resolved", that was a bug, not an issue. 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.
  • austinkhale 2y ago
    Wild response. It appears you did not learn a single lesson through this process.
  • rendall 2y ago
    > ...they violated key ethical principles by directly contacting third parties about their report prior to remediation 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.
• jazz9k 2y ago
  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.
  • hmottestad 2y ago
    Would love to hear more! I’m always eager to add companies to my blacklist.
  • tgsovlerkhgsel 2y ago
    Same experience where I reported a bug, the company ghosted me, and H1 did not even allow disclosure through their platform. 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).
    • rendall 2y ago
      I wonder what would happen if researchers en masse were to boycott a particular platform? Disclose to the companies directly and explain they won't work with X and why. Treat any attempt by the company to kick the disclosure back to platform X as a non-response.
  • jokethrowaway 2y ago
    Name and shame the companies
• farmeroy 2y ago
  I've really enjoyed all reading about all the vulnerability blogs posted over the last month! And from so many young researchers, it's super inspiring
• joshdavham 2y ago
  Slightly off topic, but why does it always seem to be teenagers who are the most talented at finding exploits?
  • tgsovlerkhgsel 2y ago
    Curiosity and near endless time to dedicate to it make for a powerful combination.
    • joshdavham 2y ago
      Beautifully said.
  • yelnatz 2y ago
    Kids who are smart and curious have already been exposed to the internet since they were 8/9 years old. So a few years of learning they're already knowledgeable by the time they're in their teens. 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.
• vladmk 2y ago
  SMH and Zendesk responds the wrong way on his post. Guys, just pay the kid instead you're making business owners like me start recommending my friends and clients against using Zendesk...
• rickmorton3 2y ago
  [flagged]
• vednig 2y ago
  It should be a standard to make bugs public or disclosed to the affected companies atleast a while after it's discovery so at least the companies which are connected to each other can implement their own fix,other wise having closed deals with security researchers behind doors and asking them not to reveal the truth, isn't going to prevent bad actors from using the vulnerability. It is times like these we should reconsider our standard in terms of web security as a whole.
• larkinrichards 2y ago
  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 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."
  • Ylpertnodi 2y ago
    >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.
• deleted 2y ago
  [deleted]
• valiant-comma 2y ago
  Looks similar in concept to this finding from 2017: https://medium.com/intigriti/how-i-hacked-hundreds-of-companies-through-their-helpdesk-b7680ddc2d4c https://medium.com/intigriti/how-i-hacked-hundreds-of-compan...
  • BehindTheMath 2y ago
    It's linked in the post.
    • valiant-comma 2y ago
      Ahh, I did read the post but missed seeing the link!
• rthtrjtyjt 2y ago
  There are countless stories of companies finding ways to not pay bug bounties. At least the black hats get their cut.
• kidbomb 2y ago
  "Create an Apple account with support@company.com email" 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.
• Fokamul 2y ago
  Big surprise that companies which outsource everything to India and other countries are hacked. No, not really. GL HF
• danpalmer 2y ago
  This matches my experience with Zendesk. We did an integration at my previous company and they were incredibly naive with respect to email setup. We had quite strict requirements around deliverability in particular, and having the Zendesk setup play nicely with our email domain setup that was tuned for deliverability. Sadly Zendesk were unable to engage with the issue beyond "just forward emails from your gmail support inbox" which was a long way behind where we were. For a company built on email, they're not good at it.
• nixpulvis 2y ago
  My first thought (which is somewhat self-serving because I hate 3rd party sign on) is that this is a great case study for having only one method of sign-in.
• dools 2y ago
  How's that "please keep this between us" request working out for them? 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.
• hedora 2y ago
  Wait. Did zendesk actually fix the issue, or did they just blacklist a few senders and decide to continue to rely on third party spam filters to save them?
• csomar 2y ago
  You are a sucker if you are using a platform like HackerOne. I reported a bug (Crypto Exchange, Bitmex) 5 years ago. It was not a critical bug, but still. The team kept the bug report open for 5 years; I assume so that it doesn't affect their payout score. They recognized the bug. After 5 years they closed it. Zero communication. 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.
• system2 2y ago
  Guess who is going to tell all of his clients about this. Me. I hate corporates pulling this type of crap.
• arendtio 2y ago
  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.
• deepsun 2y ago
  I heard that Zendesk Security team force your _root_ domain to allow their SSL certificates to be issued, per CAA dna record. 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.
• smithstreet 2y ago
  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.
• cruffle_duffle 2y ago
  > Personally, I’ve always found it surprising that these massive companies, worth billions, rely on third-party tools like Zendesk instead of building their own in-house ticketing systems. 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?
• Upright8905 2y ago
  I think that the recent third hack of Internet Archive that used the Zendesk ticketing system might have used this bug? Crazy to think about...