Date: Tue, 09 Sep 2003 22:52:50 -0400
From: Chris Brenton <cbrenton@...isbrenton.org>
To: bugtraq@...urityfocus.com
Subject: Permitting recursion can allow spammers to steal name server resources


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 <IP address of the server to test>

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 <server name> /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 <IP address of the server to test>

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@...astinkyspammer.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.

Powered by blists - more mailing lists