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

Stealing secrets from developers using WebSockets

medium.com

Post reply on HN
Print view View original

21–30 of 146 posts

Re: Stealing secrets from developers using WebSockets

#21

Post by Seb-C »

grimjack00 wrote: post #16
blakesterz wrote: post #14

This websockets thing is getting more interesting very fast. I wonder how long it'll be before someone finds something truly scary? This is the 3rd post this week, and each one has found a little bit more. Nothing that seems panic worthy yet. From this one: "In all seriousness, this attack vector is pretty slim. You’ve got to tempt unwitting users to visit your site, and to stay on it while they’re developing JS code…

> You’ve got to tempt unwitting users to visit your site, and to stay on it while they’re developing JS code So, something like evil counterparts to HN, reddit, StackOverflow, or latestcatvideos.com.

After reading this post, I checked my browser console on this page, and you'll never guess what I discovered!

Re: Stealing secrets from developers using WebSockets

#22

Post by bitwize »

"In all seriousness, this attack vector is pretty slim. You’ve got to tempt unwitting users to visit your site, and to stay on it while they’re developing JS code."

Wrap the exploit up in a blog post about Rust -- or an article about gut bacteria -- and submit it to Hackernews. Boom, a virtual feast of secrets.

Re: Stealing secrets from developers using WebSockets

#23

Post by fabian2k »

I get the following output when trying this with Create React App running:

{"type":"error","data":"Invalid Host/Origin header"}

I don't think I changed any significant settings in CRA, this is pretty close to the default. Not sure what exactly determines whether this works or not.

Re: Stealing secrets from developers using WebSockets

#24

Post by stestagg »

nkozyra wrote: post #5

The server didn't work for me, not sure if it's a traffic issue or what. I have at least 3 create-react-app and one next app running. I even ran a quick websocket server on port 3000 just to see but nada.

I threw the code together last night. It's running on cloudflare backed by an S3 static file, so shouldn't be capacity issues

It was only tested on Firefox, as a basic proof-of-concept. AIUI, chrome et al offer similar functionality but maybe the API is different

It may also take a few minutes to find and connect to the websocket, I think CRA webserver maybe only binds to one client at a time, so maybe it would pick up the connection after a webpack-dev-server reload or two.

Re: Stealing secrets from developers using WebSockets

#25

Post by codazoda »

bitwize wrote: post #22

"In all seriousness, this attack vector is pretty slim. You’ve got to tempt unwitting users to visit your site, and to stay on it while they’re developing JS code." Wrap the exploit up in a blog post about Rust -- or an article about gut bacteria -- and submit it to Hackernews. Boom, a virtual feast of secrets.

Exactly. I've got a blog with dozens of technical documents about JS and other topics. That would be an ideal place to harvest this type of information, from developers actively looking for a solution to a particular problem.

Re: Stealing secrets from developers using WebSockets

#26

Post by remram »

bawolff wrote: post #13

And this is why you are supposed to check the origin and host headers before sending sensitive data to a web socket

Or use cookies, a token in the URL, or any of the existing CSRF mitigation strategies. This is not a new problem. Sensitive and destructive HTTP endpoints open to third-party origins is a bug with many existing solutions.

Re: Stealing secrets from developers using WebSockets

#27

Post by stestagg »

fabian2k wrote: post #23

I get the following output when trying this with Create React App running: {"type":"error","data":"Invalid Host/Origin header"} I don't think I changed any significant settings in CRA, this is pretty close to the default. Not sure what exactly determines whether this works or not.

Seems to be related to this: https://github.com/webpack/webpack-dev-server/issues/1604

It's not clear (without a lot more digging) what impact the sockjs changes have on this issue.

Re: Stealing secrets from developers using WebSockets

#28

Post by armchairchair »

qppo wrote: post #15
blakesterz wrote: post #14

This websockets thing is getting more interesting very fast. I wonder how long it'll be before someone finds something truly scary? This is the 3rd post this week, and each one has found a little bit more. Nothing that seems panic worthy yet. From this one: "In all seriousness, this attack vector is pretty slim. You’ve got to tempt unwitting users to visit your site, and to stay on it while they’re developing JS code…

This is one Show HN post away from an exploit in the wild

This issues isn't endemic to websockets. I've done this with iframes as well to portscan machines on my LAN. Additionally, the portscan capabilities are even worse than the article states: you can scan any machine reachable from the visitor's machine. Any 192.* address, anything behind your VPN, so long as the time for actively refusing the connection and failing to route are different. I don't know if you can time connections to known hosts to infer things about Tor circuits.

Simply call Date.now() when adding the iframe and when that iframe's onerror event fires then diff the two. I think you can do this with img tags, frames, and anything backed by a network call that lets you observe load failures.

CORS doesn't save you because you aren't trying to reach into that iframe and run Javascript or access the DOM. A CSP doesn't save you because the site you're visiting is opting to do this and can put whatever they want in their CSP.

Re: Stealing secrets from developers using WebSockets

#30

Post by stestagg »

ShaneMcGowan wrote: post #20

I too like to hardcode my AWS secret keys in my frontend application

Admittedly the example was a bit fake :)

I /have/ put other secrets into frontend code before, strictly for small temporary projects where the cost of implementing secret management outweighs the size of the project. And obviously not in code that was anywhere close to being deployed outside my own box.

Unfortunately the method outlined in the article allows access to environments that would otherwise be considered trusted and not-accessible over the internet, hence the problem

Post reply on HN