We abused Slack's TURN servers to gain access to internal services
1–10 of 89 posts
Re: We abused Slack's TURN servers to gain access to internal services
#2tldr-
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
Re: We abused Slack's TURN servers to gain access to internal services
#3tldr- 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 Enabl…
Don't use indentation for formatting linebreaks. It beaks HN layout.
Just add extra linebreaks
Re: We abused Slack's TURN servers to gain access to internal services
#4tldr- 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 Enabl…
Stop using code blocks if you're not posting code
Re: We abused Slack's TURN servers to gain access to internal services
#5As 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?
Re: We abused Slack's TURN servers to gain access to internal services
#6Timeline—
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
Re: We abused Slack's TURN servers to gain access to internal services
#7As 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?
Edit: nvm, confused STUN and TURN
Re: We abused Slack's TURN servers to gain access to internal services
#8As 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?
Edit: nvm, confused STUN and TURN
It sounds like the TURN server is effectively acting like an (open) proxy. Wouldn't that mean the operator still has to have the infrastructure to handle the connections + traffic?
I'm assuming, perhaps incorrectly, that most of these RTC connections are happening over NAT and therefore usually go over TURN rather than by connecting directly. Even if that's not the case, why not try direct p2p connection first then fall back to routing through an application-specific proxy, which can have tighter controls on who connects to who and what payloads they send?
Re: We abused Slack's TURN servers to gain access to internal services
#9As 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?
My knowledge is about 2 years old on this but I can try to explain: TURN/STUN are to facilitate users communicating behind NAT and firewalls. TURN routes all traffic through a central server and pushes it to clients which it has an established connection with, thus getting around NAT/Firewall. STUN is a bit more lightweight in that it really just helps users to negotiate a normal P2P connection and then they send messages directly to eachother.
Re: We abused Slack's TURN servers to gain access to internal services
#10As 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?
My knowledge is about 2 years old on this but I can try to explain: TURN/STUN are to facilitate users communicating behind NAT and firewalls. TURN routes all traffic through a central server and pushes it to clients which it has an established connection with, thus getting around NAT/Firewall. STUN is a bit more lightweight in that it really just helps users to negotiate a normal P2P connection and then they send mes…
Thanks! That's in-line with what I thought was going on. It sounds like TURN is very close to being an open proxy.
Rather than falling back from p2p to STUN to TURN, why not replace TURN with something more application/protocol-specific?
Perhaps a webrtc-only proxy that performs authentication and can perform authorization along the lines of: user A is (only) allowed to connect to user B using protocol WebRTC.