I used to do this trick to get facebook accounts back when they required a .edu email address. I'd just find some abandoned mailing list under the .edu of my choice, join the mailing list, then use the list's address to create a facebook account. After that I could change the primary email address to whatever I wanted and still view profiles for anyone at the target school.
This confused me initially. Basically, he signs up to Company (not Slack) as noreply@slack.com. Then he creates an account at Slack as support@company.com. Slack sends an email FROM noreply@slack.com to support@company.com. The email gets taken by the helpdesk and detects there is a user called 'noreply@slack.com'. Although this email was not verified, the ticket becomes viewable in the helpdesk.
And, as I understood it, he was able to read arbitrary emails sent to support@ by getting access to their ticketing system instances just like he got access to Slack.
He doesn't say so explicitly, but presumably he did the same thing with ZenDesk as he did with Slack - he signed up for ZenDesk with support@target-company.com and then the target company's service with, say, no-reply@zendesk.com. And then once he had access to their ZenDesk instance he could read all emails sent to support@target-company.com, which opened up all kinds of doors.
No, he can't read arbitrary emails in Zendesk. What he did is simple yet difficult to explain. He covers it in "METHOD #2 — THE SUPPORT DESK"
He signed up to a target company's Zendesk as feedback@slack.com. This is the email address Slack sends email from. He could do this because Zendesk doesn't require email verification.
Then he signed up to Slack using support@target-company.com. This is the email address the target company uses to open cases in Zendesk.
ASo since Slack send the account confirmation links from feedback@slack.com to support@target-company.com, he could see them and login to the target company's Slack.
I don't think that's quite right. How does signing up for Zendesk using feedback@slack.com give him access to the target company's Zendesk instance? He can't read emails sent to feedback@slack.com. The auto-add-to-organization logic in these systems goes by domain so he needs to sign up for Zendesk using a @target-company.com email address, so that he'll be granted access.
He clearly describes how he got access to their Slack instance, which required finding a way to receive an email at a @target-company.com email address. He did this by signing up for the target company's service using feedback@slack.com, in order to trick the company's support desk software into making the email from feedback@slack.com visible to him in the customer-facing support portal. The target company's helpdesk software thought the email confirming ownership of support@target-company.com was from the new user who just signed up with feedback@slack.com, so it made it visible to him in the user-facing support portal as a ticket he had opened. That let him access their Slack instance.
The question was: how was he able to read tickets created when an email was sent to support@target-company.com, such as a password reset email from Twitter. Just joining the company's Slack instance wouldn't let him read emails sent to support@target-company.com. And he says he was able to do that by getting access to their Zendesk instance.
Presumably he used the same process, but substituting ZenDesk for Slack. Or else he used a different method that he doesn't describe.
Support emails sent to Zendesk/etc allow a user to see the originating support email as well as the company's response to that email via their online support interface.
I look at all the energy going into ridiculous password requirements and super esoterica attach vectors and of course the real compromises are in plain sight.
This is what bothers me about stupid password requirements that create massive user friction because we'll never remember the password. Passwords aren't guessed or brute forced 99% of the time. They are stolen or phished or access is gained in another manner.
You’re right that passwords aren’t BFd often and that phishing is by far the easiest way.
Regarding other methods: passwords are however, guessed, or stolen. If a hacker can grab the app databases store of passwords, they can preform offline cracking and quickly start getting into accounts that have matching hashes to commonly used passwords. All it takes is a few accounts and you can usually pivot around from there to get some more privileged access.
Wonder if you could download a 'hash' or encrypted version of your password and then websites as for that file instead? Then you can just direct it to it. I have no clue about how this would work just brainstorming.
I'd be interested in a follow-up to see how many companies have made the effort in the past year to address this. I suspect not as many as one would hope.
From what I understood you can sign-up at zendesk with any email like ooga-booga@gitlab.com and if someone sends an email to that address the email starts showing up in the support software even before you verify your support desk account (probably because the company has configured the MX records to send all email to zendesk, etc).
So now that you are effectively able to read emails sent to arbitrary address at the company's domain, you now get access to SSO links, etc sent on it too. Is this what the hack is?
I was fully expecting this to be yet another blog post about a fairly mundane technique, but this was actually rather clever. It's also now something I'm going to double check at work on Monday to make sure we're not vulnerable.
