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

71–80 of 89 posts

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

#71

Post by o-__-o »

MrStonedOne wrote: post #70
jerf wrote: post #27

Earlier quoted context omitted.

You may already know this, but it's worth getting the word out. Do not just deny routing to 127.0.0.1. 127.0.0.1 is merely the conventional "localhost" address; however, ALL 127.x.x.x is "localhost". You can check this now on your local command line with "ping 127.1.2.3". (This just seems to be one of those bugs that every proxy goes through at some point, just like pretty much any attempt to write a web server that…

Fun fact, windows blocks remote desktoping to localhost (because doing so would lock the console session unless you break license and modify termserv). Fun fact 2, this only blocks 127.0.0.1. (side note: if you don't mind breaking license compliance on your personal pc, you can use this to remote desktop into other user accounts on the same pc for a nice separation of work spaces (or just move to linux))

You are not breaking the license if you pay per-seat rather than per-device.

Ask me about CALs, I can tell you all about them.

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

#72

Post by jackewiehose »

jerf wrote: post #27
jackewiehose wrote: post #17

Earlier quoted context omitted.

It's not really a bug in old coturn, just a feature in the protocol. According to the article newer versions just disable routing to 127.0.0.1 by default but there are still other network addresses you might have to consider (see article for a recommended list of "denied-peer-ips").

You may already know this, but it's worth getting the word out. Do not just deny routing to 127.0.0.1. 127.0.0.1 is merely the conventional "localhost" address; however, ALL 127.x.x.x is "localhost". You can check this now on your local command line with "ping 127.1.2.3". (This just seems to be one of those bugs that every proxy goes through at some point, just like pretty much any attempt to write a web server that…

Yes and I think you typically want to use this whole recommended list of deny-ips. Maybe that should be the default for coturn.

But running coturn in its default-config isn't a good idea anyway.

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

#73

Post by empath75 »

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.

I worked for a large tech company that was hacked by Russians at least twice, and they had a not only unencrypted, but unauthenticated sql front end and api to their inventory management system that listed every server on the network and every piece of software and version installed on it, as all the user accounts on it and privileges as well as sysadmin contact info and everything you’d need for social engineering. I realized how bad it was when I was using it to find all the servers at the company that needed to be patched for heartbleed. Anybody on any server in our network could get to it, or just someone who plugged a laptop in at the office or got in to our vpn, and you’d have the keys to the kingdom. I told the head of security and he said it would break too many things to put it behind authentication.

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

#74

Post by userbinator »

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've worked with SIP and H323 but not WebRTC so I knew about STUN/TURN/ICE, but you're right about the acronym-soup, even to those who have networking experience --- VoIP is its own little niche. (Along the same lines, I've been a bystander to a group of GSM developers' meetings and it's just as incomprehensible.)

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

#75

Post by kalium_xyz »

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

Heh, reminds me of neuromancer

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

#76

Post by paxys »

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.

Funny enough Slack itself recently open-sourced https://github.com/slackhq/nebula which does exactly that.

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

#77

Post by ddrt »

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

Acronym city right here.

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

#78

Post by ddrt »

jerf wrote: post #27
jackewiehose wrote: post #17

Earlier quoted context omitted.

It's not really a bug in old coturn, just a feature in the protocol. According to the article newer versions just disable routing to 127.0.0.1 by default but there are still other network addresses you might have to consider (see article for a recommended list of "denied-peer-ips").

You may already know this, but it's worth getting the word out. Do not just deny routing to 127.0.0.1. 127.0.0.1 is merely the conventional "localhost" address; however, ALL 127.x.x.x is "localhost". You can check this now on your local command line with "ping 127.1.2.3". (This just seems to be one of those bugs that every proxy goes through at some point, just like pretty much any attempt to write a web server that…

Isn’t that 127 address a bogon?

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

#79

Post by hatefulmoron »

ackbar03 wrote: post #57
jlokier wrote: post #26

Earlier quoted context omitted.

A TURN server has to do much less computation, and it also doesn't need to decrypt the payload. It's more or less a fancy packet forwarder. In addition, only a fraction of users will need TURN; the rest can use direct peer connections with the aid of NAT traversal; the two kinds of connection are more or less the same to higher layers. Conversely, if the application depended on an application server to process data,…

> In addition, only a fraction of users will need TURN; the rest can use direct peer connections with the aid of NAT traversal; Is there actually any data on this or is it mostly anecdotal? Because I've done my own experiments on hole punching before and its almost impossible with today's routers, almost all of which it seems implement symmetric NAT (impossible to match the ports after initial contact with the STUN s…

> I have trouble believing that the majority of Slack users either have a direct public IP or a convenient way to conduct NAT traversal successfully.

Google's libjingle documentation[1] alludes to a statistic that says that "8% of connection attempts require an intermediary relay server".

This will obviously depend on the user demographic, I would guess that users on corporate connections are probably less likely to form successful p2p connections.

[1]: https://developers.google.com/talk/libjingle/important_conce...

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

#80

Post by saagarjha »

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 read your paragraph and almost didn’t read the actual article :(
Post reply on HN