Hacker News Reader

Comment by madisp | Hacker News Reader

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.

View on HN

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

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

Reply on news.ycombinator.com