Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

I was checking the article hosts file on Wikipedia, and I found this:

Blocking access to servers of unwanted content by redirecting them to the local host (127.0.0.1) may have security implications. As 127.0.0.1 is accessible only by the host itself, connections might be trusted. The link to be followed may be crafted to launch an attack on the local host.

Although it does not cite any reference, I wonder if this is true.

I thought about using hosts file to block some web bugs and trackers. Is this safe or not?

share|improve this question

migrated from superuser.com Feb 13 '12 at 13:29

This question came from our site for computer enthusiasts and power users.

4 Answers 4

My guess it that the Wikipedia author is referring to IE Security Zones, where the DNS name or IP address grants additional functionality to things like

  • ActiveX controls
  • Javascript
  • Execution of non-signed data
  • Access to internal (read corporate file server) data.

More info here

share|improve this answer
2  
+1 This makes sense. (I'm not a IE/windows user). But additionally, wouldn't the attacker have to (a) get the 'ActiveX / javascript / non-signed executables' on to the client system and (b) install/turn on some service on the client machine to serve those activeX / javascript when a request for http://malicioussite.com/malicious.js gets translated to http://127.0.0.1/malicious.js (e.g., install apache2 to serve malicious.js on localhost)? (At which point, this is more dangerous than finding malicious.js on the web as IE designates its trusted as it originated from localhost). –  dr jimbob Feb 13 '12 at 16:02

Imagine you are running a network service (e.g. HTTP) on your local machine. This is bound to both the loopback interface (127.0.0.1) and an internet facing interface (80.1.1.1).

Now say you have a script on your machine that an attacker knows can be used to perform administrative tasks, but only if performed by an administrator.

The presumption is that your script only assumes the visitor is an administrator if they are connected from the server itself. An administrative function can be called using GET variables, like: http://127.0.0.1/?droptable=foo&setpwd=bar.

If a user tried to do this from the internet, the script could see that the connecting user was on a foreign IP and it would return with, say, HTTP 403.

Now you are browsing the internet on your server (silly you). You click on an attackers link whose domain name has been associated with something dodgy, and so it's in your hosts file. Now instead of this link taking you to http://blockeddomain.com/?droptable=foo&setpwd=bar, your own hosts file ensures that http://127.0.0.1/?droptable=foo&setpwd=bar gets loaded instead.

Your database tables are dropped and the attacker compromises your authentication mechanisms.

Of course this is a very basic example and it requires many assumptions to be made. However this is one real world possibility of how such a setup could cause you a headache.

share|improve this answer
1  
Good answer. However, there's nothing stopping those attackers from building a link to http://127.0.0.1/ or http://localhost in the first place. I suppose the difference would be that upon inspection of the link it will become more obvious than someevildomain.com though. –  Yoav Aner Feb 13 '12 at 14:26
    
Thanks Yoav, my first go though! –  deed02392 Feb 13 '12 at 14:29
2  
You should not use a client's IP address to restrict access to sensitive functionality as anything but a redundant line of defense. Client IP addresses can be easily changed in http request headers; the only problem with doing so is that the client won't receive the responses from the server. (But if they are trying to just delete information, that isn't a problem.) Furthermore, you should never have a password in a URL or its query (these are typically logged in the browser history and webserver logs), and you should never transmit passwords over http cleartext. –  dr jimbob Feb 13 '12 at 15:01

I don't see any danger if you are the one setting up your own /etc/hosts to block specific web bugs/trackers; however, I can easily imagine a scenario where an attacker can use /etc/hosts to redirect to localhost to do some malicious things.

For example, let's say an attacker designs a malicious clone of a web site (like amazon.com) and install it on a local webserver and edits /etc/hosts to redirect to amazon.com to localhost. A user on that computer going to amazon.com would not know the difference and likely would input confidential information to the malicious web app running on localhost (that may say send off that confidential information to elsewhere).

I wouldn't worry too much about redirects to localhost being 'trusted'; using a client's IP address as a means of authentication to give them privileges to alter information is a mistake in the design of a web app.

share|improve this answer
    
The question as I understood it, was about the risks associated with changing your own hosts file and pointing known malicious hostnames to your localhost (as a way to block yourself from accessing those malicious sites). You say that you "don't see any danger if you are the one...". There is however some danger, as I believe deed02392 articulated in their answer. I don't disagree that the danger of external malicious modification of your hosts file is probably far greater, but I wouldn't say there is no danger in altering your own hosts file in this way. –  Yoav Aner Feb 13 '12 at 15:34
    
@YoavAner - For deed02392 attack to work, you need (a) a client browsing to the webbug from a production server (shouldn't happen), (b) the webbug site to know of a specific URL that is a security hole in your application when accessed from localhost (very insecure design), and (c) the webbug site doesn't exploit it directly by using http://127.0.0.1/?delete=data&security=none in their bug (which would always work), but instead decides to use http://malicioussite.com/?delete=data&security=none which only works if you used /etc/hosts to redirect malicioussite.com to 127.0.0.1. –  dr jimbob Feb 13 '12 at 15:55
    
If you're worried about attackers editing hosts files to phish, then you should probably worry about DNS search paths more since they're a single point of failure. The only thing that the ability to edit hosts gets you over DNS search paths is that someone who is careful to go to http://amazon.com./ instead of http://amazon.com/ will fall afoul of hosts routing when they would be safe from DNS search path manipulation. –  Mike Samuel Feb 13 '12 at 21:03

Perhaps this is a better solution. Instead of using 127.0.0.1 in the hosts file, wouldn't the net effect be the same - yet safer - to use 0.0.0.0

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.