RE: CAIS-ALERT: Vulnerability in the sending requests control of BIND

[Vagner Sacramento <vagner () natalnet br>]

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