Hacker News new | ask | show | jobs
by lstamour 2218 days ago
That won’t help if someone sets up public DNS to point to localhost or 127.0.0.1 though. Unless you check after DNS is resolved?

It’s also possible someone might bind to an IPv6 address.

Better to rely on fixes mentioned elsewhere for web socket servers running on the local machine, including inserting a secret key into web socket path or query param, ensuring the web socket validates the path or query, and ensuring there are no web socket endpoints that could be used to get the secret from the websocket when not passed in. (Like an index of paths.) The Node debugger is mentioned elsewhere here as an example and cautionary tale.

Paranoid folks could maybe trick their everyday browser into never connecting to localhost via various means, and there’s an argument that websockets deserve localhost third-party restrictions or prompts, but if I were an attacker, publishing a malicious package via the web is significantly easier and higher value. Also, websockets require JS so disabling JS is another workaround. But then the site could encourage you to enable it for other reasons...

3 comments

Thanks, I was aware of the DNS rebinding possibility but not sure how to best protect against that. I'm also less worried about websockets and other things that I know are running on my machine, but more about all the other random devices floating around in my network.

What I really want is a way to block (by default) all connections to my local network from websites outside of my network, like a firewall.

It amazes me that browsers just allow this, this should require a permission prompt.

I agree about it being scary that the browser doesn't do more to prevent connections from from "localhost" to "not localhost".

https://github.com/99designs/aws-vault/issues/578 was for an issue with remote servers accessing the localhost ec2 metadata service that aws-vault can run, that worked exactly by using DNS rebinding. It was fixed only a couple weeks ago, so it seems like this is a developing area and if I were on a red team or pen testing, I would play around with more.

I visualize the "localhost hole" problem of blindly trusting localhost as an air gap in a pipe (like [0]); anybody could come along and either drop poison in the pipe, or redirect the water coming from the top to their own bucket, or both.

[0] https://districtsales.ca/wp-content/uploads/2019/07/tru-gap-...

The best way to protect against DNS rebinding attacks is at the DNS server level on your local network.

https://www.nlnetlabs.nl/documentation/unbound/unbound.conf/

the private-address directive and setting cache-min-ttl to a value of higher than 10 minutes or so both do a lot to neuter dns rebinding attacks.

Other DNS Resolvers have similar settings.

The DNS resolver/server is still resolving 127.0.0.0/8 and ::1 with these settings.
Not if you tell it otherwise.
Part of the problem is a number of networks use public IPs including IPv6. NAT isn’t always required. Where it is used though, one could block DNS reflection at the DNS forwarder or locally, and use an application-specific firewall to block connections to local IPs from a particular app. You could use a proxy or custom DNS setting for a browser to blackhole traffic to local addresses but outside of using a proxy they could still use IP addresses. Combined with the earlier solution though that might work for IPv4 NAT environments.

Fact is, internet connected devices need to be secure, and NAT as a security tool has to be stopped, it’s just one really convenient security layer, but is relatively easy to work around, so it’s not inherently secure on its own...

I am also reminded of Internet Explorer Security Zones, where you could define different rules for your local network vs the public internet. And Home vs Work vs Public wifi connections on Windows. These days, though, most users aren’t going to configure their networks to this degree... safer routers are perhaps the only easy way to start, but folks hate getting lots of notifications, so it’s unclear how any general purpose solution would work beyond localhost.

I particularly like the “websites can reject unknown host header” solution as an extra form of protection against this. But we go back to the web socket server needing to inspect the URL and host headers it’s given. Also: https://news.ycombinator.com/item?id=23263983
I have even pointed various webpages to 127.0.0.1

When I do not want the browser to access somedomain.com, I redirect somedomain.com to 127.0.0.1 in my hosts file