The advantage of this software is that BkavDNSCheck could solve the limitation of Dan’s Tool (http://www.doxpara.com). BkavDNSCheck is able to test exactly the specific DNS Server which we want to check, while Dan’s Tool could only test the last top DNS server (not owned by the checker - DNS administrator).
 
Together with launching the software, Bkis has published some articles on how to apply patch against this flaw for vulnerable systems, thus keeping DNS systems away from a hazardous large-scale attack. These may help ISPs to check their DNS systems. We also provide the article of the tool to local press in order to guide administrators to check and patch their systems.
 
Please, read the following: http://security.bkis.vn/?p=75  for reference.
 
If you find it’s usefull, please provide it to whom may concern
 
Thank you and best regards,

That is very interesting and I have studied this.

yanky, I do not understand most of your points. :) sorry mate.

No really, quote from the RFC: “This document recommends the use of UDP source port number randomization to extend the effective DNS transaction ID beyond the available 16 bits.”

But DNS applications developers didn’t respect that. That’s where the vulnerability is.

2. “It has something to do with sending fake/forged responses to the attacked namerserver ”

No, the attacker must know the DNS server in order to change the source address of the malicious packet. The packet is sent to the victim.

3. “The attacker must know in advance or can predict the transaction ID”

Yep, we got 2^16-1 possibilities, but in fact the transaction ID is incremented by 1 for each new request. So if we know a TID sent by the victim, this can be done easily.

4. “It is probably something that can happen but it may not work well for high profile domains such as google.com”

Why not ? The cache is deleted for each reboot on XP.

5. “The attack is remote so we can eliminate man-in-the-middle attacks.”

What if I redirect a domain to my own ip address ? And for each request sent to me, I sent a request to the true domain, then I show the response to the victim. Acting like a proxy.

6. The vuln was found many years ago and published, but no one cared about it. The solution reduce the probability … but what if I have a lot of computer.

7. Journalists said something like “OMFG they can hack us !” … Oh excuse me, but, is there anything new here ? :)

But, fact is DNS is insecure by design. Doesn’t mean I am interested in the actual release of details though.

I was politely asked by Dan to discontinue this conversation and I respect that. I suspect that it is not because my thoughts are any closer to the real thing but mainly because he doesn’t want to cause too much chaos. So we will wait until BH and will see what is going to happen.

cheers

If he had the resources to mass spoof 3 nameservers X amount couldn’t he mass spoof 1 nameserver 3X amount (disregarding packet loss).

It doesn’t seem that advantageous. Now, I have little experience with DNS, so I may be wrong; there are not that many nameservers in each recursive chain to make the whole system fundamentally flawed. I believe Dan is leveraging this in some other way.

What do you think, PDP?

this means that Dan spoofs responses for the first or any other DNS server of the recursive chain. I suspect that he might do something like a mass spoof for each ns server of the chain, thus increasing the chances of getting the right transaction ID.

My take is that Dan is simply blasting all the name servers in the recursive chain until one of them has a transaction ID that matches any of his requests. I suspect, although I haven’t tried, this is very much doable.

I personally believe this is the key.