Comment by nodamage
4 months ago
In case it's not clear these are the two separate vulnerabilities:
1. Zendesk allows you to add a CC to any existing support ticket by sending a (spoofed) reply from the original requestor's email address to that ticket's Reply-To address and including a CC in the email.
In some circumstances the Reply-To address is based on an auto-incrementing integer so it can be guessed. (Although this may not alway be the case: my email archives show some emails from Zendesk using the integer and other emails using a random alphanumeric string. It seems to vary by company so it might be some sort of configuration setting?)
2. Slack allows third-party domain-wide logins via Sign in with Apple without additional verification that the email belongs to a real person. Here the author of the article pretends to be support@company.com to Slack and Slack lets them into the company.com channel, despite the fact that support@company.com does not actually represent a real user and is only intended to be a receiving email address that forwards into Zendesk. (This sounds more like a configuration problem than anything else though.)
IMHO the second problem goes deeper:
Sign In with Apple is allowing you to "create an account"(author's words) on @company.com, which should not be supported in the firat place. Instead, it should rely in a central directory controlled by company.com for authentication
Apparently so do Google and Github according to the other comments in this thread. Seems like a potential design flaw in these SSO implementations.
Those with Apple Business or School Manager can now claim domain names which blocks sign ups under claimed domain names.