MESSAGE
| DATE | 2008-07-25 |
| FROM | Ruben Safir
|
| SUBJECT | Subject: [NYLXS - HANGOUT] Re: [conspire] DNS vulnerability details
|
On Fri, Jul 25, 2008 at 04:44:32PM -0700, Rick Moen wrote:
> Quoting Ruben Safir (ruben-at-mrbrklyn.com):
>
> > With due respect, I fail to see how random outgoing ports will provide
> > more security,
>
> Because the man-in-the-middle attacker, posing as the queried
> recursive-resolver nameserver, has to send a forged response back not
> _merely_ with the correct QID (transaction ID), but also delivered on the
> correct port. If the delivery port for responses, the one used to
> originate the query, is always 53/UDP, then it's much easier to forge
> a credible fake response -- 2^16 QID value possibilites, rather than
> those permutations _plus_ 2^16 possible ports. ~32 bits of variability
> is better than 16, when you're trying to reject forged data.
>
The first client resolver request sends to DNS.myserver.com on port 53
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.
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.
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.
freeswan had opputunitic tcp cryptography at one time. I wonder what became of it.
Ruben
> > The server is still listening on a single know port and send responses
> > from a random port (one that is hopefully not being used for vnc) but
> > to connect to a known client port.
>
> The _queried_ server is not the problem. The problem resides with the
> recursive-resolver nameserver that's doing the asking: It's far too
> easy for an imposter to send it credibly faked responses -- that, in
> turn, can be used to poison the querying nameserver machine's cache.
>
> That is why the problematic scenario is a recursive-resolver nameserver
> that sends _its_ recursive-resolver requests always on UDP port 53, that
> _also_ caches received data. (It also explains why processes that send
> out recursive queries but don't cache the results -- libc's "stub"
> resolver and most "firewall" appliances' nameservers being obvious
> examples -- aren't a problem: You can send them poisoned information,
> but that information won't persist.)
>
>
> _______________________________________________
> conspire mailing list
> conspire-at-linuxmafia.com
> http://linuxmafia.com/mailman/listinfo/conspire
--
http://www.mrbrklyn.com - Interesting Stuff
http://www.nylxs.com - Leadership Development in Free Software
So many immigrant groups have swept through our town that Brooklyn, like Atlantis, reaches mythological proportions in the mind of the world - RI Safir 1998
http://fairuse.nylxs.com DRM is THEFT - We are the STAKEHOLDERS - RI Safir 2002
"Yeah - I write Free Software...so SUE ME"
"The tremendous problem we face is that we are becoming sharecroppers to our own cultural heritage -- we need the ability to participate in our own society."
"> I'm an engineer. I choose the best tool for the job, politics be damned.<
You must be a stupid engineer then, because politcs and technology have been attached at the hip since the 1st dynasty in Ancient Egypt. I guess you missed that one."
© Copyright for the Digital Millennium
|
|
