From what I can tell, the vulnerability wasn't even fixed: they just.. changed their spam filter? Whatever that means.
So for this to work still, you need to bypass a spam filter.
They should just force DMARC and SPF like Google has done, and say "your fault if you misconfigure". Also default-off for the CC thing would be a good idea, too, with a warning of what could happen if they turn it on. Alternatively making a non-guessable id for the email.
Hey, now you have to bypass two spam filters, and also email verification from Apple is now marked as likely-spam. Which addresses the very specific Slack infiltration attack, but doesn't address the underlying issue.
Requiring their customers to implement SPF and DMARC as a hard technical requirement is probably bad for business. And as mentioned in TFA, they do note issues regarding SPF/DMARC in their policy.
I think in this case it's the customers of their customers, e.g. people sending emails to support@acme-corp.com. In that light requiring all emails coming into support@acme-corp.com 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.
> 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?
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.
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 “support@company.com”.
From the description, sending an email to support@company.com 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-$ticket-ID@company.com, the primary sender needs to be from the company as well. Otherwise, why would you need the Cc hack?
The email sender needs to be spoofed in order to add the CC.
1. Apple sends a legitimate email with a verification code from appleid@id.apple.com to support@company.com, creating a ticket in Zendesk.
2. The attacker then sends an email to support-$ticket-ID@company.com from appleid@id.apple.com (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 support@company.com they can use that Apple ID to login to any service that grants domain-based access via Sign in With Apple, such as Slack.
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.
So for this to work still, you need to bypass a spam filter.
They should just force DMARC and SPF like Google has done, and say "your fault if you misconfigure". Also default-off for the CC thing would be a good idea, too, with a warning of what could happen if they turn it on. Alternatively making a non-guessable id for the email.