Bugtraq mailing list archives
Re: Thoughts about DNS...
From: vermont () GATE NET (Illuminati Primus)
Date: Sun, 27 Apr 1997 02:04:52 -0400
On Sun, 27 Apr 1997, Thomas H. Ptacek wrote:
There's a trivial and inexpensive denial of service attack associated with this method. I can prevent any nameserver employing this mechanism from ever being able to resolve "XXX.COM" by sending it a consistant stream of "XXX.COM" requests with random invalid query IDs. You mention this, but don't specifically state how it's done, so I'm simply clarifying. The attack is blind, doesn't require significant resources, and can be performed almost untraceably from any dialup connection on the net.
True, and I just thought up a solution: Once a server notices fake responses arriving, it can reattempt the lookup via TCP. Then we can be reasonably assured that we're talking to the real server.. Someone flooding us from a dialup modem will only cause our lookups to take slightly more time.
Also, what does BIND do when it's caught up in a query->invalidate->retry loop? Does it eventually give up and return NXDOMAIN? Does it cache the NXDOMAIN (thus allowing for a far more severe denial of service attack)? Does it hang indefinitely, allowing us to trick resolvers into thinking the nameserver is dead?
Well since we are dealing with these problems right now, we can be intelligent and not cache a host/IP as broken when we receive spoofed replies. I know BIND 8 wont cache unresolvable servers, so someone can only kill a domain as long as he can deny access to that domain's authoritative nameservers.
Can I tie arbitrary nameservers on the Internet up by employing this mechanism on multiple servers in parallel? What happens if I open up N recursive queries to a nameserver, following them up with a stream of invalid requests? Can I starve the nameserver of resources (some state is being allocated in BIND to cover each request)?
To protect against this we can refuse recursive queries from outside the subnets that the server is set up to serve, protecting us against outside attackers (providing routers were set up correctly)
The mechanism by which this is accomplished can be extremely simple - a flag set off by default that gets set on the first time an invalid query is received, and is turned off a configurable amount of time after the last invalid request is received. As long as the flag is set on, all requests must be completed with a "cookie" request to ensure the vitality of the queried servers.
I think connecting to the servers via TCP would be the better solution, since it is a capability built into almost every DNS server in existence. Cookies would have to be supported on the server that is being spoofed, or hidden somewhere in our queries (which is a bit of a kludge).
Although its not good to have even a small window of opportunity, what percentage of the ID space could someone cross by fully saturating a T1 with forged DNS replies before the requesting server times out theAssume every response to be 100 bytes long. I need 65536 queries to completely span the ID-space. This is 6400k of network bandwidth. On a heavily loaded T1, I manage 110 kb/s FTP, or roughly a minute to complete the entire attack. Remember, though, that there is /no window/ involved in schemes that rely entirely on the ID to prove authenticity of responses. Figuring out how to restrain a nameserver for 58.18 seconds is not a difficult problem. Bugs in BIND may make it a trivial problem.
No, the problem is managing to force enough forged responses down a server's throat before the lookup times out.. However, I didnt realized it would be that quick and easy. This is really a serious problem that should be addressed. (looking at bind code now) -vermont () gate net , mongoloid programmer
Current thread:
- Re: CPSN 4-970424: Possible buffer overflow in pop3d, (continued)
- Re: CPSN 4-970424: Possible buffer overflow in pop3d Derric Scott (Apr 27)
- Re: CPSN 4-970424: Possible buffer overflow in pop3d J. Joseph Max Katz (Apr 28)
- Re: CPSN 4-970424: Possible buffer overflow in pop3d Johannes Erdfelt (Apr 28)
- Re: CPSN 4-970424: Possible buffer overflow in pop3d Derric Scott (Apr 27)
- Overflow in xlock George Staikos (Apr 26)
- 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)