Open Redirect Vulnerability in Slack
Background
The morning of March 2nd, 2020, we were surprised to see obvious phishing emails deliver right into our inbox. This means they bypassed a multi-layered set of anti-phishing and anti-spam rules that we have configured on our Office365 tenant, including custom mail flow rules and an aggressive configuration of Microsoft APT.
While very rare, it is not unusual a few times a year for an attacker to discover a new way to thread their way through Microsoft's ATP protection. Typically, these attacks are new and thus small in scale, and they are stomped out VERY quickly.
Within an hour, we received our first report of a user who fell victim to a phishing attack, realized what happened, and immediately called us for remediation. As is standard in our response, we asked for a copy of the email they fell victim to. To our surprise it was the EXACT SAME email we received into our inbox a short time earlier. Soon after, we recieved additional reports suggesting that this attack was much more widespread.
Our immediate response to any serious attack campaign like this involves reporting the details of the attack to relevant security teams at major vendors, and blocking the unique characteristics of the campaign in affected client firewalls and email platforms. Once the account compromise was contained and remediation was in process, we turned to investigating the phishing email itself.
Further Investigation
Attacker methods grow more sophisticated by the day to make things harder on the protection systems. There's always something to be learned about the latest trends by looking more closely at a new technique.
Much of the chain of attack was relatively typical: a link to a hosted document on a reputable, legitimate service (in this case Microsoft Sway) which makes a convincing plea for a user to click another link. This next link usually goes through a redirect before landing at the actual phishing page in an attempt to hide its true objective. The phishing page impersonates a legitimate website, like portal.office.com, in an attempt to trick the user into entering their credentials so they can steal them.
What was unusual about this attack was the first step before these. The link in the original email didn't link directly to the hosted document, it too had a redirect. While not unusual in itself, this redirect was using the "slack-redir.net" domain name.
What's a redirect?
A link redirect is like a phone number foward. Most phones have the ability to forward calls to another number, so a call to 555-555-1234 forwards to 555-555-9999 without the original caller knowing any different.
Similarly, anyone who clicks on a link redirect will be sent to a webpage which transparently sends them to another link entirely. This can be useful for legitimate services who want to track, filter, or control links between sites and applications. However, without some sort of vetting in place, it can also be used by attackers to falsely assign legitimate reputation to dangerous links and obscure the true purpose of a link.
What's slack-redir.net?
Slack-redir.net is a domain owned by Slack, a popular chat and collaboration service similar to Microsoft Teams. This is where slack operates their own redirect service used in their applications. For an example of how it works, clicking this link will open a new tab or window which takes you to our NorthSky website:
https://slack-redir.net/link?url=https%3A%2F%2Fnorthskytech.com
To create this link, all we had to do was properly craft the second half with our URL. No other vetting or setup was required.
Why does this matter?
When the email protection system looks at links in these emails, all they see is a link to a known and trusted domain owned by a publicly traded company. The filters and intelligence have no reason to suspect this is malicious.
This is a problem for everyone. If false reputation can be freely assigned using an open and trusted service, one or both will happen:
It will continue to be freely exploited leading to increased compromise of businesses and users, hurting everyone.
IT departments and security filters will respond by no longer trusting this domain, or blocking it altogether, breaking the service.
The cybersecurity community recognizes these are a problem, even defining them as a formal vulnerability type: https://cwe.mitre.org/data/definitions/601.html
Furthermore, 265 of these vulnerabilities in other software and services, and counting, have been identified as so bad that they are assigned an official vulnerability number: https://www.cvedetails.com/vulnerability-list/cweid-601/vulnerabilities.html
The security community at large is concerned about this: http://projects.webappsec.org/w/page/13246981/URL%20Redirector%20Abuse https://webmasters.googleblog.com/2009/01/open-redirect-urls-is-your-site-being.html https://www.trustwave.com/en-us/resources/blogs/spiderlabs-blog/understanding-and-discovering-open-redirect-vulnerabilities/
As shown from this other blog post, Slack has been aware of this for at least more than a year. Despite that, as of the writing of this blog post, the vulnerability still exists:
https://medium.com/@abaykandotcom/open-redirect-in-slack-385eb34b7c5f
Slack's Response
Both as a courtesy and as standard practice, we quickly reached out to Slack to with this information. While their response was swift, their answer was disappointing, noting that this is something they are looking at improving, but ultimately the solution comes down to user education.
This was frustrating to say the least. Slack created a big problem for security professionals and users which is actively causing compromises, harm, and expense - and their official response is that they won't fix it and it is our problem to deal with.
Slack says that this should never be used for services visible to an end-user, and it is only for backend purposes within their application. Yet they allow the service to be freely used without restriction outside of their defined use case, by anybody in the world who wants to take advantage of it. This is an insecure design that needs to be addressed by Slack.
Digging deep into past issue reports of similar problems, it appears Slack has no interest in doing so as they consider this intentional and by design.
How to fix
Unfortunately, there's not a good answer for this. If you're operating slack yourself, you can disable the redirect functionality but that still doesn't eliminate the fact that anyone else can utilize the open redirect to mask malicious links.
There's also the option of blocking this domain in content filtering systems and spam filters, but this is a very whack-a-mole approach which could have unexpected consequences, adds technical debt, and is not scalable.
Slack has a lot of very smart engineers on their team, our best hope is that they recognize the danger this service is posing to the internet as a whole and improve the function of their redirect service so that it can only be used for legitimate purposes originating from their approved applications.