Bugtraq mailing list archives
Re: Thoughts about DNS...
From: tqbf () ENTERACT COM (Thomas H. Ptacek)
Date: Sun, 27 Apr 1997 04:19:40 -0500
Its more dependable than trying to depend on some type of cookie hidden in areas that arent guaranteed to come back unmangled
Perhaps we're not in sync with each other. I get the impression that my "cookie" idea (probably because I use the term "cookie" to describe it) is being assumed to be something more complicated than it is. All the "cookie" consists of is a totally standard DNS query. It could just as easily be an A record query for SPLOITS.CERT.ORG as it could be a type 212, class 13 query for DF97H37F74H4H3778FGH3F747.74TF784GF84GF4. The point, of course, is simply that it's not trivial to guess, and we'll only get a response back if the server we query is alive. Under what circumstances would a 1 question nonrecursive query ever be "mangled"? Is there a nameserver out there that destroys the question section of DNS packets?
Well, if the tcp connection also fails, we can return failure and try again later.. So each lookup request that the attacker generates will give
If the TCP connection fails, it will never work. There's a chance that it will fail, because servers don't necessarilly *have* to allow TCP DNS (firewall configurations, for instance, might make this impossible). On the other hand, nothing should cause a simple UDP query to fail. It also doesn't require connection setup (how will this affect latency?).
sysadmin noticing all of the logs spewing out.. Again, the best protection would be cryptography
Yes, this is of course true, but it's probably not reasonable to expect the entire Internet to switch to a cryptographically secure DNS protocol overnight.
That doesn't work. This is a blind attack; I can make the queries come
You can probably configure what addresses you'll accept recursive queries from in the bind config also.. Ill check it out
That doesn't work. This is a blind attack. I can make the queries come from wherever I want them to. Eliminating recursive queries is not, from what I can see, a valid solution to this problem. Am I wrong?
TCP-ready BIND servers are probably 99% of the internet. However, if you
I don't set firewalls up to accept incoming TCP connections to port 53. At the very least, every firewall I've configured is now broken.
find that cookies work more reliably, then that would be the superior solution. It certainly has more room for strange failures though
You seem to think that there's alot of weirdness happening here. I don't think there is. Can you come up with some specific things that can cause weird failures? I'm not doing *anything* weird with DNS packets - I'm just sending queries for information I don't care about.
The same with the cookies, except over a larger range of ID space. Also:
That larger range of DNS space is how many bits of random data, now? =) If the DNS cookie solution works reliably, guessing cookies is no longer a feasible attack, nor is brute-forcing cookie-space. The only attack remaining is the race condition against the 16 bit ID. However, I have to grant you that if a TCP connection is successful, you've eliminated the problem entirely - you just finish the request over TCP, and you know that you're getting reasonably authentic information back. Unless, of course, I can predict the sequence numbers involved in setting up the connection, or otherwise subvert the connection to fail or be spoofed...
what do you do if a server doesnt return your cookies? Return a failure?
If a server doesn't return my cookies, it's dead. Try the next server. Continue until SERVFAIL.
Well, with the method I am proposing, a DOS attack will only be possible if port 53 is unavailable on the authoritative nameservers for the domain
How hard is that? SYN SYN SYN SYN SYN SYN SYN SYN *cough* *gag* Again, we now have denial-of-service coupled with security; the attack only needs to work once.
that is being blocked. So the problem no longer lies in your nameserver, it is now a problem of the site being blocked for whatever reason, and would have to be fixed on that end. What else can be done on our end?
Our security shouldn't rely on any site's servers working. ---------------- Thomas Ptacek at EnterAct, L.L.C., Chicago, IL [tqbf () enteract com] ---------------- "If you're so special, why aren't you dead?"
Current thread:
- Re: Overflow in xlock, (continued)
- Re: Overflow in xlock David Hedley (Apr 27)
- Re: Overflow in xlock Bollinger (Apr 27)
- Re: Overflow in xlock Andrew G. Morgan (Apr 27)
- Thoughts about DNS... Thomas H. Ptacek (Apr 26)
- Re: Thoughts about DNS... Illuminati Primus (Apr 26)
- Re: Thoughts about DNS... Thomas H. Ptacek (Apr 26)
- Re: Thoughts about DNS... Illuminati Primus (Apr 26)
- Re: Thoughts about DNS... Thomas H. Ptacek (Apr 27)
- BIND ID Brute Force Fix Illuminati Primus (Apr 27)
- Re: Thoughts about DNS... Illuminati Primus (Apr 27)
- Re: Thoughts about DNS... Thomas H. Ptacek (Apr 27)
- Re: Thoughts about DNS... Illuminati Primus (Apr 26)