Dailydave mailing list archives
Re: DNS Speculation
From: natron <shiftnato () gmail com>
Date: Tue, 22 Jul 2008 11:38:59 -0500
Consider the following: The AUTHORITY SECTION in a response tells you that ns2.example.com is where you should look for www.example.com, but how do you know where ns2.example.com is located? The ADDITIONAL SECTION is the part that tells you. If you were to not include it, you would start the process over for ns2.example.com -- but would get stuck in a loop where the root server was telling you to go to ns2.example.com to find ns2.example.com's IP address. I can't think of any reasons why this would be used by anything other than looking up domain servers, but I would assume you can stick in a www. in that section and probably have it cached. (Haven't tested.) -n ;; QUESTION SECTION: ;www.example.com. IN A ;; AUTHORITY SECTION: example.com. 86400 IN NS ns2.example.com. example.com. 86400 IN NS ns1.example.net. ;; ADDITIONAL SECTION: ns2.example.com 172800 IN A 10.10.0.2 On Tue, Jul 22, 2008 at 4:42 AM, Alexander Sotirov <alex () sotirov net> wrote:
On Mon, Jul 21, 2008 at 10:24:11AM +0200, Halvar Flake wrote:Mallory wants to poison DNS lookups on server ns.polya.com for the domain www.gmx.net. The nameserver for gmx.net is ns.gmx.net. Mallory's IP is 244.244.244.244. Mallory begins to send bogus requests for www.ulam00001.com, www.ulam00002.com ... to ns.polya.com. ns.polya.com doesn't have these requests cached, so it asks a root server "where can I find the .com NS?" It then receives a referral to the .com NS. It asks the nameserver for .com where to find the nameserver for ulam00001.com, ulam00002.com etc. Mallory spoofs referrals claiming to come from the .com nameserver to ns.polya.com. In these referrals, it says that the nameserver responsible for ulamYYYYY.com is a server called ns.gmx.net and that this server is located at 244.244.244.244. Also, the time to live of this referral is ... long ... Now eventually, Mallory will get one such referral spoofed right, e.g. the TXID etc. will be guessed properly. ns.polya.com will then cache that ns.gmx.net can be found at ... 244.244.244.244. Yay. The above is almost certainly wrong. Can someone with more insight into DNS tell me why it won't work ?I've been trying to understand the attack, but I am not sure that I really get it. It looks like the only way it would work is if the DNS resolvers accept records they didn't ask for. Do they? If they do, why? I am certainly not an expert on DNS, so I'm looking for education rather than presenting a complete attack scenario. Please excuse my ignorance if I don't get something right. So from what I understand, the attack works like this (starting with a empty cache): 1) attacker sends a query for 1234.google.com to ns.isp.com 2) ns.isp.com sends a query for 1234.google.com to the root nameserver 3) the root nameserver responds with the authority record for .com 4) ns.isp.com sends a query for 1234.google.com to the .com nameserver 5) the .com nameserver responds with the authority record for google.com (the response includes the IP address of ns.google.com) 6) ns.isp.com sends a query for 1234.google.com to ns.google.com 7) ns.google.com responds with "does not exist" and includes a SOA record for google.com that points to ns.google.com. There is no A record for ns.google.com in this response. I've verified steps 1-7 with tcpdump, but I have not tried to do the spoofing yet, so what follows is pure speculation. Spoofing a A record: Right before step 7, the attacker sends a spoofed response from ns.google.com that includes an A record for www.google.com and points it to 1.2.3.4 (which is an attacker controlled name server). If the attacker does not win the race, they just try again with 1235.google.com and so on. When ns.isp.com receives the spoofed response, it puts the A record for www.google.com in its cache and from now on google is at 1.2.3.4. Why would this work? ns.isp.com did not ask for www.google.com, it asked only for 1234.google.com. Why would ns.isp.com cache that unsolicted A record? Is there some obscure DNS feature that requires this behavior? Spoofing a SOA record: Another possibility is to send a spoofed response with a SOA record for google.com that points to 1234.google.com and an A record that gives the IP of 1234.google.com as 1.2.3.4. Perhaps the ns.isp.com nameserver will replace the SOA record in its cache and from now on it will send all *.google.com queries to 1.2.3.4. Again, I'm wondering why this would work (if it does, I haven't tried it). The ns.isp.com nameserver already has a cached authority record for google.com that points to ns.google.com. It should not replace it in the cache until the record expires, and even then it should only accept such authority records from the .com nameserver (just like in step 5 above). Is there some DNS feature that requires such SOA records to overwrite previousely cached ones? Shouldn't the authority record for google.com that the .com server sent supercede all others (until its TTL expires)? Alex _______________________________________________ Dailydave mailing list Dailydave () lists immunitysec com http://lists.immunitysec.com/mailman/listinfo/dailydave
_______________________________________________ Dailydave mailing list Dailydave () lists immunitysec com http://lists.immunitysec.com/mailman/listinfo/dailydave
Current thread:
- DNS Speculation Halvar Flake (Jul 21)
- Re: DNS Speculation Jon Oberheide (Jul 21)
- Re: DNS Speculation Petja van der Lek (Jul 21)
- Re: DNS Speculation natron (Jul 22)
- Re: DNS Speculation Parity (Jul 22)
- Re: DNS Speculation Tetrapodal Giant (Jul 22)
- Re: DNS Speculation Blue Boar (Jul 23)
- Re: DNS Speculation Alexander Sotirov (Jul 22)
- Re: DNS Speculation natron (Jul 22)
- Re: DNS Speculation Dominique Brezinski (Jul 22)
- Message not available
- Re: DNS Speculation Dominique Brezinski (Jul 22)
- Re: DNS Speculation Petja van der Lek (Jul 22)
- Re: DNS Speculation Tyler Krpata (Jul 23)
- Re: DNS Speculation Alexander Sotirov (Jul 22)
- Re: DNS Speculation ninjaboy (Jul 23)
- Re: DNS Speculation Cedric Blancher (Jul 24)
- Re: DNS Speculation marc_bevand (Jul 25)