Re: DNS cache poisoning attacks -- are they real?
Brad, I suspect and google confirms, that you know a whole lot more about this than I do, so please have a little patience explaining this to me. Brad Knowles wrote:
At 8:49 AM -0500 2005-03-29, Joe Maimon wrote:
1) Registrars being required to verify Authority in delegated to nameservers (will this break any appreciated valid models?) before activating/changing delegation for zone.<REAL FIX>
Okay, so the spammers make the data appear valid just long enough to pass the test, then they go back to their wily ways. Not a real fix.
Why would this not work against the procedure as originaly described? Step 1) Spammers register Domain and delegate it to nameserver that respond with AA set for domain. Step 2) Registrar activated delegation due to Authority response from nameservers Step 3) Spammers seed recursive resolvers Step 4) Spammers change delegation by registrar to seeded resolvers Step 5) Change fails because Registrar check Authority from seeded resolvers and does not get it. How do spammers make step 5 succeed?
2) Stricter settings as regards to all lame delegations -- SERVFAIL by default without recursion/caching attempts?
You'd have the caching server check the name of the zone to see if it is claimed as an NS record, even when it's just caching/recursive? Now, tell me how they'd do this at all the sites on the Internet, since we assume that the data advertised may change at any moment?
What I meant is that when a server attempts to seed its cache and it encounters lameness it should not attempt to obtain it from any other servers. Perhaps it should return the answer but not cache it (or cache with forced small TTL). Now lameness is something that the server SHOULD see when it attempts to recursively resolve the name without extra effort.
In terms of running a caching/recursive server, I don't think there's any way to reliably detect that someone has aimed an NS record at you. That would be like asking how you know, a prior, whether or not www.youareadamnedbloodyfool.com is a now CNAME record for your webserver.
I am suggesting that the server can semi-reliably detect that the parent soa hasnt aimed the ns record for the subzone at it. It would verify its cache contents every X before sending on the answers it has. It should purge from cache anytime the check reveals that the parent zone has an NS aimed at it for the cache contents -- which should be a clear indication of cache hijacking. Or perhaps servers should check periodicaly for all kinds of lameness of the cached contents. This would prevent practical usage of a technique where spammers spray-seed all resolvers they can with large TTL's so that the resolvers users see them for quite some time irregardless of registrars/parent zone's actions.
3) Paranoid checking for situations such as these by having recursing nameservers attempt to periodically check for suspicous NS and glue from the parent zone's POV and compare it to cache, trashing cached records if they do not like result.
How do they know who their claimed "parent" is, when someone aims a totally bogus NS record at them? Do you ask them to walk the entire DNS tree throughout the entire Internet?
And thats so hard? Servers do this all the time fairly often.
An open recursive/caching nameserver is like an open mail relay. There may be some people who stubbornly insist that they are a necessary evil -- feel free to become the next toad.com if you like. There may be a lot of people who have one but don't know it.
But they are evil, and I believe that they should be eliminated.
So far nobody here has said that they are either neccessary or evil -- 'cept for you and chris on the evil part. As to that, I cant credit the resulting evilness you paint as evil as open mail servers became, not because open mail-relay servers were intrinsically so but because they become so very attractive to all the evil users out there. For a real life example of an open-relay mail server, walk to your nearest corner and see the maildrop that takes mail from anybody and delivers it to anyone else. A commandeered open-relay server is spewing garbage to its victims. A commandeered open-recursion server, while not a good thing, is hardly doing the same - in most cases described here its simply perpetuating a domain name far longer than POLICY reasons would like. This was probably a designed for feature, for example keeping panix.com going strong for the lucky one due to cached large NS TTLS would have been viewed as a good thing at the time. Furthermore, as others have pointed out, eliminating the openness of these resolvers would simply force a push to have spammers trojan armies seek 'n' seed the resolvers they can recurse from. Due to the nature of this game, the larger client base the resolver serves, the better the chances of it getting seeded. These would be the same resolvers targetted were they open. And as others have pointed out, once an answer is in cache, its not considered recursion and different access control needs to be applied.
Florian Weimer wrote:
* Joe Maimon:
How do spammers make step 5 succeed?
They delegate www.example.com instead of example.com?
I suspect I am some distance over the cliff here but nevertheless, onward. I dont get it. That has nothing to do with the registrar, or dodging forced deactivation of a domain. All it does is make it appear to anti-spammers that www.example.com nameservers are the seeded resolvers. Thats not quite the described problem in the URL that chris included. http://cert.uni-stuttgart.de/archive/bugtraq/2003/09/msg00164.html " Next the spammer goes back to their registry authority and changes their authoritative name servers to be the recursive name servers they populated in the last step. Since it appears that registry authorities no longer validate if a customer has permission to use the name server they specify (note that this used to be done way back when domain names were free), the record is quickly updated and users on the Internet are directed to this populated name server when querying information about the spammer's domain. The spammer is now free to push out their spam and if the Internet community decides to attack, the name server being attacked actually belongs to someone else. " SO if the extent of the problem is that the victim nameserver may become blocklisted/attacked due to its apparent hosting of a spam URL, than the answer is that anti-spammers need to be a whole lot more carefull at which nameservers they direct their ire at. Specifically, they need to confine that to only certain trustworthy points in the delegation, such as delegation for .com. and .co.uk. but not any deeper. IF the concern is that spammers may try to have their spamsite records survive example.com termination, thats quite possible to attempt doing without bothering to directly attempt to seed any other resolvers cache, all they need are their trojan pcs to host the domain and to hand out NS/A records with very large TTL values. SURBL and others will helpfully prime the resolvers all over the world. Its quite possible that going after the DNS for spammers may not/should not be the quick fix to abusive spam that people would hope for. If all this activity is confined to domain names that they have originally registered and paid for and belonged to them, I might find it quite reasonable declaring this to be strictly a registrar problem. And a resolver ought to be able to tell that www.example.com delegation is lame.
participants (2)
-
Florian Weimer
-
Joe Maimon