Attacks surrounding /etc/hosts/

Question

Although /etc/hosts/ is a file that comes up a lot in security, I am surprised to find there is no discussion here on this forum that describes how this can be used for an attack.

Thinking about it, I find myself, slightly unclear about what an attacker can achieve from this.

Few things that I can think of are :

1. Add a new entry say : "127.0.0.1 google.com" to mount a DoS to prevent access to google.com
2. Delete the hosts file to prevent any kind of network communication ?

3.Spoof an website " bank.com"

Are there any known attacks that particularly target /etc/hosts ?

What other possibilities are there ?

Answer 1

The main reason that /etc/hosts (or the windows equivalent %SYSTEMROOT%\system32\drivers\etc\hosts ) are used by attackers is to redirect user traffic to sites under their control. It's important to note that hosts files are used in preference to DNS servers, so even if the user has a good entry in DNS for a specific system, hosts will still take precedence.

In terms of where this has been used, banking trojans have made use of attacks on hosts files to effectively send customers to fake banking sites, which appear to use the correct host name (e.g. this one). However in general if the attacker can modify hosts, things like MITM attacks become much easier as the victim will transmit traffic directly to a machine of the attackers choosing without any other intervention.

Answer 2

I'm going to write this from an attackers perspective.

hosts is usually only writable by root (-rw-r--r--), at which point you already have achieved write access as root and have better options, like adding your SSH key to authorized_keys. Additionally, and I am not sure of this, for hosts to apply, you need to restart networking (which makes it a bad attack for servers, because those can have very, very long uptimes). It also shouldn't make networking fail, after all, it's just a simple layer in front of the DNS query mechanism. Again, I'm not sure about this.

TLS connections will generally fail (there goes your bank.com spoof) and injecting packets into apt/similar package managers will fail aswell, as those are signed aswell.

All in all, it's a very simple attack vector for very simple purposes. Given you have write access as root when this attack is possible for you, you might rather want to hijack apt with a custom source and make them install a rootkit along with a kernel image update or something along those lines.