Resources

People often ask me "How did you learn how to hack?" The answer: by reading. This page is a collection of the blog posts and other articles that I have accumulated over the years of my journey. Enjoy!

Zendesk is a customer service tool. To setup, you link it to your company's customer support email, such as support@company.com. Now, Zendesk will manage all incoming emails and create tickets for you.

When an email is sent to the company's Zendesk support email, a new ticket is created. To keep track of the thread, an automatic reply-to address is created with support+id{id}@company.com where {id} is the ticket number. Zendesk has ticket collaboration that lets you CC someone on email replies. The author found a really bad bug in this.

Zendesk did not protect against email spoofing on the collaboration feature! This meant that an attacker could impersonate the original sender to tag their own email to the ticket. Now, all of the ticket information would be readable by the attacker. Ticket IDs are also sequential, making it easy to guess.

When reported, both HackerOne and Zendesk claimed this fell "out of scope" because of a clause saying that "SPF,DKIM and DMARC issues are out of scope". Instead of just popping a single company with this over and over again, they decided to escalate this. In a previous blog post from 2017, the author used Zendesk to login to private Slack workspaces by bypassing the verification process for emails using the support email. They wanted to reproduce this.

Slack had added a protection to prevent these types of attacks since then: a random blob in the no-reply. Since the exploit required knowing this, it wouldn't be possible. Since this protection was added to Slack, it was NOT added to their other OAuth options of Google and Apple!

The flow for exploit was as follows:

1. Create an Apple account with support@company.com as the email to request a verification code.
2. Apple sends the verification code to Zendesk, which automatically creates the ticket.
3. Use the email spoofing bug to add yourself to the ticket created for the Apple email verification.
4. Login to the support Portal for the CCed account. This has the code in it now.
5. Enter the verification code in Apple to confirm the address.
6. Use Slacks "Login with Apple" feature from your new company email.

The author of this reported the vulnerability to a lot of Fortune 500 companies. They got 50K in bug bounties from these companies but Zendesk wasn't happy. The kid (he's 15) didn't show the Slack privilege escalation technique to them, which escalated the privileges dramatically. Finally, two month after submission, Zendesk fixed the issue but claimed that email flagging would have caught this in their internal systems. Because he broke the HackerOne disclosure guidelines, he got no bounty from them.

Personally, I don't think this was handled properly on either side. Attackers don't care about scope - they care about impact. So, Zendesk should have dealt with this imo. Daniel also didn't show HackerOne the Slack privilege escalation but Zendesk may not have cared even if he did. They only cared once the customers complained. Feels like a damned if you do and damned if you don't situation.

Regardless, a simple vulnerability and an amazingly creative privilege escalation alongside drama on the bug reporting made this an awesome read. They sum up the experience best at the end "that's the reality of bug hunting—sometimes you win, sometimes you don't."