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

81–89 of 89 posts

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

#81

Post by anthk »

tandr wrote: post #39
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...

This is a nice summary actually. (btw, you can read it to techy-but-not-in-the-field and still get the same look. I am not sure if I should be sad or proud from the fact that I understood 90% of what you have said without google-fu...)

If you are into SIP this is pretty well known.

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

#82

Post by monsieurbanana »

o-__-o wrote: post #71
MrStonedOne wrote: post #70

Earlier quoted context omitted.

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.

Let's start with an easy question, what is CAL?

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

#83

Post by dep_b »

ct520 wrote: post #50
lwb wrote: post #38

Earlier quoted context omitted.

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.

Yeah there's the WebRTC you can hack in an afternoon and there's the WebRTC that covers the most common edge cases. The problem that the solution to one problem (for example your websocket going disconnecting mid call while WebRTC still soldiers on) can create three new problems when a different edge case arises.

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

#84

Post by m463 »

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 recall Elon Musk's Acronyms Seriously Suck memo

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

#85

Post by jrockway »

Nextgrid wrote: post #35
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 wish there was an easy way to do mutual TLS auth with pre-shared keys that can be stored and copy/pasted just like normal passwords or API keys without having to maintain a CA and handle certificate issuing & renewal (sure, technically forever-lived certificates aren't as secure, but even those would already be a major upgrade compared to the status quo).

I personally use cert-manager to run the CA, then create a cert for each app and have k8s inject it. It is more manual than a service mesh, but many applications support this strategy out of the box. (I will say that creating a certificate resource is a lot easier than the old days of some directory of shell scripts acting as your CA, though. And the same code manages my letsencrypt certs.)

For example, I have Grafana backed by Postgres, and they both understand this authentication scheme out of the box. Postgres is happy to be provided with a cert to present to connecting applications, and is happy to check the cert that applications present against the CA cert.

The main problem with my setup is that I use a ClusterIssuer CA, so really anyone in the cluster can get a valid certificate. This is not amazingly secure and things like Istio do a bit more provenance checking of the application before issuing a cert, which I like. But this is simple, and does protect against the attack this article covers -- as long as you don't go out of your way to present the application's cert when proxying a connection. (Which is probably an easy mistake to make, so be careful.)

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

#86

Post by o-__-o »

monsieurbanana wrote: post #82
o-__-o wrote: post #71

Earlier quoted context omitted.

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.

Let's start with an easy question, what is CAL?

Client access license. For Microsoft Windows they come in per-seat and per-machine. To OPs point, they were talking about RDP. When you are licensing per-machine then (windows server) you are limited to one desktop user and two remote users (for windows desktop it’s one user at a time). When it is per-seat then you can have as many concurrent connections as you have licensed for. Per-seat is enforced by Microsoft Licensing Server

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

#87

Post by MrStonedOne »

o-__-o wrote: post #86
monsieurbanana wrote: post #82

Earlier quoted context omitted.

Let's start with an easy question, what is CAL?

Client access license. For Microsoft Windows they come in per-seat and per-machine. To OPs point, they were talking about RDP. When you are licensing per-machine then (windows server) you are limited to one desktop user and two remote users (for windows desktop it’s one user at a time). When it is per-seat then you can have as many concurrent connections as you have licensed for. Per-seat is enforced by Microsoft Lic…

I was mainly referring to personal pc uses, not corp/server users.

It's still technically breaking the license to override TERMSERV.dll's protections on home/professional PCs not allowing somebody to be logged in while somebody else is already logged in.

ie, a home or professional licensed pc can not support 1 user on remote desktop, and 1 user sitting down in front of it at the same time, you have to pay for a server license to get that functionality. This technical limitation is considered a DRM measure and also protected by the DMCA anti-circumvention provision.

if you don't mind breaking the law, I was pointing out how you could use abuse 127.0.0.2 to connect remote desktop to localhost in other to do seperate user accounts for seperate tasks, (such as putting your job hunting activities in a seperate account so you don't get distracted by discord/chrome desktop notifications and reddit in your new tab page)

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

#88

Post by namibj »

Nextgrid wrote: post #35
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 wish there was an easy way to do mutual TLS auth with pre-shared keys that can be stored and copy/pasted just like normal passwords or API keys without having to maintain a CA and handle certificate issuing & renewal (sure, technically forever-lived certificates aren't as secure, but even those would already be a major upgrade compared to the status quo).

Huh? TLS has PSK ciphers. They're popular in low-power IoT devices, because even ecc crypto is rather expensive, compared to e.g. AES.

I'm not sure if any of the PSK modes manage to work with perfect forward secrecy though. Otherwise, leaking the PSK would also allow decrypting any previously-sniffed traffic.

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

#89

Post by tandr »

anthk wrote: post #81
tandr wrote: post #39

Earlier quoted context omitted.

This is a nice summary actually. (btw, you can read it to techy-but-not-in-the-field and still get the same look. I am not sure if I should be sad or proud from the fact that I understood 90% of what you have said without google-fu...)

If you are into SIP this is pretty well known.

I am not :)
Post reply on HN