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
We abused Slack's TURN servers to gain access to internal services
51–60 of 89 posts
Re: We abused Slack's TURN servers to gain access to internal services
#52am 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.
Yeah, I had the same thought. For something as big as this? Should be at least 2 more zeros imo.
Re: We abused Slack's TURN servers to gain access to internal services
#53Earlier 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…
Also don't forget that IPv6 ::1 is localhost too.
[deleted]
Re: We abused Slack's TURN servers to gain access to internal services
#54Earlier quoted context omitted.
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.
Thanks! I don't know where my head was.
Re: We abused Slack's TURN servers to gain access to internal services
#55Earlier quoted context omitted.
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.
Thanks! I don't know where my head was.
Re: We abused Slack's TURN servers to gain access to internal services
#56So 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...
Read it to myself and my eyes glaze over, and I've spent the past couple of weeks trying to decipher all the acronyms involved in WebRTC!
Re: We abused Slack's TURN servers to gain access to internal services
#57Earlier quoted context omitted.
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.
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 sever cause it becomes assigned randomly). Compound this with the fact that some ISPs have more than 1 layer of NAT, 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.
Re: We abused Slack's TURN servers to gain access to internal services
#58So 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...
Could be a line on CSI: Los Angeles.
Re: We abused Slack's TURN servers to gain access to internal services
#59Earlier quoted context omitted.
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.
Thanks! I don't know where my head was.
Sounds like you're STUNned. Try not to TURN you head and maybe put some ICE on it.
Re: We abused Slack's TURN servers to gain access to internal services
#60Things 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.
Totally agree. I've been rolling every service out with mTLS. It was a huge PITA tho without a service mesh (which we can't use for different reasons), so I built a drop-in solution for use with any Kubernetes. I'm still developing on it a bit but my solution is open source [1]. If anybody want to use this I'm happy to provide answers to questions, and quick bug fixes (as this directly benefits my work right now). If…
I think Istio gives you mTLS for free if you add it to your kubernetes cluster.