April 7, 2005 – DNS cache poisoning update

We have received more technical details on the software configurations that
are vulnerable. Thanks to Microsoft for clarifying details on Windows DNS and
thanks to numerous others for reporting. We try to get all the technical
details right before publishing information on attacks like this, but if we
waited until we were 100% sure all the time, we would never be able to notify the
community when the attacks are actually happening.

On Windows 2000 SP3 and above, the DNS server DOES protect against
DNS cache pollution by default. The registry key to protect against the poisoning
is not necessary: the value is TRUE if the registry key does not exist. Microsoft has
now corrected the KB article that we published earlier with this information.

http://support.microsoft.com/default.aspx?scid=3Dkb;en-us;241352

http://support.microsoft.com/kb/316786

On Windows 2000, you should manage the DNS cache protection security
setting through the DNS Management Console. On Windows 2000 below SP3, the
“Secure cache against pollution” is not the default so you should enable it using the
DNS Management Console. On Windows 2000 SP3 and above (and Windows 2003),
the secure setting is the default (even if the registry key does not
exist).

Our recommendation is to only set the registry key (HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\DNS\Parameters) on
Windows NT4. Otherwise, use the DNS Management Console. If you are on Windows
2000 and you created the key already, you are safe to leave it in place as long
as the value is “1″.

There seems to be other possible scenarios where cache poisoning can
occur. When forwarding to another server, Windows DNS servers expects the
upstream DNS server to scrub out cache poisoning attacks. The Windows DNS server
accepts all data that it receives, regardless of the setting for protecting against
cache poisoning. So vulnerability of the attack depends upon whether the
upstream DNS server is filtering out the attack.

We are currently trying to determine the behavior of DJBDNS, and BIND versions 4, 8, and 9 when acting as a forwarder. We are asking for assistance from the community to determine their behavior so write us if you have details. It appears that BIND4 and BIND8 do not scrub the data, whereas BIND9 does. See the following scenarios:

Windows DNS > forwarding to BIND4 or BIND8. Windows DNS server assumes
that BIND scrubs out the poisoning attempt. BIND4 and BIND8 do NOT appear to
scrub the attack. Windows DNS trusts the data and the Windows DNS cache will
become poisoned.

Windows DNS > forwarding to BIND9. This configuration seems to be secure
because BIND9 scrubs the poisoning attempt.

Windows DNS (slave) > forwarding to Windows DNS (master). In this
scenario, your vulnerability is based on the vulnerability of the master. If the
master is vulnerable, then it will be poisoned and forward the attack to the slave server, which will also be poisoned. However, if the master is secure then both servers should be safe.

The following recommendations are based on the current assumption that BIND4 and BIND8 forwarders will not filter the cache poisoning attack to its downstream clients. If we find out that this is not the case, then the recommendations may not be valid. If you have Windows DNS servers forwarding to BIND4 or BIND8, you should start investigating an upgrade of those BIND servers to BIND9. If upgrading to BIND9 would not be a possibility, a secondary recommendation would be to turn off the forwarding on Windows DNS and allow the
server to contact the Internet directly so that it can apply the proper protection against cache poisoning. If you run an ISP and have clients that are using your DNS servers as forwarders, you may want to consider upgrading your resolvers to BIND9 in order to protect your clients.

Alternatively, if you have Windows DNS servers that are functioning as forwarders then you should verify that those machines are protected, which should protect the rest of the DNS servers behind it.

April 8, 2005 – Internet Storm Center Returning to Green

You may have noticed that the InfoCon has returned to Green. We do this not because we think the DNS cache poisoning is solved, but due to that we now understand the issues and have clear things people should do to protect themselves. Here are the suggestions we have for you:

- add the right key to the registry on NT

http://isc.sans.org/diary.php?date=3D2005-04-07

(Note: Windows systems are not protected even with their magic registry entry IF they trust an upstream dns system that doesn’t clear additional dns records from the answer to the query and site the article. – upgrade to the right SP on W2K
- not forward to vulnerable windows DNS caches
- not forward to pre-BIND9 bind DNS caches

And a heads-up to ISP’s and others
running BIND4 and BIND8 – Please upgrade to BIND9 if you are likely to have people
forwarding to you with a MSFT DNS cache.

Thanks to Kyle, Swa, Eric and Donald for their input. You guys are awesome.
A heartfelt thanks to all of you who participated in the research and investigation on this issue. It is
because of you and you willingness to assist that we are as successful as we are.