Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

rtcsec.com

Post reply on HN
Print view View original

41–50 of 89 posts

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

#41

Post by tptacek »

jrockway wrote: post #28

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.

Any kind of inter-service authentication, really. And for lots of reasons, not just SSRF. But regardless: coherent inter-service authentication is not a norm.

If you're exclusively interested in mitigating SSRF, a more targeted solution is to run your connections (HTTP or TCP) through a proxy that enforces network-level rules. That seems like it would have worked here. For HTTP SSRF, Stripe has a good tool, Smokescreen.

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

#43

Post by jedberg »

pottertheotter wrote: post #40
russellbeattie wrote: post #31

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...

Do you mean this paragraph? "Our recommendation here is to make use of the latest coturn which by default, no longer allows peering with 127.0.0.1 or ::1. In some older versions, you might also want to use the no-loopback-peers."

OP means they paragraph they just wrote.

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

#44

Post by jedberg »

russellbeattie wrote: post #31

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...

I understood every word of that and my eyes still glazed over. :)

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

#46

Post by topher200 »

pottertheotter wrote: post #40
russellbeattie wrote: post #31

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...

Do you mean this paragraph? "Our recommendation here is to make use of the latest coturn which by default, no longer allows peering with 127.0.0.1 or ::1. In some older versions, you might also want to use the no-loopback-peers."

I believe GP means this paragraph:

> 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.

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

#47

Post by annoyingnoob »

gfodor wrote: post #12
wrkronmiller wrote: post #5

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?

If you have a centralized server, you have a SFU. SFUs typically expose a range of UDP (and/or TCP) ports for communication. Peer connections are allocated on a port basis. So if a user is connected to your SFU, they take up a port, and need to be able to egress over a large UDP/TCP port range to connect, since the port is assigned randomly. However, many firewalls block port ranges, or even UDP entirely. What you re…

Pushing everything through a proxy does not seem ideal. Seems kind of like the easy road to adding VoIP to everywhere that slack already works.

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

#50

Post by ct520 »

lwb wrote: post #38
russellbeattie wrote: post #31

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...

Even a techy who isn't familiar with networking protocols would start to glaze over!

Not so much networking protocols but WebRTC maybe? I did a hello world type of implementation of WEBRTC awhile back and it made perfect sense to me.
Post reply on HN