[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.
Ryan
More information about the conspire
mailing list