We abused Slack's TURN servers to gain access to internal services

reader_1000 | 381 points

So Slack's VoIP uses WebRTC, which connects via UDP/TCP to always send SRTP packets through a TURN proxy (which extends STUN via ICE) to work around usual NAT problems. These guys scanned the TURN and found an SSRF which allowed them to connect to Slack's VPC on AWS using IAM temporary credentials. Interesting.

For fun, read that last paragraph out loud to a non-techy near by and watch their eyes...

russellbeattie | 2 months ago

Huh, I happen to be knee-deep in this stuff right now. This article noted that Slack seemed to be running an old TURN server (pre-coturn):

https://webrtchacks.com/slack-webrtc-slacking/

Given that the latest coturn has this vulnerability mitigated by default, perhaps all this boils down to is "Slack runs outdated software, we exploited it."?

gfodor | 2 months ago

Timeline—

November 2017: added TURN abuse to our stunner toolset

December 2017: discovered and reported TURN vulnerability in private customer of Enable Security

February 2018: briefly tested Slack and discovered the vulnerability

April 2018: submitted our report to Slack, helped them reproduce and address the issue through various rounds of testing

May 2018: Slack pushed patch to live servers which was retested by Enable Security

January 2020: asked to publish report

February 2020: disclosure delayed by HackerOne/Slack

March 2020: report published

BoorishBears | 2 months ago

Things like this are why mTLS internally are so important. If a hole is found in your firewall, services still don't trust each other until they have a valid TLS certificate.

jrockway | 2 months ago

As a complete novice in this area, I don't understand the advantage of using a proxy-like service such as TURN.

What is the advantage over simply routing the media streams through application servers (i.e. user A connects to server which links to user B) which can then perform application-specific authentication, enforce restrictions on payloads, etc... Performance?

wrkronmiller | 2 months ago

am i wrong or security researchers aren't paid well. i mean not sure how much this bug is wort but def. $3500 looks like a small number.

realchucknorris | 2 months ago

Instead of sending traffic anywhere, why don't they have the destination address first send a (slack-authenticated) request to the TURN server saying "I'm happy to receive traffic from [SOURCE]" and then a temporary window is opened for [SOURCE] to open a connection to that specific destination.

Diggsey | 2 months ago

tldr-

November 2017: added TURN abuse to our stunner toolset

December 2017: discovered and reported TURN vulnerability in private customer of Enable Security

February 2018: briefly tested Slack and discovered the vulnerability

April 2018: submitted our report to Slack, helped them reproduce and address the issue through various rounds of testing

May 2018: Slack pushed patch to live servers which was retested by Enable Security

January 2020: asked to publish report

February 2020: disclosure delayed by HackerOne/Slack

March 2020: report published

kylek | 2 months ago

kind of important almost title-edit-worthy to note this is an exploit and research that went on late-2017 until about mid-2018 no? Not that this is some current thing

ChrisArchitect | 2 months ago
[deleted]
| 2 months ago
[deleted]
| 2 months ago

Thanka a lot . It is intresting for me

hodoj | 2 months ago

Now many companies are changing their schedule and style of work. Remote access is an important part of business success

lardikanna | 2 months ago

cdcd

enrichpu | 2 months ago

scs@cd

enrichp | 2 months ago

In order for employees to be able to fully work in remote access, the company installs the necessary software on employees' computers. It's enough to https://www.action1.com/. This software gives control to endpoints in real time, software deployment, installation of fixes from the cloud

lardikanna | 2 months ago