I renewed the domain local.computer and set it and all subdomains to 127.0.0.1 | Hacker News Reader

I renewed the domain local.computer and set it and all subdomains to 127.0.0.1

twitter.com

9 pointsskwashd17 comments

Every computer already defines the domain "localhost" for this purpose, which never expires and can't be hijacked. Why would someone want to use this risky alternative?

Also, localhost will work if your machine is disconnected from the internet, while local.computer, which relies on a remote DNS server, will not.

It's really just for convenience. I build a lot of drupal sites and often need to run a lot of them at once locally.

Instead of putting each one on it's own port (hard to remember) or starting and stopping VMs or containers (tedious), I just use a subdomain like http://projectname.local.computer).

I'm a contributor to Aegir, and created the aegir docker containers, which default to aegir.local.computer for easy testing. When I create sites in aegir, I don't have to set any DNS if I use a subdomain of aegir.local.computer, I can just visit node/add/site and fill in the form and get a site. Great for Aegir development. See https://hub.docker.com/r/aegir/hostmaster/

I'm also creator of devshop, a more "cloud-y" version of aegir which gives each site a domain automatically, so local.computer is really great for developing devshop as well. http://ENVIRONMENT.PROJECT.devshop.local.computer

I've also got a CLI tool for launching drupal sites locally in docker containers called Terra. It uses jwilder/nginx-proxy to route requests for domains to the right container, and makes dynamic domains like devshop. So *.local.computer is useful there too.

https://github.com/terra-ops/terra-cli https://github.com/opendevshop/devshop

This is still a pointless security risk. Just use projectname.whatever (something that isn't on a public TLD).

I still can't quite put my finger on the security risk for others, can you help explain what makes it one?

Here's the only scenario I can think of:

Say you are a web developer and you use mybusiness.local.computer for developing your client's website. You use it every day, you are used to loading up the URL and seeing your website.

One day I, owner of local.computer turn the dark side. I decide that I want to attack you, this one person who I know uses mybusiness.local.computer, and change mybusiness.local.computer to redirect to my nefarious server.

When I do that, when you come to work, you load up mybusiness.local.computer and expect to see the site you've been working on.

Because I know my victim, I know exactly what website to spoof, so I have my spoof up and running on my nefarious server.

Then, when the victim goes to visit mybusiness.local.computer, thinking they are visiting a copy of their website, it's actually being served from my server.

Hopefully, you then input some information, like their username and password, which I then capture in my spoof website.

This is the only way I can imagine using this domain against someone.

It involves quite a few assumptions:

- The one in control of DNS is the attacker. - The attacker has one specific victim in mind, because they can only spoof one website. - The attacker already knows what site the victim is expecting to load at a .local.computer domain. This requires personal knowledge of the victim's site because the DNS for .local.computer goes straight to 127.0.0.1. Requests are not proxied or logged. (Ok, after writing this, I realize I could change the local.computer to go through my servers then redirect the user to 127.0.0.1 enabling me to at least learn what subdomains are being requested. Still, I have no idea what that site is supposed to be.) - The attacker is able to spoof that website well enough that the victim (a developer of the website) is able to be fooled into giving up information.

Is there another way this could be abused? I seriously would like to know.

Thanks!

As the owner of local.computer, you are in a position to intercept anything a developer is sending to her server via HTTP request. This could be username/password, yes.

You also then know the public IP address and public domain of a development server, which may allow you to access the server and learn secrets, steal stack traces, etc.

It's a small security risk, but it's a non-zero risk with zero benefit. Just use fake, never-to-be-public domains. There's no downside. If you need to interact with something like Twilio (which you never need to do while developing), you can wait until you're ready to push to staging.

The benefit is not zero, it is having unlimited domains pointed to local without having to ever mess with DNS or /etc/hosts.

You can do this using dnsmasq[1] on Linux or OS X and Acrylic DNS on Windows[2]. I guess if someone wanted to do more work, they could also just register their own random domain and point it to 127.0.0.1.

We're also talking about maybe 30 seconds of work per project to edit a hosts file. Someone who knows their command line will be able to do it in 5 seconds. Multiplied by 20 projects, that's still only 2 to 10 minutes of work every year.

I personally use localhost for everything and just work on one thing at a time. I never mess with hosts.

1. https://davejamesmiller.com/blog/installing-dnsmasq-wildcard...

2. http://mayakron.altervista.org/wikibase/show.php?id=AcrylicH...

I build systems (devshop/aegir) that create and destroy websites on the fly.

If I'm working on a feature related to that process I could create and delete a dozen or more arbitrary domains in a day.

I also know plenty of web development teams that are less technical and could deal without manual hosts file tweaking on a daily basis.

I also use multiple computers. With this domain, I never have setup Dnsmasq, never have to edit a hosts file, never have to edit DNS.

Being obsessed with automation and efficiency, anywhere I can save a few seconds, I will.

> Being obsessed with automation and efficiency, anywhere I can save a few seconds, I will.

I just make my CLI tools update my hosts file.

*.local.computer all points to 127.0.0.1 - when I want localhost subdomains, I want unique IPs too (so e.g. I could bind different httpds to 127.0.0.1:80 and 127.0.0.2:80, or other evil thing I've thought up)

Actually, let me put it another way.

Public DNS records are intended to allow other people to easily locate and network with your server. You never want people to do that with a development server.

Sure, but this record goes to 127.0.0.1. How would I get the IP of your development server other than 127.0.0.1? When you request local.computer, it's not sending me your IP, it's requesting one.

Right? Public DNS for a private IP doesn't get me anything I don't already know, right?

I'm not a security expert, so my answers are not going to be exhaustive and may be incorrect. The bottom line is that trusting someone else with the DNS records for a development server is pointless and comes with some risk. Use it yourself if you want, but there's no reason other people should trust their security to a stranger who may have poor security practices (insecure password for registrar's website, for example).

I mentioned that public DNS is for networking only to point out that there's a mismatch here between the problem and the solution, but there are still attack vectors here.

One vector would be your ability to intercept anything that's being sent to the development server by a browser or IDE, which could include debug information, API keys, fragments of the stack, or even chunks of source code. It depends on the tools the developer is using.

> How would I get the IP of your development server other than 127.0.0.1?

The client IP. Many default configurations of local servers will use or bridge port 80, which means external requests will be routed to the local development server. The client IP, as well as permissive firewall settings, would allow an attacker to access the development server.

> When you request local.computer, it's not sending me your IP, it's requesting one.

With a very low TTL, you could still get the client IP pretty reliably. This is how DNS rebinding attacks work.

I never suggested using the domain for anything but web browser requests, not sure why anyone would need to use it to connect in any other way.

So as long as users don't use it for connecting to their local server are they safe?

Don't most people connect to local servers via Vagrant or docker shared volumes, anyway?

Not sure why anyone would use it for accessing their local machine when there are existing methods for that.

Thanks for the details.

Another option is to use dynamic DNS service like - http://www.noip.com IIRC they also supports wildcard subdomains.

I've recently started to add a local. record to the DNS of the project which points to the statically defined local Vagrant IP, as you often need to add dev and staging records anyway.

> I still can't quite put my finger on the security risk for others, can you help explain what makes it one?

FWIW, here's the way I see this actually going down:

1) Within a decade or two, you forget or are unavailable to renew. 2) Domain squatter takes over and spams ads. 3) It's 2036 and we still have 0-days and browser exploits.

This seems like a good reason for you to use that domain. But if someone else wants to do the same thing, it might be better for them to register their own domain that resolves to localhost rather than use yours - that way, they at least have control of how long their domain will be in existence and know that they control the IP address it resolves to.

"Why would someone want to use this risky alternative?"

Well, you can have some fun jamming this into various text fields that might block 127.0.0.1 and "localhost", but don't successfully block everything else that leads to local access, thus allowing you to use $SOME_NETWORK_SERVICE to probe its own internal services.

It can also be fun to jam something like 127.3.22.99 into things that only block 127.0.0.1; the whole 127.0.0.0/8 is "localhost". Try it with ping sometime.

Reply on news.ycombinator.com