Several concerned users have reached out to me with questions about the so-called Ticket Trick Hack discovered by a hacker named Inti De Ceukelaire. You can read the original article at Free Code Camp as well as additional details on The Next Web.
The vulnerability that Inti found could give potential hackers access to company intranets, social media accounts, and most commonly Yammer and Slack teams by exploiting the way some online based help desk software is set up.
Our IT Managers have been closely following all new developments about this vulnerability that can affect any professional services automation software, while also working to make sure that SherpaDesk isn't vulnerable from a technical perspective.
Unfortunately, like most successful hacks, it only relies partially on IT issues, and exploits what IT managers have less control over: The human factor.
In this case, the human factor involves using email in ways that violate common assumptions, like the practice of using your company’s main domain to create an easily guessed email address on your online based help desk software.Email addresses like support@company.com, or feedback@company.com are particularly vulnerable because hackers don’t even have to guess them because they're already being used in your company’s automated reply emails.
So how does this hack work?
As explained earlier, many large companies use Support@YourCompany.com as an email address that allows their employees to email directly for IT support. When a Support@YourCompany.com email address receives an email, it takes the From: part of the email, matches it to any existing user account, and files a ticket under that user. This is fairly standard in the online Help Desk industry.
Some websites also let you see your ticket queue without having to verify your email address (i.e. they don’t use two Factor Authentication, or the standard “click here to confirm your email address” that you get when you sign up for an account). All an attacker has to do at this point is to understand what service accounts a 3rd party system sends verifications links on (i.e. feedback@slack.com) and then create an account on the target company’s integrated support site with that known verification email address. They then go to Slack, and ask Slack to send a verification link to Support@YourCompany.com. The help desk matches the email it gets from Slack to feedback@slack.com's account, which the attacker controls. The attacker then accesses the verification link through the help desk. Of course this does leave an extremely obvious trail, but by then the attacker has already gained access to the company's internal Slack channel, and extracted any secrets found on internal public channels.
We’re using Slack here as an example, but most team collaboration software is vulnerable, including Yammer and Facebook workplace (or at least they were until this hack became public).
This is not a straightforward or easy patch to implement because it exposes a vulnerability in the way organizations use service email accounts and how 3rd party systems handle verification for new accounts. This is the proverbial human factor I referred to earlier.
Here are some things you should look into today to help mitigate any exposure:
Check to see if your organization's internal communication boards allows you to set new accounts to ‘Invite Only’. This will stop the free registration process and will require a human to specifically invite someone to your boards
Check to see if the invite process of your internal communication boards sends out randomized emails for verification vs a generic standard email address like ‘no-reply@company.com’. If you’re still using an easily guessable generic email address, make sure you switch to randomly generated tokens ones ASAP. This makes it very difficult for anyone to guess these. Example: 84y630ahfr82@YourCompany.com.
Once a hacker has gotten inside your internal communications there are still things you can do to limit your exposure. For example, don’t post sensitive subjects like passwords on public forums. Know who is all active in a chat. Be diligent on who and what you discuss on any communication thread. This is the last line of defense and should be an integral part of your company’s culture.
Service accounts that are typically used (i.e. info@MyCompany.com, no-reply@MyCompany.com, support@mycompany.com, help@MyCompany.com, etc) are easy to guess or detect in order to be used in 3rd party registrations because they contain your domain name. It’s suggested that you use an email address that are not fully domain or used a subdomain for service accounts (ie. @mail-MyCompany.com, @reply-MyCompany.com) as these won’t be accepted in 3rd party registrations. PRO-TIP: Never, ever use these service accounts to also set up any 3rd party services.
By tricking help desk systems to act like an accomplice, these hackers can now gain access to 3rd party solutions like Slack and Yammer. This is mainly due to the fact that most help desk systems also work as an email exchange platform. We’re working on upgrading our user registrations to more advanced verifications. We’re currently working on requiring email verification for all new account registrations from portal sign ups to new email creation. We’re also looking into requiring verification for email changes on existing accounts. As expected, when the level of security goes up, ease of use and accessibility goes down. Such is the world we live
in :(.
This is just our first pass on this, but we wanted to get the information out to you our customers. We will be providing further updates as we are able to get more information and additional updates out on our platform. We also want to hear from you, our user, on how you are treating your email security for internal teams and what we can do to help you. What to keep up with the latest developments in SherpaDesk's professional services automation and how we can help your business grow?