Aquaboutic | Focus Security Research | Vulnerability Exploit | POC

Home

see how i can use corporate email to handle hundreds of intranet or internal accounts

Posted by mitry at 2020-03-10
all

Translator: small stomach caused by interest

Estimated contribution fee: 260rmb

Submission method: send an email to Linwei Chen 360.cn, or log in to the web page for online submission

I. Preface

A few months ago, I found a loophole that hackers can use to obtain internal communication data of enterprises. The vulnerability is very simple to exploit. It only needs a few clicks to access the internal network and social media accounts of the enterprise, such as twitter and more common yammer and slack collaborative accounts.

The vulnerability is still not fixed because it is difficult to fix it in the first place. Over the past few months, I have contacted dozens of companies and affected vendors to participate in their vulnerability incentive programs to enable them to fix related vulnerabilities. Due to the large number of affected enterprises, I can not contact them one by one. According to the suggestions of some hacker partners, with the permission of relevant manufacturers, I wrote and published this article so that each affected unit can immediately fix the vulnerability. I call this vulnerability ticket trick.

2、 Road block gate: need to use enterprise email to register

Business collaborative communication platforms such as Slack, Yammer and Facebook Wrokpace require employees to use their corporate (@company) email to sign up for platform accounts. The employee's corporate email will receive an email containing a confirmation link. Once the employee clicks the link, they can become a part of the company for internal communication.

 

In slack, users with the same @ company mailbox can join the same team by default. We can change it to SSO (single sign on) mechanism or invitation mechanism.

 

In yammer, anyone can join as long as they have @ company mailbox.

 

In Facebook workspace, anyone can join as long as they have @ company email.

3、 Knock on the door: help desk or create by email

3.1 method 1: the issue tracker

The earliest thing can start with gitlab. For slack, I found that as long as you use an effective @ gitlab.com email, you can join gitlab's official team.

 

At the same time, gitlab provides a function to create an issue by email, as long as the specific issue is sent to a certain email address of @ gitlab.com. As shown in the figure below, I have hidden this address for privacy reasons.

 

Gitlab is just one of the other enterprises that provide the function of creating and tracking issue through email.

I tried to use this email address to join gitlab's team on slack to see if it could succeed.

 

I immediately refreshed my list of questions and found that the confirmation email had been added to my project as an issue:

 

The newly added issue contains a magic link, through which we can join gitlab's internal slack team:

 

I clicked on the link and it turned out to be the same as I thought. I received a bunch of welcome messages (as shown in the figure below), and then I immediately deleted my account and fed back the problem to gitlab.

 

Gitlab replied to my report the same night.

 

They immediately set slack to invite mode and informed their customers of the dangers of this feature.

3.2 method 2: the support desk

Only hundreds of websites have the open issue tracking function, so I want to further analyze to see if I can find a more general vulnerability utilization method. In fact, I did find such a utilization method, which is more general than I expected, that is customer service.

E-mails to [email protected] sometimes appear in an online support portal platform, such as Zendesk, Kayako, (fresh) desk, WHMCS or a customized tool. So I decided to look at this and see if hackers could extract key links from the database.

Most of these portals can integrate single sign on (SSO) functions: authenticated users can automatically log in to the service desk to ensure a seamless user experience. More than half of the sites I tested didn't need to validate email, which means anyone can use any email address to register and read any support ticket created by that email address. Online video sharing platform Vimeo is one of the companies that does not need to be verified.

So I registered a Vimeo account with the email of [email protected], which is the email used by slack to send the verification link.

 

Slack has a very convenient "find your workspace" function. With this function, I found the instance corresponding to Vimeo, and then registered with [email protected]

 

In the background processing logic, [email protected] will send an email to [email protected], including the verification link.

When [email protected] receives this email, it will be classified as a support ticket created by [email protected], which is the email I used to register.

So I went to the help center to check the support notes I received.

 

I did receive a support note with a verification link through which I could join the Vimeo team.

 

The Vimeo team immediately responded to the vulnerability report I submitted and awarded me $2000 under their vulnerability Award Program (, details to be announced).

All websites that integrate portal tools and lack mailbox verification mechanism will be affected by this vulnerability, and the situation is more severe than expected.

I found two additional vulnerabilities in Kayako and Zendesk, which we can use to bypass the mail verification process under common settings. In this way, even if the target does not have SSO enabled and mail authentication enabled, we can always successfully complete the attack. On June 1, I submitted a problem report to the vulnerability response plans of these two manufacturers, and the corresponding repair technology is under development.

In addition, if the website needs to verify the email address when the user registers, but does not need to verify when modifying the email address, the website will also be affected by the vulnerability.

4、 Further expansion of the scope of influence

If an enterprise doesn't use slack and thinks it's safe enough, they may be mistaken because the problem I found has a wide range of impacts. For example, other commercial communication tools such as yammer are also affected by this attack:

 

As shown in the figure above, I successfully joined the yammer intranet of a company.

In addition, since we can read emails to support @, we can also see any password reset links to that address. It turns out that many companies use this email address to sign up for third-party services like Twitter and social media.

This means that an attacker can also hijack any account associated with the support @ mailbox:

 

In some cases, this mailbox will also be associated with a privileged account on the target company's website. After registering for [email protected], you can intercept the password reset token of [email protected], obtain the access rights of the privileged account, and finally access the privacy information of all customers.

If none of these methods works, the attacker can still read and reply to the supporting tickets created by the mailbox (before or after). A friend of mine once wrote a letter to a company's help and support email because of some problems. After analysis, I found that there was a vulnerability in this company, so I used my friend's email to complete the registration. After clicking "my support cases", I found the email he sent before. As long as people don't have a corresponding account on the service desk, I can read and reply to all emails sent by people to customer service. Users think it's customer service people who talk to them, but in fact it's a hacker who hides behind them.

5、 Reply of manufacturers and enterprises

It is a very interesting thing to study how each enterprise deals with this vulnerability:

1. Most businesses can handle my reports in a very professional way. Some companies even decided to give me a loophole reward of up to $8000. Sometimes I get a negative response, even some enterprises choose to ignore my report completely.

2. In terms of the problem tracking function, gitlab (disclosed) quickly responded by removing trust in the company's domain name and modifying their slack settings. In addition, they also updated the documentation to prevent customers from making the same mistakes.

3. I reported this problem to slack (, to be disclosed), and wanted to see if we could stop this vulnerability in high-level logic. Although they are not directly responsible for this problem, it does affect many customers.

Slack attaches great importance to this. They modify the no reply mailbox and add a random token (as shown in the figure below), which can effectively prevent hackers from attacking the service desk software. Although the problem tracking function and other mailbox integration functions still have problems, these problems have nothing to do with slack itself. Slack awarded me $1500 for this.

 

4. I also contacted yammer. At first, I didn't get any response. Two weeks later, I sent another email. This time, they replied that they had forwarded the email to yammer's security team and told me their definition of security vulnerability by the way. So far, they have not taken positive measures like slack to solve this problem at a higher level.

 

As a result, hackers can still use the methods I found to join the yammer team.

5. I submitted an SSO bypass vulnerability to Kayako and Zendesk's vulnerability incentive program. Both solved the problem and awarded me $1000 and $750, respectively.

6、 Lessons learned

1. Once entering the enterprise, the security of the enterprise will be greatly reduced. By using the resources that everyone in the team can access, the attacker can obtain the password, enterprise secret, customer information and other privacy information posted on it.

2. We must continue to look for security risks everywhere. This problem has existed in hundreds of websites for many years, and many security experts face these websites every day. However, as far as I know, no one else has found this problem.

3. It is difficult for large enterprises to grasp the trend of employees. I discussed this issue with the CISO of a large payment enterprise, and he assured me that their enterprise must not have this issue, because their employees should not communicate through slack. They have an internal network to handle these transactions. I joined the slack channel created by 332 employees around the world of the company, proving his wrong view. I ended up with a $5000 reward.

4. If you want to know which slack teams you can join using your own company email, you can try slack's "find team" function.

Seven, FAQ

1. How to know if your company is affected?

If the support ticket can be created by email and the user with an unauthenticated email address can access the support ticket, the target will be affected by the vulnerability. In addition, if the public problem tracking and response function uses the unique @ company.com email to submit information directly to a ticket, forum post, private message or user account, then it will also be affected by this vulnerability.

2. How to fix the loopholes in the enterprise?

At present, I know that there are several ways to solve this problem. Companies like aribnb, LinkedIn, and GitHub use email addresses of different domains, such as @ reply.linkedin.com or @ mail.github.com. These mailboxes cannot be used to register services like yammer or slack. Gitlab updated their documentation based on this recommendation to prevent such vulnerabilities in the issue tracking feature.

Some companies choose to disable the email function, service portal site or single sign on function, while others use the correct mailbox authentication mechanism. In addition, I don't recommend that companies use the official support @ email to sign up for services like Twitter, slack, or Zendesk.

3. As an affected vendor, how can I prevent such vulnerabilities?

For those users who register with customer service email, you can take additional security measures, but in many cases, this method is not practical and efficient. Facebook workplace uses a more ingenious method. They use randomly generated email addresses to send emails, such as notification + [email protected], which can't be guessed by attackers. In response to my email, slack said they would use this randomized email address.

4. At present, there are hundreds of enterprises affected. Why do you disclose this loophole?

Due to the large number of affected enterprises, I cannot fully inform you that there may be legal risks in publishing this loophole, because some companies do not require me to provide security bulletins. I have contacted only a few affected companies and manufacturers with public vulnerability disclosure plans. It's a tough decision for me to publish details now, because it may directly lead to security risks, but according to historical experience, we know that hoarding hidden vulnerabilities is not a good idea either.

5. Who are you?

My name is inti and I live in Belgium. I've been good at sabotage since I was a child. I am 22 years old and am a creative editor working for Brussels, Belgium's largest radio station. In the evening, I will do some damage as a kind hacker. Google, Facebook, Microsoft, Yahoo, etc. have all thanked me for my work.

6. Any other results?

I hijacked Trump's Twitter and founded the website, stalkscan.com, which can dig deep into Facebook's interpersonal relationships. I also like to share my research results on medium.

You can follow my twitter for more information.