4

Many questions have already been asked about DNS cache poisoning (aka Kaminsky attack), however I couldn't find a clear answer to my question:

Is DNS cache poisoning possible in a LAN, without executing a MITM attack?

Clarification:

It is normal that DNS cache poisoning is possible during a MITM attack.

However, I don't see many topics revolving around a technique to cache poison a LAN, without executing a MITM attack (like the Kaminsky attack). I think it should be possible, as all DNS requests/replies are plain http, unencrypted. We should thus be able to see the request (including the transaction ID and exact port), and prepare a fake answer before a 'good' DNS server can answer the request. The attacker is on the same LAN as the target, and will thus be much faster to response than another DNS server outside the LAN.

Is such an attack possible? I understand that it is easier to perform DNS spoofing during a MITM attack, I just want to know if it would be practically possible to cache poison clients on a LAN by winning the DNS response race without having executed a MITM attack.


Note: this is not a question about how the Kaminsky attack was prevented (transaction ID and port randomization)

2

Yes this is possible, although better attacks are available too.

DNS cache poisoning is possible through a number of methods, the Kaminsky attack being just one of them. The reason that the Kaminsky attack got so much interest is because you do not need to be on the same LAN. You could attack a DNS server half-way round the planet.

It is well established that you can tamper with traffic on the same LAN as yourself - unless that traffic is protected by encryption. Most tools (e.g. Android Network Spoofer) use ARP poisoning in combination with DNS poisoning, because that is the most reliable method. In principle you could do DNS poisoning without MITM, just as you propose, but it would be less reliable because you are relying on a race condition.

And that's why you don't see much discussion of your proposed attack. In any practical situation you have better options.

4

DNS requests and replies are not HTTP; they are... DNS. See the standard. Most of the time, DNS requests and responses use UDP: the request is a single IP packet, and so is the response.

With UDP, each packet is identified by:

  • the source IP address
  • the destination IP address
  • the source port
  • the destination port

A DNS request from client C to DNS server S will use C's IP address as source, S's IP address as destination, a random port value p as source port, and 53 as destination port (the standard port value for the DNS server). The DNS response will use C's IP address as destination, S's IP address as source, 53 as source port and p as destination port. The client will accept the response as "correct" because it uses p as destination port, the same p as the one used by the client as source for its request.

An attacker who wish to feed fake DNS information to the client C can know C's IP address and S's IP address, and can make a good guess about the moment the client will send its request. The attacker's goal is to send a fake DNS response, claiming to come from the DNS server S, but containing. Without full eavesdropping access, the attacker cannot know the value of p, because he cannot see packets. However, port numbers are in a limited range (port numbers range from 0 to 65535, but the actual range for randomly allocated numbers is smaller, and depends on the involved operating system). Therefore, the attacker may just send a few thousands of spoofed IP packets, each containing the fake information, for all possible port p values. The client will drop all of them except the one using the correct p value.

The same concept can be extended to communications between DNS servers, because they talk to each other, and cache responses. It is often easier to pull off for the attacker, because he can trigger himself the DNS-to-DNS exchange, allowing a precise timing for his launch of his thousands of spoofed responses. When he succeeds at feeding fake information to a DNS server, then that DNS server is said to be poisoned.

This sort of things is relatively easy even for low-tech attackers who don't have eavesdropping abilities, let alone interception power as would be required for a true MitM between the client and its DNS server, or between DNS servers. The reason which makes it easy is the use of UDP, which implies that the attacker knows everything except the random source port, which lives in a small range. If the two DNS servers talk to each other over TCP, then the attack is more difficult, because injecting fake data in a TCP flow implies guessing the connection sequence numbers, which are randomly chosen in a 32-bit range: the "thousands of packets" have become "billions of packets".

  • Thanks for pointing out that DNS indeed does not use HTTP. – Michael Feb 12 '14 at 21:56

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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