This week will look at what to me seems like a less well known form of DoS attack, DNS poisoning. This attack is more dangerous than the others we have looked at before because it can not only prevent users from accessing a services, it can lead them to a fake version of the service and ask for sensitive information. There are many methods for this attack, such as grabbing packet in a MITM attack and altering them. An example of this method which can be executed over wireless networks can be seen in the video below:
As mentioned in the video, the process of reading packets, checking for a specific field, editing it and re-injecting the packet requires ‘a half-way decent computer’.
The DNS cache poisoning attack, first released by Dan Kaminsky, actually poisons the source of the IP addresses the target computer is looking up. This way no real time injection or modification is required and a whole subnet can be attacked through their DNS server. Bind, the most common
The patch included in BIND 9.4.2 provided defense by randomization of listening port.
However, this is only a partial fix, Liu warned. “Port randomization mitigates the problem but it doesn’t make an attack impossible,” he said. “It is really just a stopgap on the way to cryptographic checking, which is what the DNSSEC security extensions do.
An example of DNS server cache poisoning effective prior to the port randomization patch can be seen below:
So why did this vulnerability come about?
As with many aspects of the internet, convenience rather than security was the priority. The internet could function with just the root name servers that store IP addresses entered by an administrator. Every time a user wanted to view a site or service associated with that domain name they could ask the root nameserver to send the relevant address. This would however mean a great deal more DNS traffic clogging up networks and causing bottle necks at the authoritative name servers. So, we create name servers that are below the authoritative name servers, they store the IP addresses from the first time they are asked to check them, until the expiry (TTL) value of the records they retrieved. Kaminsky’s exploit waited for a target DNS server to re-check the IP addresses for a domain name, sending a falsified response to the name server.
Kaminsky’s blog post on the vulnerability can be found here: http://dankaminsky.com/2008/07/09/an-astonishing-collaboration/