4 ms·

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

by aftbit 2y 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?

vitus 2y ago
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.
layer8 2y ago
Only the customer domain owners can fix the underlying issue, which is a missing SPF/DMARC configuration.
- cjbprime 2y ago
  That doesn't sound right. Aren't these @zendesk.com addresses?
  - layer8 2y ago
    The spoofed addresses were support@company.com, is my understanding. Zendesk is very well aware of SPF/DMARC, from their support pages.
    - Thorrez 2y ago
      The spoofed address was appleid@id.apple.com . support+id@company.com was the to address, not the from address. https://gist.github.com/hackermondev/68ec8ed145fcee49d2f5e2b9d2cf2e52#reproduction-steps-apple---zendesk---slack https://gist.github.com/hackermondev/68ec8ed145fcee49d2f5e2b...
  - Thorrez 2y ago
    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.
- Aachen 2y ago
  They could make the ticket IDs unpredictable so you can't subscribe yourself to any existing ticket by sending it an email
- aftbit 2y ago
  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".
deleted 2y ago
[deleted]

by aftbit 2y ago

vitus 2y ago

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.

layer8 2y ago

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

cjbprime 2y ago
That doesn't sound right. Aren't these @zendesk.com addresses?
- layer8 2y ago
  The spoofed addresses were support@company.com, is my understanding. Zendesk is very well aware of SPF/DMARC, from their support pages.
  - Thorrez 2y ago
    The spoofed address was appleid@id.apple.com . support+id@company.com was the to address, not the from address. https://gist.github.com/hackermondev/68ec8ed145fcee49d2f5e2b9d2cf2e52#reproduction-steps-apple---zendesk---slack https://gist.github.com/hackermondev/68ec8ed145fcee49d2f5e2b...
- Thorrez 2y ago
  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.
Aachen 2y ago
They could make the ticket IDs unpredictable so you can't subscribe yourself to any existing ticket by sending it an email
aftbit 2y ago
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".

deleted 2y ago

[deleted]