Re: DNS Guess 2 for the day

[Petja van der Lek <lek () xs4all nl>]

For a moment, I thought that I've witnessed what we in the business call 
a "Bingo!" moment -- until I ran some experiments. Now, I'd hate to 
contradict the list owner (much less so on my very first post), but bear 
with me. If I turn out to be horribly mistaken, feel free to flog me 
mercilessly, call me a little girl, or something similar.

The problem with the thesis: the transmission ID of the query from the 
client to the resolving name server is not retained in the related 
outgoing non-recursive queries sent out by that name server.


What I did: create an NS delegation record in one of the DNS zones under 
my control, and have it point to the address of the client I ran the 
tests on. That way, I could monitor both the outgoing DNS queries and 
the attempts of the public DNS servers to resolve said query.

Next, I fired off queries for the newly created subdomain to some of my 
friendly unpatched neighbourhood name servers. The constant query port 
shows that we're dealing with unpatched servers. Some Wireshark data 
(83.137.150.2 is the name server being tested, 32967 is its query source 
port):


  1 0.000000  192.168.1.65  83.137.150.2  DNS Standard query A 
aaargh.dnstest.lekdevil.nl

Internet Protocol, Src: 192.168.1.65 (192.168.1.65), Dst: 83.137.150.2 
(83.137.150.2)
User Datagram Protocol, Src Port: pptconference (1711), Dst Port: domain 
(53)
Domain Name System (query)
     [Response In: 17]
     Transaction ID: 0x0006
     Flags: 0x0100 (Standard query)
     ...

  2 0.012301  83.137.150.2  192.168.1.65  DNS Standard query A 
aaargh.dnstest.lekdevil.nl

Internet Protocol, Src: 83.137.150.2 (83.137.150.2), Dst: 192.168.1.65 
(192.168.1.65)
User Datagram Protocol, Src Port: 32967 (32967), Dst Port: domain (53)
Domain Name System (query)
     Transaction ID: 0xb261
     Flags: 0x0000 (Standard query)
     ...


In this case, the TID of the recursive query is 0x0006 and the TID of 
the non-recursive query by the name server is 0xb261. Repeated tests 
show that the two TIDs are different from each other every time. So it 
seems like a name server generates a new TID for each query it sends out 
(with the exception of retransmissions). The aspiring evil spoof 
overlord wouldn't have control over the server TID, and thus wouldn't 
know which one to use in its spoofed reply.

Now, were a name server to retain and reuse the TID received from a 
client in its corresponding outgoing queries, the possibility of a 
collision of TIDs from queries received from separate clients would be 
small but non-negligible on a busy name server. Such a collision could 
ruin the server's whole day, I presume, and make for a pretty broken 
design. I know it's BIND we're talking about, but still...


So, do we still need to buy tickets to Black Hat, or am I about to be 
ridiculed by world+dog? Fire away.

Cheers,
Lek.

> From: Dave Aitel <dave_at_immunityinc.com 
> <mailto:dave_at_immunityinc.com?Subject=Re:%20DNS%20Guess%202%20for%20the%20day>> 
>
> Date: Sat, 12 Jul 2008 16:56:35 -0400
>
> So you don't really want to spoof the client. You want to spoof the
> resolver. So you pretend to be a resolver below it, and pass it along a
> fake request (with a TXID), and then immediately send him the spoofed
> response (since you specified the TXID) and his port is known. He then
> sends you the response (which is the one you spoofed him) and is poisoned.
>
> -dave

_______________________________________________
Dailydave mailing list
Dailydave_at_lists.immunitysec.com
http://lists.immunitysec.com/mailman/listinfo/dailydave
_______________________________________________
Dailydave mailing list
Dailydave () lists immunitysec com
http://lists.immunitysec.com/mailman/listinfo/dailydave