Ticket Trick: Hacking hundreds of companies through customer support
A few months ago, a vulnerability was discovered with which hackers could break into corporate messaging. Taking advantage of this vulnerability is no more difficult than clicking a mouse a couple of times; if it is used successfully, you can access the company's internal network, the accounts of its employees 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 for granted.
The problem 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 service providers affected by the vulnerability, as part of their bug-trapping programs, to remedy the situation. Due to the huge number of organizations to which it applies, I am not able to contact everyone. Following the recommendations of some people I respected 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 platforms for organizing business communications, such as Slack, Yammer and Facebook Workplace, require that employees of companies are registered using corporate mailboxes. As soon as the employee clicks the link to confirm the address sent to his work mail, he will be able to join the company group in the service and get access to internal means of 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 the connection mode by invitation only.
')
Yammer: anyone with a corporate inbox can join the company team
Facebook Workplace: one who has a corporate inbox can join the team
I started research with GitLab. Anyone with a valid @ gitlab.com mailbox can join their Slack team.
Connect to the GitLab Slack Team
At the same time, GitLab offers the ability to create error messages by sending them ... to a unique address created on @ gitlab.com. See what's going on?
GitLab is one of many bug tracking systems that provides the ability to generate error messages using email.
For the sake of interest, I tried to join their Slack team using the email address I was given to create error messages.
Register at gitlab.slack.com
Immediately after registration, I updated my call list, and saw that a new address confirmation letter was added to my project as a new error message.
Address Confirmation Letter
The error message I just added contained a “magic link” needed to connect to the GitLab command on Slack:
A letter with a link to confirm the address
I clicked the link to see if it worked. She worked. I was offered a list of channels I can join. I immediately deleted my account and reported a problem to GitLab.
Edited screenshot with the list of channels
The GitLab team responded to my message on the same Sunday evening when I sent it to them.
Reaction to a vulnerability report
They immediately changed the connection mode to their team on Slack, making it possible to connect by invitation only. In addition, they have taken additional measures in order to inform their clients about the dangers of this functionality.
Not many websites have a publicly available bug tracker, so I decided to dig deeper to find out if there is a more common attack vector. As it turned out, it exists, and it occurs much more often than I could have expected: this is customer service.
Emails sent to support@company.com are sometimes found on online support portals, such as Zendesk, Kayako, (Fresh) Desk, WHMCS, or similar systems of their own design. As a result, I decided to experiment with this and find out if a cracker could somehow get the necessary email confirmation link from the customer support system.
Most support portals can be integrated with single sign-on technology: an authenticated user will automatically enter support services. This increases the usability. More than half of the sites I checked did not require verification of the email address. This means that anyone can register with any email address and read any support requests created using this address. Vimeo 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 email confirmation links to feedback@slack.com.
Register with Vimeo using feedback@slack.com
Using the convenient Slack Find Your Workspace feature, I found the Vimeo command on Slack and registered with support@vimeo.com.
Register at vimeo.slack.com using support@vimeo.com
In the meantime, an email was sent to feedback@slack.com at support@vimeo.com, containing a link to confirm the address.
When support@vimeo.com receives a letter, it is classified as a ticket for technical support, created from the address feedback@slack.com ... and this is the address with which I registered.
Then I looked into Vimeo support to check my tickets.
Vimeo support service
It turned out one appeal, which contained the very link to confirm the address, which I needed to join the Vimeo team.
Address verification link
The Vimeo team immediately responded to my bug report, they gave me $ 2000 as part of their bug search program (# 220102 , awaiting disclosure).
This vulnerability applies to all websites in which the support portal is integrated, which does not include email confirmation. However, it turned out to be even worse.
I discovered two more holes in Kayako and Zendesk, which allowed me to bypass the email address verification process with their normal settings. This allowed me to successfully carry out the attack, even in cases where the SSO service was disabled and email confirmation was required. I reported these issues on the first of June, as part of a responsible vulnerability disclosure program. Both projects have fixed everything.
Further, websites that require confirmation of the address after registration, but not after its subsequent change, are also vulnerable.
If the company does not use Slack and they believe that they are safe ... probably not so good, considering how widespread the vulnerability I discovered was. For example, other business communication tools, such as Yammer, are also subject to this attack.
I managed to connect to a Yammer internal network owned by a company whose name I don’t disclose
And since we can read letters sent to support @ addresses, we can also see the password reset links sent to these addresses. As it turned out, quite a few companies use this particular 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 the address type support @.
Reset password on Twitter
I managed to capture several Twitter accounts with over a million followers.
In some cases, privileged accounts on company websites were also associated with these email addresses. By registering with the address no-reply@company.com, it was possible to intercept the password reset token for support@company.com and gain access to privileged accounts that gave access to all customer information.
If none of the above methods worked, the attacker still had the opportunity to read and respond to existing and future support tickets created using mail. A friend of mine once sent a letter to the company's support desk, as something was wrong. Dealing with this problem, I found out that a certain company was 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 the letters that were sent to the support service from those users who did not have an account in this service, could answer them. As a result of this attack, users who think that they are communicating with the support service, in fact, correspond with the hacker.
I was curious to find out exactly how each company would eliminate the vulnerability I discovered. That's what happened in the end.
The companies that were most affected by this responded to my appeals very professionally. Some even decided to give 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 opened 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 , awaiting 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 clients.
Slack took the problem seriously and changed its no-reply address to include a random token. This allows you to reliably prevent such attacks on software support services. The problem, however, is still relevant for bug tracking services and other systems integrated with e-mail. Despite the fact that this is not a vulnerability of the Slack service itself, I received a generous reward of $ 1,500 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 issue. At first I did not receive a reply. Two weeks later, I sent the following email to which I responded, saying that I had been sent to the Yammer team along with a description of the vulnerability. So far, they have not taken any proactive measures in order to solve the problem at a higher level, as they did in Slack.
Attackers can still join Yammer workspaces using the vulnerability I discovered
I contacted Kayako and Zendesk as part of their vulnerability scan program (# 235139 , revealed), reporting the possibility of bypassing SSO. Companies have solved this problem and gave me, respectively, $ 1000 and $ 750.
How to know that this may affect our company?
This vulnerability is relevant if support ticket tickets can be created using email messages, and if tickets are available to users with unconfirmed email addresses. In addition, it exists in publicly available bug trackers, or if the system, responding to user messages, provides them with unique addresses in the company's domain to send messages that then get tickets, posts in forums, private correspondence or into the user account.
If a company is exposed to this vulnerability, how to cope with it?
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 has updated the documentation to include this tip to prevent such attacks in error tracking services.
Some decided to disable e-mail functionality, support portal, or single sign-on. Others have implemented a suitable email address verification system. In addition, it is not recommended to register with services like Twitter, Slack or Zendesk using support @ corporate addresses.
If our public service or business communications system is exposed to this vulnerability, how to 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, a more successful approach is implemented in Facebook Workplace, since they send emails from randomly generated addresses like notification+ajivdw9kpwld@fbworkmail.com . The attacker cannot guess what this address will be like. In response to my appeal, Slack also decided to implement this 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 being sued by companies that have not sought safety advice. I only contacted a small number of vulnerable companies and service providers that implement publicly available vulnerability disclosure programs. The discovery of this information was now a difficult decision, it can lead to hacking, 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 for granted.
The problem 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 service providers affected by the vulnerability, as part of their bug-trapping programs, to remedy the situation. Due to the huge number of organizations to which it applies, I am not able to contact everyone. Following the recommendations of some people I respected 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 corporate mailbox
Popular platforms for organizing business communications, such as Slack, Yammer and Facebook Workplace, require that employees of companies are registered using corporate mailboxes. As soon as the employee clicks the link to confirm the address sent to his work mail, he will be able to join the company group in the service and get access to internal means of 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 the connection mode by invitation only.
')
Yammer: anyone with a corporate inbox can join the company team
Facebook Workplace: one who has a corporate inbox can join the team
Door Keys: support service or email creation feature
â–ŤMethod # 1: error tracking system
I started research with GitLab. Anyone with a valid @ gitlab.com mailbox can join their Slack team.
Connect to the GitLab Slack Team
At the same time, GitLab offers the ability to create error messages by sending them ... to a unique address created on @ gitlab.com. See what's going on?
GitLab is one of many bug tracking systems that provides the ability to generate error messages using email.
For the sake of interest, I tried to join their Slack team using the email address I was given to create error messages.
Register at gitlab.slack.com
Immediately after registration, I updated my call list, and saw that a new address confirmation letter was added to my project as a new error message.
Address Confirmation Letter
The error message I just added contained a “magic link” needed to connect to the GitLab command on Slack:
A letter with a link to confirm the address
I clicked the link to see if it worked. She worked. I was offered a list of channels I can join. I immediately deleted my account and reported a problem to GitLab.
Edited screenshot with the list of channels
The GitLab team responded to my message on the same Sunday evening when I sent it to them.
Reaction to a vulnerability report
They immediately changed the connection mode to their team on Slack, making it possible to connect by invitation only. In addition, they have taken additional measures in order to inform their clients about the dangers of this functionality.
â–ŤMethod â„–2: support service
Not many websites have a publicly available bug tracker, so I decided to dig deeper to find out if there is a more common attack vector. As it turned out, it exists, and it occurs much more often than I could have expected: this is customer service.
Emails sent to support@company.com are sometimes found on online support portals, such as Zendesk, Kayako, (Fresh) Desk, WHMCS, or similar systems of their own design. As a result, I decided to experiment with this and find out if a cracker could somehow get the necessary email confirmation link from the customer support system.
Most support portals can be integrated with single sign-on technology: an authenticated user will automatically enter support services. This increases the usability. More than half of the sites I checked did not require verification of the email address. This means that anyone can register with any email address and read any support requests created using this address. Vimeo 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 email confirmation links to feedback@slack.com.
Register with Vimeo using feedback@slack.com
Using the convenient Slack Find Your Workspace feature, I found the Vimeo command on Slack and registered with support@vimeo.com.
Register at vimeo.slack.com using support@vimeo.com
In the meantime, an email was sent to feedback@slack.com at support@vimeo.com, containing a link to confirm the address.
When support@vimeo.com receives a letter, it is classified as a ticket for technical support, created from the address feedback@slack.com ... and this is the address with which I registered.
Then I looked into Vimeo support to check my tickets.
Vimeo support service
It turned out one appeal, which contained the very link to confirm the address, which I needed to join the Vimeo team.
Address verification link
The Vimeo team immediately responded to my bug report, they gave me $ 2000 as part of their bug search program (# 220102 , awaiting disclosure).
This vulnerability applies to all websites in which the support portal is integrated, which does not include email confirmation. However, it turned out to be even worse.
I discovered two more holes in Kayako and Zendesk, which allowed me to bypass the email address verification process with their normal settings. This allowed me to successfully carry out the attack, even in cases where the SSO service was disabled and email confirmation was required. I reported these issues on the first of June, as part of a responsible vulnerability disclosure program. Both projects have fixed everything.
Further, websites that require confirmation of the address after registration, but not after its subsequent change, are also vulnerable.
Scaling up problems
If the company does not use Slack and they believe that they are safe ... probably not so good, considering how widespread the vulnerability I discovered was. For example, other business communication tools, such as Yammer, are also subject to this attack.
I managed to connect to a Yammer internal network owned by a company whose name I don’t disclose
And since we can read letters sent to support @ addresses, we can also see the password reset links sent to these addresses. As it turned out, quite a few companies use this particular 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 the address type support @.
Reset password on Twitter
I managed to capture several Twitter accounts with over a million followers.
In some cases, privileged accounts on company websites were also associated with these email addresses. By registering with the address no-reply@company.com, it was possible to intercept the password reset token for support@company.com and gain access to privileged accounts that gave access to all customer information.
If none of the above methods worked, the attacker still had the opportunity to read and respond to existing and future support tickets created using mail. A friend of mine once sent a letter to the company's support desk, as something was wrong. Dealing with this problem, I found out that a certain company was 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 the letters that were sent to the support service from those users who did not have an account in this service, could answer them. As a result of this 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 find out exactly how each company would eliminate the vulnerability I discovered. That's what happened in the end.
The companies that were most affected by this responded to my appeals very professionally. Some even decided to give 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 opened 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 , awaiting 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 clients.
Slack took the problem seriously and changed its no-reply address to include a random token. This allows you to reliably prevent such attacks on software support services. The problem, however, is still relevant for bug tracking services and other systems integrated with e-mail. Despite the fact that this is not a vulnerability of the Slack service itself, I received a generous reward of $ 1,500 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 issue. At first I did not receive a reply. Two weeks later, I sent the following email to which I responded, saying that I had been sent to the Yammer team along with a description of the vulnerability. So far, they have not taken any proactive measures in order to solve the problem at a higher level, as they did in Slack.
Attackers can still join Yammer workspaces using the vulnerability I discovered
I contacted Kayako and Zendesk as part of their vulnerability scan program (# 235139 , revealed), reporting the possibility of bypassing SSO. Companies have solved this problem and gave me, respectively, $ 1000 and $ 750.
FAQ
How to know that this may affect our company?
This vulnerability is relevant if support ticket tickets can be created using email messages, and if tickets are available to users with unconfirmed email addresses. In addition, it exists in publicly available bug trackers, or if the system, responding to user messages, provides them with unique addresses in the company's domain to send messages that then get tickets, posts in forums, private correspondence or into the user account.
If a company is exposed to this vulnerability, how to cope with it?
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 has updated the documentation to include this tip to prevent such attacks in error tracking services.
Some decided to disable e-mail functionality, support portal, or single sign-on. Others have implemented a suitable email address verification system. In addition, it is not recommended to register with services like Twitter, Slack or Zendesk using support @ corporate addresses.
If our public service or business communications system is exposed to this vulnerability, how to 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, a more successful approach is implemented in Facebook Workplace, since they send emails from randomly generated addresses like notification+ajivdw9kpwld@fbworkmail.com . The attacker cannot guess what this address will be like. In response to my appeal, Slack also decided to implement this 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 being sued by companies that have not sought safety advice. I only contacted a small number of vulnerable companies and service providers that implement publicly available vulnerability disclosure programs. The discovery of this information was now a difficult decision, it can lead to hacking, but history teaches us that hiding information about errors is even worse.
Results
- Internal security systems of companies are usually much more vulnerable than external ones. Studies of such systems show that employees post passwords, confidential company 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 were checked by security professionals, but as far as I know, no one noticed this problem.
- Large companies have no idea what exactly their employees do. I discussed the vulnerability with CISO of a huge payment processing company. He assured me that this was not a problem for them, as their employees should not use Slack. They have their own internal system for such cases. I proved to him that he was wrong by connecting to 8 Slack channels that were open, at his own peril and risk, by the employees themselves. These channels were used by 322 people around the world. In the end, I got a reward of $ 5000.
- 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?
Source: https://habr.com/ru/post/338822/
All Articles