Hi Iván, >I understand your point but I think the problem remains >the same. I think you did not understand me yet. I am going to try explaining with more details. Before, I would like to know if you agree with me that the implementation problem of BIND that generate multiple simultaneous queries for the same resource record, allow the attacker to implement DNS Spoofing attacks remotely with HIGH probability of success using fewer packets (by several orders of magnitude) than the traditional brute-force approach would require. Ok or not??? It is this that being released in advisory. CERT opinion: "By rapidly generating multiple queries for an RR to a vulnerable resolver, the attacker can induce a condition whereby the vulnerable resolver has multiple open queries for that RR. The attacker then sends a number of spoofed responses to the vulnerable resolver. Given the right combination of open queries and spoofed responses, the attacker can achieve a high probability of success with far fewer packets (by several orders of magnitude) than the traditional brute-force approach would require." First: My attack methodology I am describing a probabilistic method that significantly improves an attacker's chances of successfully to implement DNS Spoofing attacks with a relatively small number of packets sent. Using this method, an attacker would have a 99% chance of compromising a vulnerable name server running BIND 4.x and BIND 8.x with less than 1100 total packets. I do not need send many packets to implement the attack with high probability of success. The bind and other DNS implementations current have vulnerabilities that allow the attacker to implement attacks remotely with VERY, VERY facility. The bug is in this file: src/bin/named/ns_forw.c as I said in the last message. CERT Analyses: "The only distinction between this attack and the traditional brute-force approach (1 query with multiple spoofed replies) is the generation of multiple simultaneous queries. The attacker need not sniff any packets between the victim resolver and the legitimate nameservers for the RR being spoofed. An attacker's success against any particular resolver instance will be probabilistic in nature, with a persistent attacker always being able to achieve a reasonable probability of success given enough attempts." "By rapidly generating multiple queries for an RR to a vulnerable resolver, the attacker can induce a condition whereby the vulnerable resolver has multiple open queries for that RR. The attacker then sends a number of spoofed responses to the vulnerable resolver. Given the right combination of open queries and spoofed responses, the attacker can achieve a high probability of success with far fewer packets (by several orders of magnitude) than the traditional brute-force approach would require." I say again: If the ISC and other vendors correct their code, they significantly will reduce an attacker's chances to implement the attack REMOTELY. Do you agree with me? Of course, all DNS implementations are vulnerable to attacks via brute force. * Second - Attacks brute force Attacks brute force is possible. All We know of this. However, this attack is VERY difficult to be implemented REMOTELY on DNS implementation that uses random algorithm. I am affirming this because the attacker has to send millions of replies with IDs and source ports different into a time very short (~ 90ms). In most cases, the response from the legitimate nameserver will arrive long before the attacker has the opportunity to send that many packets. The attack is possible ONLY if spoofed response, which correct ID will be received before ANY of responses from legitimate DNS server. My attack methodology describes a method that dramatically reduces the number of packets required to make the chances of successful cache poisoning high. This is an excellent paper that describes the average time necessary to resolve a domain name: Performance and the Effectiveness of Caching. MIT Laboratory for Computer Science. Proc. in ACM SIGCOMM INTERNET MEASUREMENT WORKSHOP. 2001. There are several limitations to implement this attack REMOTELY via brute force. You only will know the limitations if you try to implement it. I am going to demonstrate the results presented by CERT during its tests. The CERT did an excellent mathematics model about the success probability of attack. http://www.kb.cert.org/vuls/id/457875 Wrote by CERT: "As expected, the traditional brute-force case where the attacker tries to guess the transaction ID or TID/port pair based on a single open request requires the attacker to search half the search space (15 or 31 bits, respectively) to achieve a 50% probability of success. However, when the attacker is able to induce the resolver into generating multiple simultaneous requests, the total number of packets required falls off rapidly." >Namely that there is a fundamental design flaw than makes DNS >vulnerable to cache poisoning either way: a 16bits space for >query IDs is NOT ENOUGH. You can predict them, brute force the >entire space or elaborate any other attack with a good degree >of sucess in any case. Any way you at look it, 16 bits and weak >authentication of reponses will just not do suffice to prevent >the problem. I agree with you, a 16bits space for query IDs is NOT ENOUGH. all we know of this >The attack in the cited 1997 SNI advisory show that source routed >packets or control of a primary nameserver is not needed since the query IDs >can be predicted almost blindly. I say again: This is very easy, because the Bind running with these versions (4.9.5, 4.9.6 and 8.1.x) increase the ID by 1 for each query. BIND Versions current (8.3.4, 4.9.11) are not vulnerable to the attack presented in this advisory (SNI advisory). I implemented this attack methodology and I tested its limitations. >Yes, that's in the 1997 advisory, but EVEN if he doesnt get the IDs >he can blindly send responses with different IDs hoping that >one will match the query ID of the DNS request. In practice, brute force attacks is not so easy or simples. >This is obvious.. uh guess what the source IP address should be? >If I am trying to point www.microsort.org to my own IP, the source >IP address of my spoofed DNS responses should be that of microsort.org's >primary nameserver. It will be this if you knew the moment that DNS target sent a request to microsort.com's primary nameserver. The DNS Target is going to send request to the .root servers.: root-servers.net or gtld-servers.net and other, then it is going a request to microsort.com's primary nameserver. In my attack I try identify the possible DNS requested. I noticed that this way I have more success.. Then I explain this with more details. >The probability of sucess is exactly: > m-responses-sent/65535 >If I sent 65535 DNS responses with a different ID on each one one of them >will hit the right ID. NO. No. I NEVER send more than 3000 replies. If you sent 65535 DNS responses with a different ID on each one do not guarantee that you are going success on attack, other thing, this is a brute force attack. >> Only THIS. The problem is in the BIND implementation. The ISC think not. >No, the problem is in the protocol. The fact of BIND generates multiple simultaneous queries for the same resource record is not problem of DNS protocol. Do you agree with me? Regards, Vagner Sacramento
