11

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?

2
  • This kind of setup automatically improves exploits that grant remote, unprivileged access into ones that grant remote, privileged access. Are you okay with that? May 24, 2014 at 3:15
  • Proxy misconfiguration is unfortunately relatively common. Jun 16, 2014 at 9:13

4 Answers 4

5

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.

4
  • You can't spoof sending to 127.*. Your packets will not get delivered.
    – Joshua
    May 19, 2014 at 16:33
  • @Joshua - are you sure that is true on all network cards and operating systems? Either way, my point is that it is irrelevant if it can or not. May 19, 2014 at 17:06
  • It's true of both Linux and Windows in the default host model (hardware irrelevant). Over TCP it's a non-start even if the host accepts as it can't predict the sequence number.
    – Joshua
    May 19, 2014 at 17:16
  • @Joshua - yes, the TCP thing was exactly my point, you can't establish a connection on TCP and can't get any responses on UDP, even should the host accept it in error. May 19, 2014 at 17:18
4

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.

2

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.

4
  • For reference BitTorrent sync, is not torrents. Well not in the sense of "Download the warez, moviez, etc". it is for synchronizing your files. If those files are sensitive, it is actually a big deal. Sensitive data can be worth much more than the machine it is being stored on. May 24, 2014 at 7:42
  • In that case encrypt it before you sync. If you're hiring your server then any Tom, Dick and Harry working at the data center can poke through your files. May 27, 2014 at 8:56
  • You are not hiring a server, it is distributed file synchronisation. You might want to understand the technology\. That said, encrypting the files is probably still worth doing. May 27, 2014 at 12:27
  • I assume OP is renting a VPS or something and not hosting his own internet facing server from home but ok. Sorry for the assumption. May 27, 2014 at 12:53
2

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.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .