September 27, 2017 at 15:17Ticket Trick: Hacking Hundreds of Companies Through User Support Services
- Transfer
A vulnerability was discovered a few months ago that could allow hackers to crack corporate messaging tools. To exploit this vulnerability is not more difficult than to click the mouse a couple of times; if it is successfully used, you can access the company's internal network, its employees' accounts on social networks such as Twitter, and, usually, the teams in Yammer and Slack.
I came up with a name and logo for my find. Take it for granted.
The issue in question still exists. This is not the case when everything can be instantly put in order. Over the past few months, I have contacted dozens of companies and vulnerable service providers, as part of their bug-trapping programs, in order to remedy the situation. Due to the huge number of organizations to which this applies, I am not able to contact everyone. Following the recommendations of some of the people I respect and with the permission of the organizations affected by the problem, I publish this material so that everyone concerned can take action immediately. Now I will talk about what I called Ticket Trick.
Popular business communication platforms, such as Slack, Yammer, and Facebook Workplace, require company employees to sign up using corporate mailboxes. As soon as the employee clicks on the link to confirm the address sent to his work mail, he will be able to join the group of the company in the service and gain access to internal communication with other members of the group.
Slack: users whose mailbox is open on the same corporate domain can, by default, join the team. This can be replaced with SSO or set to connection mode by invitation only
Yammer: anyone with a corporate mailbox can join the company team
Facebook Workplace: Anyone with a corporate email account can join the team.
I started research with GitLab. Anyone with a live email account at @ gitlab.com can join their team at Slack.
Connecting to the GitLab team in Slack
At the same time, GitLab offers the ability to create error messages by sending them ... to a unique address created on @ gitlab.com. See where everything is going?
GitLab is one of many error tracking systems that provides the ability to generate error messages via email.
For the sake of interest, I tried to join their team on Slack using the email address provided to me to generate error messages.
Registration at gitlab.slack.com
Immediately after registration, I updated my list of hits, and saw that a confirmation letter was added to my project, in the form of a new error message.
Confirmation email
The error message just added contained a “magic link” needed to connect to the GitLab Slack command:
A letter with a link to confirm the address
I clicked on the link in order to see if it worked. She worked. I was offered a list of channels that I can join. I immediately deleted the account and reported the problem to GitLab.
Edited screenshot with a list of channels
The GitLab team replied to my message the same Sunday evening when I sent it to them.
Response to the vulnerability message
They immediately changed the connection mode to their team on Slack, making it possible to connect only by invitation. In addition, they took additional measures in order to inform their customers about the dangers of such functionality.
Not many websites have a public bug tracker, so I decided to dig deeper in order to find out if there is some more common attack vector. As it turned out - it exists, and it occurs much more often than I could expect: this is a customer support service.
Emails sent to [email protected] are sometimes found on online support portals, such as Zendesk, Kayako, (Fresh) Desk, WHMCS, or similar proprietary systems. As a result, I decided to experiment with this and find out if the cracker can somehow get the email confirmation link that he needs from the customer support system.
Most support portals can be integrated with single sign-on technology: an authenticated user will automatically log into the support service. This improves usability. More than half of the sites I checked did not require verification of the email address. This means that anyone can register in the system with any email address and read any support requests created using this address. Vimeo's online video platform was one of many companies that did not require verification.
As a result, I registered an account on Vimeo using the same email address that Slack uses to send confirmation email addresses: [email protected].
Registering at Vimeo using [email protected]
Using the convenient Slack Find Your Workspace feature , I found the Vimeo team at Slack and registered with [email protected].
Registration in vimeo.slack.com using the address [email protected]
In the meantime, a message was sent from [email protected] to [email protected] containing a link to confirm the address.
When [email protected] receives a letter, it is classified as a ticket for technical support created from [email protected] ... and this is exactly the address with which I registered.
Then I looked in Vimeo support team to check my tickets.
Vimeo Support
There was one call that contained the same address confirmation link that I needed in order to join the Vimeo team.
Confirm address link
The Vimeo team immediately responded to my report on the found error, they gave me $ 2000 as part of their bug search program (# 220102 , pending disclosure).
This vulnerability affects all websites that integrate a support portal that does not provide email verification. However, it turned out even worse.
I discovered two more holes in Kayako and Zendesk, which allowed me to bypass the process of confirming the email address with their usual settings. This allowed me to successfully carry out the attack, even in cases where the SSO service was disabled and confirmation of the email address was required. I reported these issues on June 1, as part of responsible disclosure programs for vulnerabilities. Both projects fixed everything.
Further, websites that require confirmation of the address after registration, but not after its subsequent change, are also vulnerable.
If a company doesn’t use Slack and they think it’s safe ... it’s probably not so good, considering how common the vulnerability I discovered was. For example, other business communication tools, such as Yammer, are also susceptible to this attack.
I managed to connect to the internal Yammer network, owned by a company whose name I do not disclose.
And since we can read letters sent to addresses like support @, we can see links to reset passwords sent to these addresses. As it turned out, quite a few companies use this address to register with third-party services and social networks like Twitter.
This means that the attacker, in addition, can seize any account associated with an address like support @.
Twitter password reset
I managed to capture several Twitter accounts with more than a million subscribers.
In some cases, privileged accounts on company websites were also associated with these email addresses. By registering with the address [email protected], it was possible to intercept the password reset token for [email protected] and gain access to privileged accounts that gave access to all customer information.
If none of the above methods worked, the attacker had the opportunity to read existing and future tickets to the support service created using mail, and respond to them. My friend once sent a letter to the address of the company support service, because something was working wrong. Dealing with this problem, I found out that a certain company turned out to be vulnerable, so I registered in the system using its address, went to the "my support cases" section and saw how the letter appeared there. I was able to read letters that were sent to the support service from those users who did not have an account in this service, was able to respond to them. As a result of such an attack, users who think that they are communicating with the support service, in fact, correspond with the hacker.
I was curious to know how exactly each company will eliminate the vulnerability that I discovered. Here's what happened in the end.
The companies that were affected most of all reacted very professionally to my requests. Some even decided to give out a reward for the discovered vulnerability in the amount of $ 8,000. Sometimes I received negative answers, and some simply ignored me.
The administration of the GitLab error tracking system (# 218230 , disclosed) quickly took action, namely, now the addresses open on the company's domain are not trusted, in addition, some Slack settings have been changed. Further, they made changes to the documentation so that their users did not make the same mistakes.
I reported a problem in Slack (# 239623 , pending disclosure) in order to find out if we can prevent this at a higher level. Despite the fact that they are not directly responsible for this vulnerability, it affects a considerable number of their customers.
Slack took the problem seriously and changed their no-reply address so that it included a random token. This allows you to reliably prevent such attacks on support services software. The problem, however, is still relevant for error tracking services and other email-integrated systems. Despite the fact that this is not a vulnerability of the Slack service itself, I received a generous $ 1,500 reward from the company.
Slack added randomized tokens to its no-reply address in order to prevent attacks on support services.
In addition, I tried to contact Yammer to report this problem. At first, I did not receive an answer. Two weeks later, I sent the next letter, which was answered, saying that I had forwarded it to the Yammer team along with a description of the vulnerability. So far, they have not taken any proactive measures to solve the problem at a higher level, as they did at Slack.
Attackers can still join Yammer workspaces using the vulnerability
I discovered. I contacted Kayako and Zendesk as part of their vulnerability search programs (# 235139 , disclosed), reporting the possibility of bypassing SSO. The companies solved this problem and gave me, respectively, $ 1,000 and $ 750.
How to find out what could affect our company?
This vulnerability is relevant if support desk tickets can be created using email messages, and if tickets are available to users with unconfirmed email addresses. In addition, it exists in publicly accessible bug trackers, or if the system, responding to user messages, provides them with unique addresses in the company’s domain for sending messages that later go to tickets, to forum posts, to private correspondence or to the user account.
If a company is vulnerable to this vulnerability, how can it be dealt with?
I have seen several approaches to solving this problem. Companies like AirBnb, LinkedIn, and GitHub provide addresses on another domain, like reply.linkedin.com or mail .github.com. These addresses cannot be used to register with services like Yammer or Slack. GitLab updated the documentation to include this tip to prevent such attacks in error tracking services.
Some have decided to disable email-related functionality, a support portal, or single sign-on. Others have implemented a suitable system for checking email addresses. In addition, it is not recommended to register with services like Twitter, Slack or Zendesk using corporate addresses like support @.
If our public service or business communications system is susceptible to this vulnerability, how can we deal with it?
You can implement additional security measures for those who register with your system using customer support mailboxes, but this is usually impractical and inefficient. For example, Facebook Workplace has a better approach, as they send letters from randomly generated addresses like [email protected] . The attacker cannot guess what the address will be like. In response to my appeal, Slack also decided to implement similar functionality.
Why do you disclose this information, because hundreds of companies are still vulnerable?
A large number of vulnerable companies make it impossible to inform them all. There is a risk of suing companies that did not seek safety advice. I contacted only a small number of companies affected by the vulnerability, and with service providers that implement publicly accessible vulnerability disclosure programs. Opening this information now was a difficult decision, it can lead to hacks, but history teaches us that hiding information about errors is even worse.
Dear readers! Is your company vulnerable to Ticket Trick?
I came up with a name and logo for my find. Take it for granted.
The issue in question still exists. This is not the case when everything can be instantly put in order. Over the past few months, I have contacted dozens of companies and vulnerable service providers, as part of their bug-trapping programs, in order to remedy the situation. Due to the huge number of organizations to which this applies, I am not able to contact everyone. Following the recommendations of some of the people I respect and with the permission of the organizations affected by the problem, I publish this material so that everyone concerned can take action immediately. Now I will talk about what I called Ticket Trick.
Door: register using a corporate mailbox
Popular business communication platforms, such as Slack, Yammer, and Facebook Workplace, require company employees to sign up using corporate mailboxes. As soon as the employee clicks on the link to confirm the address sent to his work mail, he will be able to join the group of the company in the service and gain access to internal communication with other members of the group.
Slack: users whose mailbox is open on the same corporate domain can, by default, join the team. This can be replaced with SSO or set to connection mode by invitation only
Yammer: anyone with a corporate mailbox can join the company team
Facebook Workplace: Anyone with a corporate email account can join the team.
Door Keys: a support service or the function of creating calls from email messages
▍ Method No. 1: error tracking system
I started research with GitLab. Anyone with a live email account at @ gitlab.com can join their team at Slack.
Connecting to the GitLab team in Slack
At the same time, GitLab offers the ability to create error messages by sending them ... to a unique address created on @ gitlab.com. See where everything is going?
GitLab is one of many error tracking systems that provides the ability to generate error messages via email.
For the sake of interest, I tried to join their team on Slack using the email address provided to me to generate error messages.
Registration at gitlab.slack.com
Immediately after registration, I updated my list of hits, and saw that a confirmation letter was added to my project, in the form of a new error message.
Confirmation email
The error message just added contained a “magic link” needed to connect to the GitLab Slack command:
A letter with a link to confirm the address
I clicked on the link in order to see if it worked. She worked. I was offered a list of channels that I can join. I immediately deleted the account and reported the problem to GitLab.
Edited screenshot with a list of channels
The GitLab team replied to my message the same Sunday evening when I sent it to them.
Response to the vulnerability message
They immediately changed the connection mode to their team on Slack, making it possible to connect only by invitation. In addition, they took additional measures in order to inform their customers about the dangers of such functionality.
▍Method No. 2: support service
Not many websites have a public bug tracker, so I decided to dig deeper in order to find out if there is some more common attack vector. As it turned out - it exists, and it occurs much more often than I could expect: this is a customer support service.
Emails sent to [email protected] are sometimes found on online support portals, such as Zendesk, Kayako, (Fresh) Desk, WHMCS, or similar proprietary systems. As a result, I decided to experiment with this and find out if the cracker can somehow get the email confirmation link that he needs from the customer support system.
Most support portals can be integrated with single sign-on technology: an authenticated user will automatically log into the support service. This improves usability. More than half of the sites I checked did not require verification of the email address. This means that anyone can register in the system with any email address and read any support requests created using this address. Vimeo's online video platform was one of many companies that did not require verification.
As a result, I registered an account on Vimeo using the same email address that Slack uses to send confirmation email addresses: [email protected].
Registering at Vimeo using [email protected]
Using the convenient Slack Find Your Workspace feature , I found the Vimeo team at Slack and registered with [email protected].
Registration in vimeo.slack.com using the address [email protected]
In the meantime, a message was sent from [email protected] to [email protected] containing a link to confirm the address.
When [email protected] receives a letter, it is classified as a ticket for technical support created from [email protected] ... and this is exactly the address with which I registered.
Then I looked in Vimeo support team to check my tickets.
Vimeo Support
There was one call that contained the same address confirmation link that I needed in order to join the Vimeo team.
Confirm address link
The Vimeo team immediately responded to my report on the found error, they gave me $ 2000 as part of their bug search program (# 220102 , pending disclosure).
This vulnerability affects all websites that integrate a support portal that does not provide email verification. However, it turned out even worse.
I discovered two more holes in Kayako and Zendesk, which allowed me to bypass the process of confirming the email address with their usual settings. This allowed me to successfully carry out the attack, even in cases where the SSO service was disabled and confirmation of the email address was required. I reported these issues on June 1, as part of responsible disclosure programs for vulnerabilities. Both projects fixed everything.
Further, websites that require confirmation of the address after registration, but not after its subsequent change, are also vulnerable.
Scaling up the problem
If a company doesn’t use Slack and they think it’s safe ... it’s probably not so good, considering how common the vulnerability I discovered was. For example, other business communication tools, such as Yammer, are also susceptible to this attack.
I managed to connect to the internal Yammer network, owned by a company whose name I do not disclose.
And since we can read letters sent to addresses like support @, we can see links to reset passwords sent to these addresses. As it turned out, quite a few companies use this address to register with third-party services and social networks like Twitter.
This means that the attacker, in addition, can seize any account associated with an address like support @.
Twitter password reset
I managed to capture several Twitter accounts with more than a million subscribers.
In some cases, privileged accounts on company websites were also associated with these email addresses. By registering with the address [email protected], it was possible to intercept the password reset token for [email protected] and gain access to privileged accounts that gave access to all customer information.
If none of the above methods worked, the attacker had the opportunity to read existing and future tickets to the support service created using mail, and respond to them. My friend once sent a letter to the address of the company support service, because something was working wrong. Dealing with this problem, I found out that a certain company turned out to be vulnerable, so I registered in the system using its address, went to the "my support cases" section and saw how the letter appeared there. I was able to read letters that were sent to the support service from those users who did not have an account in this service, was able to respond to them. As a result of such an attack, users who think that they are communicating with the support service, in fact, correspond with the hacker.
Answers of companies and service owners
I was curious to know how exactly each company will eliminate the vulnerability that I discovered. Here's what happened in the end.
The companies that were affected most of all reacted very professionally to my requests. Some even decided to give out a reward for the discovered vulnerability in the amount of $ 8,000. Sometimes I received negative answers, and some simply ignored me.
The administration of the GitLab error tracking system (# 218230 , disclosed) quickly took action, namely, now the addresses open on the company's domain are not trusted, in addition, some Slack settings have been changed. Further, they made changes to the documentation so that their users did not make the same mistakes.
I reported a problem in Slack (# 239623 , pending disclosure) in order to find out if we can prevent this at a higher level. Despite the fact that they are not directly responsible for this vulnerability, it affects a considerable number of their customers.
Slack took the problem seriously and changed their no-reply address so that it included a random token. This allows you to reliably prevent such attacks on support services software. The problem, however, is still relevant for error tracking services and other email-integrated systems. Despite the fact that this is not a vulnerability of the Slack service itself, I received a generous $ 1,500 reward from the company.
Slack added randomized tokens to its no-reply address in order to prevent attacks on support services.
In addition, I tried to contact Yammer to report this problem. At first, I did not receive an answer. Two weeks later, I sent the next letter, which was answered, saying that I had forwarded it to the Yammer team along with a description of the vulnerability. So far, they have not taken any proactive measures to solve the problem at a higher level, as they did at Slack.
Attackers can still join Yammer workspaces using the vulnerability
I discovered. I contacted Kayako and Zendesk as part of their vulnerability search programs (# 235139 , disclosed), reporting the possibility of bypassing SSO. The companies solved this problem and gave me, respectively, $ 1,000 and $ 750.
FAQ
How to find out what could affect our company?
This vulnerability is relevant if support desk tickets can be created using email messages, and if tickets are available to users with unconfirmed email addresses. In addition, it exists in publicly accessible bug trackers, or if the system, responding to user messages, provides them with unique addresses in the company’s domain for sending messages that later go to tickets, to forum posts, to private correspondence or to the user account.
If a company is vulnerable to this vulnerability, how can it be dealt with?
I have seen several approaches to solving this problem. Companies like AirBnb, LinkedIn, and GitHub provide addresses on another domain, like reply.linkedin.com or mail .github.com. These addresses cannot be used to register with services like Yammer or Slack. GitLab updated the documentation to include this tip to prevent such attacks in error tracking services.
Some have decided to disable email-related functionality, a support portal, or single sign-on. Others have implemented a suitable system for checking email addresses. In addition, it is not recommended to register with services like Twitter, Slack or Zendesk using corporate addresses like support @.
If our public service or business communications system is susceptible to this vulnerability, how can we deal with it?
You can implement additional security measures for those who register with your system using customer support mailboxes, but this is usually impractical and inefficient. For example, Facebook Workplace has a better approach, as they send letters from randomly generated addresses like [email protected] . The attacker cannot guess what the address will be like. In response to my appeal, Slack also decided to implement similar functionality.
Why do you disclose this information, because hundreds of companies are still vulnerable?
A large number of vulnerable companies make it impossible to inform them all. There is a risk of suing companies that did not seek safety advice. I contacted only a small number of companies affected by the vulnerability, and with service providers that implement publicly accessible vulnerability disclosure programs. Opening this information now was a difficult decision, it can lead to hacks, but history teaches us that hiding information about errors is even worse.
Summary
- Corporate internal security systems are usually much more vulnerable than external security systems. Studies of such systems show that employees upload passwords, company confidential information and customer data in messaging channels that anyone who has joined the company’s team in such a system has access to.
- You can not stop in the search for vulnerabilities. Their appearance can be expected anywhere. The problem described here existed for many years on hundreds of sites that security professionals checked, but as far as I know, no one noticed this problem.
- Large companies have no idea what their employees are doing. I discussed the discovered vulnerability with CISO of a huge payment processing company. He assured me that this was not a problem for them, since their employees should not use Slack. They have their own internal system for such matters. I proved to him that he was wrong by connecting to the 8 Slack channels that were open, at your own peril and risk, by the employees themselves. These channels were used by 322 people worldwide. In the end, I got a reward of $ 5,000.
- If you want to know which Slack teams you can join using your corporate email address, use the Find Your Team feature .
Dear readers! Is your company vulnerable to Ticket Trick?
