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

[Iván Arce <core.lists.bugtraq () core-sdi com>]

Hi Vagner,

I understand your point but I think the problem remains
the same.

What I am saying is that the attack you mention is a variation
of the something known for years as a result of discussing a fix
for the predictable sequence ID problem, which in turn was triggered
by the SChuba and Spafford paper of 1993.

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.

> At first site It may looks like the vulnerability reported cited by you,
> but in fact It isn.t.
>
> The CERT did the same question when we were doing tests. Of course, if was
> the same attack released in 1993 the CERT had not released a Vulnerability
> Note.
>
> http://www.kb.cert.org/vuls/id/457875
>
>
> > Original advisory posted in 1997:
> >
> > http://www.codetalker.com/advisories/sni/sni-12.html
> > http://www.corest.com/common/showdoc.php?idx=133&idxseccion=10 (spanish)
>
> I know this attack methodology. Christopher Schuba and Eugene Spafford
> outline this attack in the paper "Addressing weaknesses in the Domain Name
> System Protocol" in COAST Laboratory, Department of Computer Science,
> Purdue University, 1993.

The attack outlined in Schuba and Spafford paper calls for the attacker to
control a primary nameserver or to use source routed packet.

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.

This triggered discussion on how to fix the problem back
in 1997, and as the comments on the patch for the then
current BIND version suggest, there is no way to
fix the problem because even if you randomize the query
IDs, there isnt strong authentication of responses
(crypographically strong, that is) and even if there
was, 16 bits is just not enough to prevent sucessful
exploitation.


> This attack is the simplest and most widely used attack to do DNS Spoofing
> on bind 8.1.x, 4.9.3, 4.9.5 and 4.9.6. Bind running with these versions
> increase the ID by 1 for each query. They don.t randomize the dns id. This
> is a problem of pedictable ID's and not the problem that I reported.
>
> The algorithm initially used to generate ID in BIND 8.1.x and 4.9.[3-6]
>
> u_int16_t nsid_next()
> {
> !       if (nsid_state == 65535)
> !               nsid_state = 0;
> !       else
> !               nsid_state++;
>         return (nsid_state);
>   }
>
> :-), :-)

OpenBSD produced unpredictable query IDs since 1997 using BIND-4.9.5-P1,
why ISC and the "official" BINd did not incorporate this and kept
using predictable IDs up till 8.2.x escapes my understanding.


> BIND Versions current (8.3.4, 4.9.11) and older (8.2.x, 9.x) are not
> vulnerable to the attack presented in this advisory (cited by you).
>
> However, I get to implement DNS Spoofing attacks remotely with very easily
> in the bind 8.3.4 ,4.9.11 and older bind, and I can prove THIS.
>
> The problem that I described attests BIND versions 4 and 8 do not prevent
> sending of two or more resolution requests for the same domain name
> allowing DNS Spoofing attacks with significant probability of success,
> then I implemented specific techniques (originals) to have good results in
> the attacks.

Even if you prevented this you what very good sucess probabilities


> In the link cited by you, the attacker has complete control of
> DNS.ATTACKER.COM's network, he can both spoof and sniff DNS packets there.

No, he has complete control of his own box, in order to spoof/sniff
one only needs to be root on your favourite Linux system or
Administrator on Windows, etc.

> In particular, he can sniff DNS packets sent to DNS.ATTACKER.COM. The
> attacker needs to get the IDs to send the replies.

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.

> The attacker sniff DNS.ATTACKER.COM's local network and retrieve the query
> packet
> sent by DNS.TARGET.COM to DNS. ATTACKER.COM.  He can then determine the
> query ID (qid0) and source port used by DNS.TARGET.COM. Chances are that
> the next queries generated by DNS.TARGET.COM will have query IDs that will
> fall in the range [qid0,qid0+N] where N is dependent on the amount of
> queries DNS.TARGET.COM is generating in the period of time on which the
> attack takes place. N is usually <= 15 for most cases.
>
> In this attack methodology (released by Schuba) is not implemented
> anything to determine the source IP address that should be used in the
> reply packet because the attacker get the victim DNS current ID (sniffing
> technique) and other.

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.


> In my attack methodology, I implemented techniques to determine ID, Source
> IP address and the attacker can apply the attack successfully FROM any
> network. The attacker does not need to be at  the same DNS.ATTACKER.COM's
> local network. The attacker does not NEED to sniff queries to determine
> the source port and ID.
>
> The success probability in my attack methodology to implement of DNS
> Spoofing attack in BIND 4 and BIND 8 is calculated by the equation:
> n-request-sent/65535, where n-request-sent is the number of requests sent
> simultaneously to the target DNS server.
>
> Another difficulty that I have in the remote attack is to imprecision from
> establishing the ID to be used in the replies. In example presented, the
> attacker doesn.t have difficulty because the his host keeps capturing all
> packets in its local net, applying a sniffer technique. ;-):-)
>
>
> > +  /*
> > +  * The 16 bit space is very small and brute force attempts are
> > +  * entirly feasible, we skip a random number of transaction ids
> > +  * so that an attacker will not get sequential ids.
> > +  */
> Using only brute force, the attack is very difficult to be applied. I
> tried this several times. I did several tests in my experiments. The
> probability of success is very low to get implement the attack using only
> brute force.

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.

The attack is basically the same.
Either you sent N spoofed requests or you send M spoofed responses.
The network traffic generated is also the same and in both cases
there is still a race to win against the real DNS.

> > BTW, what does BIND 9 do to prevent this?
> The BIND 9 doesn.t generate multiple simultaneous queries for the same
> resource record.

This does not prevent exploitation

> Only THIS. The problem is in the BIND implementation. The ISC think not.

No, the problem is in the protocol.


> However, you can see and analyze that an only code line resolve part of
> the problem. Of course It does not resolve problems of brute force
> attacks, but resolve the problem that I reported.
>
>    || (!strcmp(qp->q_name,dname)) )
>
> If the ISC and other vendors correct their code, they will reduce almost
> 98% success probability of an attacker to implement the attack remotely.
> The 2 % is attacks successfully via brute force.

Perhaps a better fix  would be not generating multiple queries for
the same resource record AND invalidating pending outgoing requests
when a thresold of responses with invalid QIDs is reached. However,
this also opens the door for a DoS attack...


> > > . configure anti-spoofing rules on the firewall or border router;
> > >
> > >  . considering the network topology, set up the DNS server into a DMZ
> > >   (demilitarized zone).
> >
> > Maybe I am missing something but how will this prevent cache poisoning
> > of the DNS server in  the DMZ? (assuming it does recursion)
> > Inbound DNS replies (with spoofed source IP address) to
> > DNS requests forwarded to Internet servers will look perfectly valid to
> the
> > border router or firewall.
>
> This way (DNS in the DMZ), you can to dropp packets sent to your DNS that
> are using spoofed source IP address of your local network. This is the

Yes but you dont need to spoof internal victim's addresses to
force the DNS to send queries.

Also, this is specific to the attack you described, if what you
spoof are the DNS responses as if they were coming from the
real DNS servers that the victim queried, theres nothing the firewall
can do, unless it was a stateful DNS proxy that matches inbound QIDs
in the DNS responses to outbound QIDs of DNS requests.

> first step to implement attack. The attacker has to do the target DNS
> server to generate multiple simultaneous queries for the same rr. If you
> has configured this option in named.conf:
> allow-query{IP-internals;};  the attacker will try use IP-internal to
> generate the queries for the same rr.

Which is completly feasible.
Anti-spoofing at the border does not prevent the attacker from
forcing resolver queries fromthe victim to her DNS from perfectly
legitimate hosts at the victim's network, which  in turn will have
the DNS recurse and go out to the Internet to find out about IP
addresses of unknown hosts.

> I can assure that I get to implement DNS Spoofing attacks with high
> probability of success with very facility in BIND 8.3.4 and 4.9.11
> (Released November 16th, 2002 by ISC)

I have not doubt whatsoever about that!

> Iván, thanks by observations.
>
>
> Regards,
>
> Vagner Sacramento

-ivan


---
Perscriptio in manibus tabellariorum est
Noli me vocare, ego te vocabo

Ivan Arce
CTO
CORE SECURITY TECHNOLOGIES

44 Wall Street - New York, NY 10005
Ph: (212) 461-2345
Fax: (212) 461-2346
http://www.corest.com


PGP Fingerprint: C7A8 ED85 8D7B 9ADC 6836  B25D 207B E78E 2AD1 F65A


--- for a personal reply use: =?iso-8859-1?Q?Iv=E1n_Arce?= <iarce () core-sdi com>