am 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.
We abused Slack's TURN servers to gain access to internal services
61–70 of 89 posts
Re: We abused Slack's TURN servers to gain access to internal services
#62Earlier quoted context omitted.
Yeah, I had the same thought. For something as big as this? Should be at least 2 more zeros imo.
I don't understand what's so big about this. It's akin to telling someone that they forgot to use passwords on their mongodb database. Does that really deserve $350k compensation?
Let's put it another way: The team who discovered this has skills WELL worth 350k for a year's worth a work. How many security issues would they have to catch for it to be "worth it"? Maybe more than 1, but 100 show stopping vulnerabilities for 350k is crazy to me.
edit: ESPECIALLY slack, if it was possible to use this to get access to any chat logs.
Re: We abused Slack's TURN servers to gain access to internal services
#63Earlier quoted context omitted.
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.
Yes, Istio was the service mesh I referenced above that we can't install for different reasons:
>> It was a huge PITA tho without a service mesh (which we can't use for different reasons)
If you have Istio then you don't need MeTaLS (unless your client comes from outside the cluster or something, and even then I think there are ways to make it work).
I don't know that I would agree that it is "for free" as Istio still needs to be configured, and it isn't trivial from my experience. I could also see situations where something like MeTaLS where you place a few env vars for certs and you're done is nice to have. I would definitely recommend Istio if you can use it though.
Re: We abused Slack's TURN servers to gain access to internal services
#64Earlier 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…
Re: We abused Slack's TURN servers to gain access to internal services
#65Re: We abused Slack's TURN servers to gain access to internal services
#66kind of important almost title-edit-worthy to note this is an exploit and research that went on late-2017 until about mid-2018 no? Not that this is some current thing
Re: We abused Slack's TURN servers to gain access to internal services
#67So 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."
Re: We abused Slack's TURN servers to gain access to internal services
#68tldr- 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
#69Earlier quoted context omitted.
I don't understand what's so big about this. It's akin to telling someone that they forgot to use passwords on their mongodb database. Does that really deserve $350k compensation?
Depending on what a black hat could do with the data in your database, it might absolutely be worth it. I understand that 350k is way more than bug bounties usually pay, but 3.5k is taking advantage of people's ethics to outsource your security. Let's put it another way: The team who discovered this has skills WELL worth 350k for a year's worth a work. How many security issues would they have to catch for it to be "w…
Re: We abused Slack's TURN servers to gain access to internal services
#70Earlier 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…
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))