From: Chris Brenton To: bugtraq@securityfocus.com Date: Tuesday, September 9, 2003, 7:52:50 PM Subject: Permitting recursion can allow spammers to steal name server resources ===8<==============Original message text=============== Hi Dave, Sorry this post is so long but I wanted to make sure testing and how to fix the problem was spelled out exactly so people are more likely to fix their servers. Credits Many thanks to William Stearns and Tanya Baccam for helping to pull together this information. _Executive Summary_ The default configuration of many domain name servers (DNS) can leave you vulnerable to cache spoofing attacks as well as allow spammers to steal resources from your servers. To protect against these attacks, it is strongly recommended that any name server exposed to the Internet be configured to act non-recursively for all but trusted networks. _Vulnerable Software_ Bind (at default settings) Microsoft DNS (at default settings, but less so than Bind) Probably many others _Background_ There are three primary factors that attribute to the spammers ability to steal your DNS resources: 1) Exposed name server configured to act recursively 2) DNS susceptibility to cache poisoning attacks 3) Poor validation by domain name registrars First, a recursive name server is described to be a name server that is willing to do the work in answering a DNS query. If the name server does not have the answer to the query in cache, a recursive name server will go out to the Internet and find an answer. A non-recursive name server will only answer queries based on the information in its cache. If the server does not know the answer to the question being asked, the source is redirected to another server, or an error code is returned. For example, most people configure their internal name servers to act recursively so they will lookup DNS information for the local user base. The root name servers however are configured to act non-recursively. They don't answer questions about specific hosts, but rather re-direct you to the server that can answer the query Second, DNS cache poisoning attacks are not a new problem. Excellent papers have been written on these attacks over the years. Some good examples are: "Addressing Weaknesses in the Domain Name Protocol" by Christoph Schuba http://ftp.cerias.purdue.edu/pub/papers/christoph-schuba/schuba-DNS-msthesis.pdf "Using the Domain Name System for system Break-ins" by Stephen M. Bellovin ftp://ftp.research.att.com/dist/smb/dnshack.ps "DNS Cache Poisoning - The Next Generation" by by Joe Stewart, GCIH http://www.securityfocus.com/guest/17905 Additionally, there are a large number of tools out on the Internet that permit an attacker to perform a variety of DNS attacks. One of the more popular is ADMIDpack available at http://www.securiteinfo.com/ Rather than re-invent the wheel by describing cache poisoning and how it is done, we'll refer readers that require that information to the above references. Instead, we will focus on what appears to be a new trend with spammers, how it can impact your network, and what you can do to protect yourself. Finally, the fact that domain name registries perform extremely poor validation of the information associated with a given domain name is also well know. A good article on the subject can be found here: http://news.com.com/2100-1025_3-5071523.html _The Problem_ Just about everyone hates receiving spam and it is not uncommon for people to lash out at the source of these messages. Spammers know this, which is why they go to such great lengths to hide their tracks. Spammers that set up legitimate domains frequently find themselves to be the recipient of Denial of Service (DoS) attacks, or discover that their Internet connectivity is quickly terminated by their upstream ISP. One of the stealthy tricks spammers have developed is to find mis-configured mail servers that will permit them to relay their spam messages (this is a well known technique). If the mail server gets attacked or blocked by the Internet community, the spammer simply moves on to another open mail relay. Of course the legitimate owner of the mail server is not so lucky. In an escalation of arms, it appears that some people also take action against the spammer's name servers as well. The thought process is that if the Internet community can take out the spammer's DNS (note we are not advocating this practice, just describing it), click though links in their spam messages as well as Web bugs and the like may no longer function. This can severely hinder the spammers ability to figure out which messages were actually received, as well as the amount of interest generated by the message. Unfortunately, spammers have found a way around this problem in a similar fashion to the open SMTP relay method described above. Instead of targeting mis-configured mail relays however, they target mis-configured name servers. Here's how it works. The spammer registers a domain name using name servers that are under their control. Note that we found no consistency in the amount of time that spammers use when registering a domain name. It could be anywhere from a year to 10 years. Also, we found no consistency with the registrar authority being used. The spammers we tracked used a range of authorities. Next the spammer seeks out name servers on the Internet that have been mis-configured to act recursively for anyone. Unfortunately, this appears to be a fairly easy task as testing we performed showed that an overwhelming majority of the exposed name servers on the Internet act recursively. After that, the spammer populates the recursive name server with host information regarding their spam domain. We prefer not to go into a whole lot of detail as to how this is done, as we prefer not to train script kiddie spammers on how to leverage this attack. Suffice to say that once the spammer is finished, the target server contains cached information about the spam domain. The amount of time this information will be cached varies depending on the time to live (TTL) values used by the spammer. 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. There is a limiting factor in all of this. Most name server software allows you to specify a maximum amount of time that the server will cache information. In other words, if the spammer attempts to set a TTL cache value of 90 days, the name server doing the caching may quietly truncate the TTL value to a lower setting. For example, the maximum TTL cache time with Microsoft DNS is set through the MaxCacheTtl registry key value. The default value is one day. This gives a very small window of time that the spammer could use to populate the name server, change their registry information, send out their spam, and expect replies to come back. This makes Microsoft DNS far less susceptible to this attack (by default) than other name servers. Bind limits this cache time though the max-cache-ttl parameter. The default setting is seven days. Given that most registry authorities make changes in 24 hours or less, this is still ample time to push out spam messages and see who replies. Please note that the root cause of the problem is not how long the information is being cached. The real problem is that the server is acting recursively by default. The above information has been included in order to help identify the magnitude of the problem with different name server software packages. Longer caching is actually preferred as it helps to improve performance. _How to fix the problem_ Fixing the problem varies depending on whether you are running Bind, Microsoft DNS, or some other software. Regardless of what you are running, testing to see if you are vulnerable is a consistent process. Run the following command from a remote UNIX or Windows system. You want to run this from a system that *should not* have recursive access to your exposed name servers. DO NOT try this from an internal host first, as it will skew your results. Good choices are an external shell account, your home system, or possibly have a trusted friend do the testing for you. Here is the command to run: nslookup bogus.spam-free-zone.com If the command returns similar to the following: Non-authoritative answer: *** Can't find bogus.spam-free-zone.com: No answer You name server is configured properly. Pass directly to "GO" and collect $200. :-) If however you get back an answer similar to: Name: bogus.spam-free-zone.com Address: 172.29.217.137 your name server is improperly configured to act recursively for everyone on the Internet, and needs to be changed. _Fixing the problem with Bind_ Changing Bind so that it will not act recursively for all hosts on the Internet is a relatively simple process. Edit the /etc/named.conf file to add in the "allow-recursion" parameter similar to the following: options { directory "/var/named"; allow-recursion {localnets; }; }; Note that you may already have additional options defined, which is just fine. The important thing is to add in the allow-recursion line as shown. The above command tells Bind to only act recursively for systems that are part of the same logical subnet as the Bind server. This way if there is a local SMTP or HTTP server than needs to do name resolution, this functionality will continue to work. All other subnets however will be blocked from doing recursive queries. Users on the Internet will only be permitted to look up information you are authoritative for (like your Web server's IP address, your MX record, etc.). This will protect you from the current round of spammers stealing name server resources. If you need to have the Bind server act recursively for multiple subnets, simply specify them in CIDR format, separated by commas. For example: allow-recursion {172.16.1.1, 10.0.0.0/8, 192.168.1.0/24;}; _Fixing the problem with Microsoft DNS_ Unfortunately, Microsoft DNS is not quite as configurable as Bind when it comes to tweaking recursion. Your options are to either enable or disable recursion; you cannot make exceptions for certain subnets like we could with Bind using the allow-recursion parameter. This can cause problems if there is a local SMTP, HTTP, etc. server that relies on the Microsoft DNS server to perform recursive queries. Disabling recursion will break this required functionality. If you are in this situation, you may need to do one or more of the following additional steps along with disabling recursion on your exposed Microsoft DNS server: 1) Re-configure these systems to direct recursive queries though some other name server, such as your upstream ISP 2) Run a local DNS process on each of these systems but do not make TCP/53 and UDP/53 directly accessible from the Internet to these systems. 3) Replace the server with a Bind server and use the allow-recursion parameter. To disable recursion on a Microsoft DNS server from the command line, run the following command while having Administrator level access to the system: dnscmd /config /NoRecursion 1 If you prefer to use the GUI interface, open Administrative Tools and then DNS, and click on the following: Properties--> Advanced --> Server Options --> Disable recursion --> OK _Verifying that recursion is now disabled_ If you believe you have recursion properly disabled, you can test it from an outside host in a similar fashion to the testing we performed earlier: nslookup bogus1.spam-free-zone.com The IP address of this host is 172.29.217.138. Again, if you get a failed lookup, the test is successful and your DNS server is safe from recursive attacks. You can verify that recursion is working properly by running the same command from an internal host. If the command returns the above IP address, the name server is functioning properly. _Additional testing_ If you would like to verify that a domain's name server is acting as a proper authoritative name server, rather than serving up cached information only, the host command works quite nicely: $host -C spam-free-zone.com Nameserver host2.spam-free-zone.net: spam-free-zone.com SOA host2.spam-free-zone.net. postmaster.spam-free-zone.net. 200309091 28800 900 1209600 86400 Nameserver dns1.chrisbrenton.org: spam-free-zone.com SOA host2.spam-free-zone.net. postmaster.spam-free-zone.net. 200309091 28800 900 1209600 86400 A server that is suppose to be authoritative for a domain, but is only serving up the information via cache would return no information. You can configure Sendmail to reject SMTP messages when the name servers for the domain are supposed to be authoritative, but are actually serving up information from cache. Simply edit your sendmail.mc file and comment out (add dnl to the beginning of the line) the "accept_unresolvable_domains" option, similar to the following: dnl FEATURE(`accept_unresolvable_domains')dnl Then just rebuild a new sendmail.cf file, restart Sendmail, and you are cooking with gas. Rejected e-mails will get logged with the following error code: reject=451 4.1.8 Domain of sender address mail@iamastinkyspammer.com does not resolve) In our testing this tweak resulted in zero legitimate e-mails getting dropped, but your mileage may vary. We are unable to come up with a legitimate reason as to why someone would configure their domain this way on purpose, and in fact it's in violation of the RFCs. It's possible however that someone you communicate with has incorrectly configured their domain this way, so watch your logs to see if you start rejecting legitimate e-mails. ===8<===========End of original message text===========