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

• Previous message: Robert Tracz: "Re: CAIS-ALERT: Vulnerability in the sending requests control of BIND"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]

Date: Fri, 29 Nov 2002 21:12:52 -0300 (EST)
From: Vagner Sacramento <vagner@natalnet.br>
To: Iván Arce <iarce@core-sdi.com>

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

• Next message: Martin Schulze: "[SECURITY] [DSA 201-1] New Free/SWan packages fix denial of service"
• Previous message: Robert Tracz: "Re: CAIS-ALERT: Vulnerability in the sending requests control of BIND"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]