Attack on Zendesk

The first time I heard about this attack I was told that it’s a slack takeover via a bug in Zendesk. That Zendesk failed to reward this “bug” the bounty but the other company did pay the person 50K bucks. After a few days I saw the description of the attack itself. It turned out that nobody paid 50K to the author. And it also became clear that Zendesk was not aware of the final attack at all. Some other things didn’t add up. The main thing that stood out was that there was no demonstration of actual slack takeover. Just stating that there was one. Which wouldn’t mean that there was no takeover. Just no proofs were presented.

That’s it. Unlike the original attack that the author took the inspiration from, there were no screenshots provided that would prove that indeed he was able to obtain the access to the company’s slack.

Which seems a bit confusing. The impact was not clearly stated. Responsibilities of each step weren’t properly described. All blame was put on Zendesk. And Zendesk was never presented with this attack. But I’ll get to this later.

First let’s try to understand what exactly functionality of what applications allowed him to do that. And let’s understand where that “single bug” is responsible for all of that.

First of all the author creates an apple id as support@company.com. Why would he need to do this? Upon registration on apple.com they would send an email to the email address that you’ve entered in order to verify if you are in control of the provided mailbox. Since the email has been sent to the email that was integrated with Zendesk a new support ticket was created. That contains a security code that apple sent in order to verify mailbox ownership. This Zendesk functionality works as expected. It’s also hard to blame apple for allowing such apple ids.

As the second step the author sends spoofed emails allegedly from `appleid@id.apple.com` . The goal of this step is to see the ticket that was created in the previous step in order to obtain verification code. The author didn’t demonstrate how many tickets he got access to. But he showed a screenshot of a ticket with the code from apple. Since the email was matching. That’s how he confirmed his email to apple. Not clear if he had access to other tickets. Maybe he did but he didn’t show it.

Lastly he stated that he logged into the company’s Slack but provides no screenshots or any other proofs to have access to anything company specific. So the impact that is proven is just one ticket that he knew the email for.

From everything stated from above we definitely can say that the author was able to register malicious apple id thankfully to the specifics of both apple id and Zendesk functionality.

I was puzzled with the amount of hate Zendesk received. And this was main motivation to write this post. As the author stated he did not present this attack to Zendesk at all. We don’t know what was his original report. The only thing what we know about the original impact is this:

The author unfortunately decided not to demonstrate the impact to Zendesk. But he presented it like Zendesk decided not to pay for this particular attack.

There are more people who claimed they did report this but they correctly don’t treat it as solely Zendesk bug.

While I definitely agree that the author’s ingenuity deserves to be acknowledged. His unethical behavior deserves acknowledgement as well.

He had to present this attack to Zendesk. We don’t know at this point if they would reward it or not. Since they had no idea about the impact described in the article. And we don’t know how exactly the author described the impact in the original ticket. If one chooses the path of truth they have to be ready to face obstacles.

Author presents it as a single bug however he uses other systems. Particularly the main piece here is apple id that allows support@company.com as apple id(but also it works as expected) . Which laready means that the bug wasn’t single.

Another issue is how slack handles external SSO. Again we didn’t see what exactly he got access to. Just taking his words for granted. Why would slack allow anyone with an apple id to join an internal company workspace is also not clear. And if it does is it a zendesk or slack issue? Or apple? Why does all blame goes to Zendesk if if was only a part of the puzzle? Spreading the info that it’s all Zendesk bug to it’s customers while Zendesk had no clue about the impact, and while it wasn’t the only appliaction that was featured is extremely unethical.

The attack utilizes 3 systems, maybe some configuration options as well. Remove one from the equation and you’ll get nothing. That’s why all the pieces equally matter. And that’s why it’s not a single bug.

As a conclusion I want to mention that the author’s claims regarding his age meet some contradictory data. For example that he created twitter account at the age of 8:

And that he started his bug hunt at the age of 12

But I’m an early millennial. And had my first computer at the age of 20. On the other hand, my exes kid was playing angry birds on his tablet around the time the author registered twitter. So not sure about that. Not excluding anything however.

Again “slack takeover” wasn’t demonstrated. We didn’t see more than one Zendesk ticket “takeover”. Because the author knew who’ll be the sender. So in the end the impact is not clear. Taking into account that he got ~ 50K of bounties in total for reporting to several hundreds of companies we can conclude that he got several hundred bucks as an avg bounty for this. That would give us an idea about a true impact.

In the end I want to finish with this. How it was amusing to the author that he did not report the exploit to the company he was pointing as the root cause of the problem to its own customers. Everyone has their own definition of ethics. I personally find such behavior disgraceful. (You might disagree) That would be extremely beneficial for the author if he’d indeed was 15. That would give the only rational explanation for the misconduct he committed.