A recent public announcement by Inti De Ceukelaire (@securinti) shed some light on an exploit that he has been able to use on multiple websites. He has named this exploit “Ticket trick helpdesk hacking”.
Introduction
You could be forgiven for thinking that this exploit resulted from some typical social engineering. Indeed, that was my first impression when this article was first published.
You may have noticed that when you raise issues with companies using an online system you will receive an email from the ticketing system which has a @company.com address. If you look even more closely you may notice that before the @ symbol you will find some subject information (or not) and a random token.
The purpose of these email addresses are to allow you to interact with your ticket via email so you don’t have to go to company.com’s website, navigate to the ticketing system and check on the status or even reply.
Enumeration
Many web services have sprung up that offer commercial services to companies and organisations. To help minimise the administration overhead they allow a user to signup to commercial services of their company by using an email address @company.com.
I think you can clearly see where this headed!
Exploit
- Go to company.com’s ticketing system and enter a new ticket.
- Receive an email from company.com’s in the form
@company.com - Find a service online that company.com uses. Like GitHub, Yammer or Slack.
- Try to join company.com’s team. You will be asked for an email address at company.com
- Paste in the email address
@company.com . - Visit the issue tracker and a confirmation email should have been appended to the issue.
- Click the verification link and you’re in.
Further exploitation of help desks
So, things don’t stop there. There are many help desk portals like ZenDesk, Kayako, etc. Some of these do not require any email verification when setting up a new account. Hmmm.
Exploit 2
- Create an account at company.com using an email address at service.com. We will use the email address @service.com that sends out verification links. This might look like feedback@service.com.
- We find the one of company.com’s commercial instances at service.com.
- We create an account at service.com with the support email of company.com; something like support@company.com.
- Now feedback@service.com sends an email to support@company.com.
- If you are still awake you will realise we can login to company.com using our account feedback@service.com and we will see tickets. One of which will be our verification email. Click the link to verify.
- You have now joined company.com team on service.com.
Surface area
There implications for infiltration of private teams is very significant. Many email addresses are used by companies that could be registered in the same way; think no-reply@company.com where you could intercept password reset emails, or payment@company.com to see payment details, or ebilling@company.com to see invoices.
There are many, many, vulnerable applications and processes that are exploitable right now. Bug bounties were awarded to Inti but we see this as an issue that will remain pervasive in the short term.
Am I vulnerable?
Are all of the following true?
- Support tickets are created by email.
- Support tickets are viewable by unverified email addresses.
OR
- Public issue trackers which use unique email addresses to post information to an issue, forum, messaging service, or user account.
If you fall into the category below then have a look below or (contact us)[/contact/]
Mitigation
- Use a seperate domain for automated emails; support.company.com, reply.company.com, mail.company.com.
- Add random tokens to outgoing mail; e.g. no-reply+cmFuZG9tIGl0IGlzIG5vdCB3ZWxsIGRvbmU@mail.company.com