← Back to context

Comment by aftbit

4 months ago

Wait... it looks like Zendesk only fixed the issue of Apple account verification emails being added to tickets, not actually the underlying issue?

>In addition to this, we also implemented filters to automatically suspend the following classes of emails: User verification emails sent by Apple based on the Reply-To and Message-Id header values Non-transactional emails from from googleworkspace-noreply@google.com Over the coming months, we will continue to look into opportunities to strengthen our Sender Authentication functionality and provide customers with more gradual and advanced security controls over the types of emails that get suspended or rejected.

So is it still possible to hijack anyone's support tickets using the default configuration of Zendesk if you just happen to know their email and ticket ID?

Yeah. Zendesk only put a bandaid in place to prevent this particular attack vector for the Slack infiltration attack, and did nothing for the initially reported issue.

Only the customer domain owners can fix the underlying issue, which is a missing SPF/DMARC configuration.

  • They could make the ticket IDs unpredictable so you can't subscribe yourself to any existing ticket by sending it an email

  • Zendesk could refuse to allow "ticket collaboration" if customers had a missing or insufficiently secure SPF/DMARC configuration, or at least make customers check a box that says "Tickets may leak their contents to anyone who can send emails".

  • That doesn't sound right. Aren't these @zendesk.com addresses?

    • No, it's spoofed appleid@id.apple.com addresses. But you are correct that it's not customer SPF/DMARC configuration that's the problem.

    • The spoofed addresses were support@company.com, is my understanding.

      Zendesk is very well aware of SPF/DMARC, from their support pages.

      1 reply →