Is it secure to use *no authentication* for services listening only on localhost?

Question

I have many applications installed on my server that use a webui frontend to control the application.

Since I am the only user of the server, I usually bind these applications to 127.0.0.1.

As the services are bound to localhost, I have assumed that I can disable authentication (usually username+password), for these applications, because nobody outside of my local machine can even access the services.

I access the services by using an SSH tunnel; so essentially it gives me access to the server's local services from any machine.

An example: I installed BitTorrent Sync. The app uses a webui that I bind to 127.0.0.1. I then disable username+password auth for this webui, and access it using an SSH tunnel from my remote location.

My question is, is this secure? Would it be better practice to enable the application's authentication scheme? (I assume not, since it is bound localhost). Is it possible for an attacker to somehow spoof 127.0.0.1 and get access?

Answer 1

They could try spoofing 127.0.0.1 (I'm not sure if the network card would accept it or not, they shouldn't, but who knows if every setup handles this properly), but even if they could they wouldn't get a response as long as it is a webui. It might be a problem for UDP connections possibly, but web requests aren't UDP.

The larger concern would be that if an attacker ever got some level of local access to your server, they would then be able to access your services more easily. For example, if they could get some type of proxy on your server, they would then have full access as they would be able to behave as localhost.

If they get complete access to the server, you are probably hosed anyway, but authentication on the services, especially if it pushes all the way to being used to protect the data stores themselves, could limit the damage of a compromised server.

Answer 2

There is a fairly little-known attack called DNS rebinding that can be used to exploit a situation like that. Here is great a video by Robert "RSnake" Hansen explaining the basics of it. Watch it. Now.

...okay, done? So, here's the scenario: Let's say you have a web UI for a private service running on 127.0.0.1:80 with no authentication of any kind protecting it. And let's assume the service doesn't care about host headers. In most cases, the kinds of services you'd be running there won't, at least not by default.

Enter Evil Guy. He sets up a web page on his server at 123.123.123.123:80 and binds his domain name, www.evil.com, to the IP. Then he sends you an email: "Hey, check out this cool website I found: http://www.evil.com/". And you, being clueless to what's going on, open the link. The page shows you a funny cat video, but in the background it actually does an XHR request forcing the domain name to rebind to your local IP address, 127.0.0.1.

Now there is a web page at http://www.evil.com/ with Evil Guy's scripts running on it, but the domain name actually pointing to your private web UI. That means the scripts on the page have full access to your internal tool. Normally the same-origin policy would prevent such access, but now the protocols, domain names and ports match, so there's nothing it can do. And so, you're screwed.

The solution: use authentication. Or make sure your web services respect the host header and fail when receiving requests for unknown hosts. Or, just to be sure, do both.

Answer 3

Is it possible for an attacker to somehow spoof 127.0.0.1 and get access?

Not that I am aware of.

However any application running on your machine may be able to access services bound to localhost. Running a malicious or compromised application may be outside your threat model but it is worth pointing out. It is likely that if someone did have access to your machine then what might happen to your torrents may be irrelevant.

Answer 4

A Linux kernel feature called Reverse Path Filtering drops or logs packets coming on an interface (in this case network) where the reply should go on a different interface (in this case loopback).

A typical server environment has a lot of privilege levels for users and services running on that server. Whatever has local access on that server, has access to your loopback and the unauthenticated services running on it. A guest account might have minimal file privileges but it has the same privilege as any other user when it comes to accessing local services.

In a desktop user environment and where you have a web application on localhost, then someone that is intercepting your cleartext HTTP communication (you definitively have some), can inject JavaScript into it and then use your browser like a proxy for access inside your network and to localhost. The same is applicable when you fall victim to XSS on any web application you access or if your local application is vulnerable to CSRF. This was interestingly illustrated in a recent and popular story called How I hacked your router. And there are other local services like SMTP that use text communication and can be accessed through XSS and CSRF. The Man-In-The-Browser scenarios will also get to your local data.