Examice

attacker.evil.org is attempting to insert a poisoned cache entry for www.moneybags on the dns.victim.com DNS server using the Kaminsky method of DNS cache poisoning. Of the following choices, which would be an example of an effective query sent by the attacker?

Correct Answer: C

Poisoning the cache -

With a good understanding of a properly-functioning DNS, it's time to see where things break. Cache poisoning is where the bad guy manages to inject bogus data into a recursive nameserver's cache, causing it to give out that bad information to unsuspecting local clients.

It's not so simple as just sending random DNS packets to a nameserver, as DNS only accepts responses to pending queries; unexpected responses are simply ignored.

How does a nameserver know that any response packet is "expected"?

✑ The response arrives on the same UDP port we sent it from: otherwise the network stack would not deliver it to the waiting nameserver process (it's dropped instead).

✑ The Question section (which is duplicated in the reply) matches the Question in the pending query.

✑ The Query ID matches the pending query

✑ The Authority and Additional sections represent names that are within the same domain as the question: this is known as "bailiwick checking".

This prevents ns.unixwiz.net from replying with not only the IP address ofwww.unixwiz.net , but also fraudulent information about (say) BankOfSteve.com.

If all of these conditions are satisfied, a nameserver will accept a packet as a genuine response to a query, and use the results found inside. This includes caching answers, as well as valid authority and additional data found there too.

But if the bad guy can predict and forge a DNS response packet that's just right, he can cause all kinds of shenanigans for the victims.

The bad guy normally first chooses his victim by finding a nameserver he believes vulnerable to poisoning: all of the clients of that DNS server get to unwittingly ride the victim train as well.

Then he finds a target domain, one he wishes to take over. His intent is to fool the victims into visiting his own malicious website instead of the real deal: by getting www.goodsite.com to resolve to the bad guy's IP address, the user's traffic visits the bad guy's website instead of the good one.

We noted that unexpected packets were simply dropped, so a bad guy need not get everything right every time: sending many packets attempting to guess some of the key parameters is likely to prove fruitful with enough attempts.

Guessing the Query ID -

In old nameservers (and in our detailed packet trace example), the Query ID simply increments by one on each outgoing request, and this makes it easy to guess what the next one will be as long as an interloper can see a single query.

We probably can't directly ask the nameserver for its query ID, but we can provoke it into telling us:

1. Bad guy asks the victim nameserver to look up a name in a zone for a nameserver he controls (perhaps test.badguy.com).

He might query the server directly, if it permits recursion from his location, or he might convince a user to lookup a name ג€" perhaps by including the test hostname on a web page.

2. Victim nameserver receives the request and makes the usual rounds to resolve the name starting at the root servers. Here, we've put the root and GTLD servers in the same category to separate them from the bad guy's nameserver.

3. Eventually, the victim nameserver will be directed to the bad guy's nameserver: after all, it's authoritative for badguy.com.

4. Bad guy monitors this lookup of test.badguy.com by sniffing the IP traffic going to his own machine, or perhaps even with a custom modification to the nameserver software, and from this discovers the source port and Query ID used.

At this point he knows the last query ID and source port used by the victim nameserver.

But the thoughtful might wonder: so what? This hasn't poisoned anything yet, and there's no need to engage in DNS shenanigans for badguy.com anyway. After all, the bad guy is already authoritative for his own zone.

Reference:

http://unixwiz.net/techtips/iguide-kaminsky-dns-vuln.html