[madisp]

I think in this case it's the customers of their customers, e.g. people sending emails to [e-mail]. In that light requiring all emails coming into [e-mail] to have SPF and DMARC is bad for business indeed, not only for Zendesk but probably also for the fictional ACME corp.

EDIT: they absolutley should not use an autoincrementing int as a "support-chain token" though, that's a workaround they could easily do.

[nodamage]

> EDIT: they absolutley should not use an autoincrementing int as a "support-chain token" though, that's a workaround they could easily do.

I checked my email archives and some (but not all) of the emails I've received from Zendesk have arbitrary alphanumeric ids in the Reply-To header instead of integers. Seems to depend on the company, perhaps this is a configuration issue?

[layer8]

I’m not clear on that. If the support requestor doesn’t need to be from the company, then I don’t understand why the email sender has to be spoofed in the first place.

[ec109685]

The attack requires getting yourself CC’d on a support ticket. In this case to show how bad that is, it was a support ticket that had an oauth ticket to log into slack as “[e-mail]”.

[layer8]

From the description, sending an email to [e-mail] creates a support ticket, to which you can later latch on by adding a Cc. My understandig is that, at least in order to get the full history of a ticket, including any other emails sent to support-$[e-mail], the primary sender needs to be from the company as well. Otherwise, why would you need the Cc hack?

[nodamage]

The email sender needs to be spoofed in order to add the CC.

1. Apple sends a legitimate email with a verification code from [e-mail] to [e-mail], creating a ticket in Zendesk.

2. The attacker then sends an email to support-$[e-mail] from [e-mail] (spoofed), attaching their own email address in the CC field.

3. Since the attacker is now CC'ed they can read the entire history of the ticket including the legitimate email Apple sent in (1) containing the verification code.

4. Now that the attacker has verified ownership of the Apple ID with the email address [e-mail] they can use that Apple ID to login to any service that grants domain-based access via Sign in With Apple, such as Slack.

[qilo]

My understanding is that, the original sender (spoofed apple in this case) can send the reply to support-$ticket-$id@ with CC field to grant full access to the thread for CC'ed email.

[madisp]

oh, I think you're right! my bad.