[conspire] DNS vulnerability details

Ryan Russell ryan at thievco.com
Fri Jul 25 17:11:54 PDT 2008

Ruben Safir wrote:
> The first client resolver request sends to DNS.myserver.com on port 53

And then dns.myserver.com turns around and asks some other DNS server a 
question using a random source port. That's the change. It used to ask 
this other server from port 53, or random port >1023, or with poor 
randomness. For most DNS servers.

> The server can open a new random port but sends data back to the client
> on 53 which then has information on which port to respond back to.
> and querry to the serve is going to go to 53 and wait for a response
> and the be told where to post to next.  Seems like a lot of oppurtunity
> to poison a servers cach still.  It might complicate broot force but
> nothing that can't be automated.

It can still be brute forced. The current effort is to make the work go 
from 16-bits (just txid) to ~32 bits, txid + 64K source ports.

> Of a man in the middle, nothing is encypted, and you "in the middle"
> so sniffing a DNS Servers ports should be not that hard.

We're talking about a blind spoofing attack, no sniffing involved.

> I suppose I'm not getting soething here.  I can't help but feel that until
> of criticle systems services are using cryptography, that we just continue to
> go in circles.

Some are proposing DNSSEC, which will bring many many bugs and new attacks.

> freeswan had opputunitic tcp cryptography at one time.  I wonder what became of it.

The kinds of DNS packet spoofing under discussion are of the UDP variety.


More information about the conspire mailing list