Comment by mmsc
4 months ago
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.
5 replies →