Men & Mice Community

Men & Mice Security Note - Multiple DNS implementations vulnerable to cache poisoning

Sources:
Vulnerability Note VU#800113
http://www.kb.cert.org/vuls/id/800113

ISC characterization: Query Port Randomization for BIND 9 ISC CVE 2008-1447
http://www.isc.org/index.pl?/sw/bind/bind-security.php

Microsoft Knowledgebase - MS08-037: Vulnerabilities in DNS could allow spoofing
http://support.microsoft.com/KB/953230

Massive DNS security problem endangers the internet
http://www.heise-online.co.uk/security/Massive-DNS-security-problem-endangers-the-internet--/news/111070

This is an security announcement for customer using the Men & Mice Enterprise Suite for managing DNS Servers.

The Men & Mice Management Suite manages industry standard DNS Servers, either Microsoft DNS Server on Windows 2000/2003/2008 Server Operating Systems or ISC BIND DNS Server on Unix/Linux/MacOS X.

According to the Vulnerability Note published on 8. July 2008, most DNS Server deployed are vulnerable to cache poisoning attacks. This is a critical security risk. These affected DNS Server engines should be upgraded as soon as possible. Men & Mice does not provide the DNS server engine used in a Men & Mice Management System, instead the DNS Server engine is either supplied as part of the operating system or is installed separately by the customer's server administrator. Customers of the Men & Mice Management should check their DNS Server Versions and should either

a) use the Operating System internal Update system to upgrade the DNS Server Engine
b) contact the Operating System vendor for an update
c) compile an new DNS Server Engine using the Sources from the Vendor (ISC BIND)

The provided fixes by the vendors does not 100% fix the issue (the fixes make it harder to exploit the security vulnerability), as the issue is in the design of the DNS Protocol. Migrating to DNSSEC and the use of validating resolvers will solve this issue in the long run.

Customer that have not started planning for a DNSSEC Migration should start testing DNSSEC and the use of validating resolvers. The Men & Mice Services Team provides help preparing for a DNSSEC deployment in form of Training, DNSSEC Infrastructure Design and Audit.

Windows Operating Systems

Microsoft has published an extended Knowledgebase article on the topic. DNS Admins should fully read the article (the the linked articles) and the implications the provided fix will have on their Infrastructure (other applications using UDP Ports on the same machine as the DNS Server, Firewalls, NAT-Devices, Intrusion Detection Systems).

The Article:
http://support.microsoft.com/KB/953230

Removing Windows software updates in the wrong order may cause the operating system to stop functioning
http://support.microsoft.com/kb/823836/

more information about the MaxUserPort registry entry http://www.microsoft.com/technet/prodtechnol/windows2000serv/reskit/regentry/58791.mspx?mfr=true

The default dynamic port range for TCP/IP has changed in Windows Vista and in Windows Server 2008
http://support.microsoft.com/kb/929851/

The Updates can be downloaded from the Microsoft Update Site http://update.microsoft.com/microsoftupdate/

MS08-037: Description of the security update for DNS in Windows Server 2003, in Windows XP, and in Windows 2000 Server (client side): July 8, 2008
http://support.microsoft.com/kb/951748/

MS08-037: Description of the security update for DNS in Windows Server 2008, in Windows Server 2003, and in Windows 2000 Server (server-side): July 8, 2008
http://support.microsoft.com/kb/951746/

Apple MacOS X

Users of MacOS X should use the MacOS X Software update to update to the latest version of MacOS X including the fix for the MacOS X BIND DNS Server.

Men & Mice Support Contract Customers of Level Silver and up can request an updated BIND 9 installer for MacOS X 10.4/10.5 from Men & Mice Support (support@menandmice.com)

Linux (RedHat, SuSE, Ubuntu/Debian and others)

Users of BIND DNS Servers on Linux should check their BIND DNS Server versions against the problematic versions listed on the ISC Website:
http://www.isc.org/index.pl?/sw/bind/bind-security.php

DNS Admins should fully read the article above and the implications the provided fix will have on their Infrastructure (other applications using UDP Ports on the same machine as the DNS Server, Firewalls, NAT-Devices, Intrusion Detection Systems).

They should contact the operating system vendor and upgrade to a new, patched version of BIND (BIND 9.3.5-P1, BIND 9.4.2-P1 or BIND 9.5.o-P1) or download the BIND source from the ISC Website and compile a new version of the ISC BIND DNS Server engine.

Men & Mice Support Contract Customers of Level Silver and up can request an updated BIND 9 installer (RPM or DEB) for Linux (SuSE, RedHat or Ubuntu) from Men & Mice Support (support@menandmice.com)

Solaris

Users of BIND DNS Servers on Solaris should check their BIND DNS Server versions against the problematic versions listed on the ISC Website:
http://www.isc.org/index.pl?/sw/bind/bind-security.php

DNS Admins should fully read the article above and the implications the
provided fix will have on their Infrastructure (other applications using UDP Ports on the same machine as the DNS Server, Firewalls, NAT-Devices,
Intrusion Detection Systems).

They should contact SUN Microsystems and upgrade to a new, patched version of BIND (BIND 9.3.5-P1, BIND 9.4.2-P1 or BIND 9.5.o-P1) or download the BIND source from the ISC Website and compile a new version of the ISC BIND DNS Server engine.

Men & Mice Support Contract Customers of Level Silver and up can request an updated BIND 9 package for Solaris 10 from Men & Mice Support (support@menandmice.com)

There has been some discussion in the BIND Users mailing list regarding resource limits relating to this new version.

Basically, if the name server needs to open a new port for every outgoing query, then a busy name server can quickly run out of ports and briefly (but repeatedly) go deaf. Also, a firewall in front of that name server can quickly become overloaded in trying to track all of the connections involved.

Because of this, Men & Mice recommends caution in deploying the new versions of BIND name server. Test, including a performance test that comes as close as possible to your production server's traffic pattern, before deployment.

Note that a similar very large number of open ports has been reported with Microsoft DNS after applying the latest security update from Microsoft. Again, test before deployment.

Discussions of the problem on BIND Users can be found here:

http://readlist.com/lists/isc.org/bind-users/jul-2008.html

There are several relevant threads, with new ones still being opened.

Further research reveals the following two data points:

1. If your name server does not change ports with every query, or at least every few seconds, it is vulnerable to this new attack. This is not a rehashing of the old forged-response attack vector; this is apparently something new.

2. Once advised of the general parameters of the attack (what is known to the public so far), but not the specific method of the attack (the part Mr. Kaminsky is reserving for his presentation), a security researcher was able to recreate it in under 50 hours. There is therefore a solid chance that bad operators will be able to start exploiting this attack vector before the presentation next month.

Therefore, it is important for all resolving name servers, and possibly even all caching stub resolvers, to be updated as soon as possible.

- Upgrade to the newest version of BIND, or
- Apply the recent security patch from Microsoft.
- Patch your stub resolver (another Microsoft patch from earlier this week) or disable its caching daemon (e.g. nscd on many Unix/Linux operating systems).

We do not yet have full details of the new attack vector, nor do we expect to have them until Mr. Kaminsky's presentation next month unless an exploit gets loose (and is detected) before then.

This article from IBM Internet Security Systems describes an issue that some NAT/Firewall devices cancelled out the source port entropy introduced by the recent patches:
http://blogs.iss.net/archive/dnsnat.html

So if the DNS Server is placed behind a Firewall or NAT Device, it shoukd be tested that the UDP Source Port order of outgoing DNS requests is still random behind the NAT/Firewall device.

A quick test can be done using the DNS Checker of Dan Kaminsky on
http://www.doxpara.com/?p=1162

People interested in the topic of DNS Resolver Security and DNS Spoofing might also find it useful to review the Internet Draft "DNS resilience against forged answers"
http://tools.ietf.org/html/draft-ietf-dnsext-forgery-resilience-05

A message from Dan (Kaminsky, who found the issue) and Sarah on the topic:

http://www.youtube.com/watch?v=XDKw8ny6IcM

The team at DNS ORAC has developed a port testing tool that can be used to test a caching DNS Server if the server is vulnerable to the cache poisioning issue reported above:

Use a DNS query tool such as dig to ask for the TXT record of porttest.dns-oarc.net:

$ dig +short porttest.dns-oarc.net TXT

You should get back an answer that looks like this:

z.y.x.w.v.u.t.s.r.q.p.o.n.m.l.k.j.i.h.g.f.e.d.c.b.a.pt.dns-oarc.net.
"169.254.0.1 is FAIR: 26 queries in 0.1 seconds from 25 ports with std dev 3843.00"

Your resolver's randomness will be rated either GOOD, FAIR, or POOR, based on the standard deviation of observed source ports. In order to receive a GOOD rating, the standard deviation must be at least 10,000. For FAIR it must be at least 3,000. Anything less is POOR. The best standard deviation you can expect to see from 26 queries is in the 18,000-20,000 range.

DNS records used in this test are given 60 second TTLs. To repeat the test you should wait at least 60 seconds.

Note that you can tell dig to test a specific resolver with an @-argument:

$ dig @4.2.2.3 +short porttest.dns-oarc.net TXT

The full information can be found at
https://www.dns-oarc.net/oarc/services/porttest

Windows users can use the "nslookup" tool to test their DNS Server. To use the OARC Porttester:

1) start a Command Prompt Window

2) start "nslookup"

Code:

 nslookup

3) on the nslookup prompt, set the server to the IP Address of your local caching DNS Server

4) set the resource record type to be requested to "TXT"

Code:

 set type=txt

5) set the timeout to "20" seconds

Code:

 set timeout=20

6) type in the domain name to resolve: "porttest.dns-oarc.net". If the request times out, retry the request until you get an answer

7) check the result output (see example session below)

Example session:
Code:

 C:\>nslookup
 Default Server:  localhost
 Address:  127.0.0.1
 
 > server 192.0.2.2
 Default Server:  [dns1.example.com]
 Address:  192.0.2.2
 
 > set type=txt
 > set timeout=20
 > porttest.dns-oarc.net
 Server:  [dns1.example.com]
 Address:  192.0.2.2
 
 Non-authoritative answer:
 porttest.dns-oarc.net   canonical name = z.y.x.w.v.u.t.s.r.q.p.o.n.m.l.k.j.i.h.g.f.e.d.c.b.a.pt.dns-oarc.net
 z.y.x.w.v.u.t.s.r.q.p.o.n.m.l.k.j.i.h.g.f.e.d.c.b.a.pt.dns-oarc.net     text =
 
         "217.255.158.70 is GOOD: 26 queries in 4.5 seconds from 26 ports with std dev 18990.84"
 
 z.y.x.w.v.u.t.s.r.q.p.o.n.m.l.k.j.i.h.g.f.e.d.c.b.a.pt.dns-oarc.net     nameserver = ns.z.y.x.w.v.u.t.s.r.q.p.o.n.m.l.k.j.i.h.g.f.e.d.c.b.a.pt.dns-oarc.net
 ns.z.y.x.w.v.u.t.s.r.q.p.o.n.m.l.k.j.i.h.g.f.e.d.c.b.a.pt.dns-oarc.net  internet
  address = 149.20.58.126
 >

We will cover this cache poisioning issue and how to configure/upgrade a BIND or Windows DNS Server in detail during the Men & Mice DNS Security Training in Berlin. During this training we also cover how to implement DNSSEC.

The training will take place on Thursday/Friday 21-22 August 2008 in Berlin.

The Men & Mice Training schedule for Europe and Asia
http://menandmice.com/training/eaaa

We will also cover the topic during our upcoming trainings in Reykjavik, London and Singapore, and also in all upcoming "DNS Security and Advanced Topics Hands - On" Courses in the U.S.
http://menandmice.com/training/northamerica

Recently we announced that there was a DNS cache-poisoning exploit discovered by Dan Kaminsky that would be revealed on August 6th. Unfortunately, the details of the exploit were leaked Monday, July 21st, and it is important to be sure that your resolving name servers are protected. The exploit can be used to create a fully automated, drive-by attack on any resolving name server, and any server that does not use sufficient source port randomization is likely to be compromised rather quickly.

** Testing **

Visit this web page:
https://www.dns-oarc.net/oarc/services/dnsentropy

Click on the Test My DNS button and wait for the test to complete - it may take a minute or two. If the results are anything less than "Good" on the source port randomization test, you have work to do.

** Quick Fix **

The quickest fix is to configure your existing front-line DNS resolvers to forward queries to known-safe resolvers. ISC, maker of BIND, offers one set of resolvers for their support customers, or you can use opendns.com's name servers. We have tested opendns.com's resolvers and they appear to be safe.

** Short Term Fix **

Although forwarding can be seen as an immediate mitigation, a creative
attacker can still target your name server - it's just a bit more difficult. You should immediately begin planning to deploy a name server version that uses source port randomization. Also, make sure that your name server configuration does not limit your server to a single outbound source port, such as port 53.

On the 8th of July, the following vendors released updated versions of their name server software: ISC (the BIND package), Microsoft, Cisco, and Nominum (the CNS package). In addition, resolvers from PowerDNS and the djbdns package were already using source port randomization.

Unfortunately, it appears that there may be some issues with the releases from at least Microsoft and ISC relating to large amounts of traffic. Be sure to test these new releases with a realistic traffic pattern before deployment, or at least pay close attention after deployment to make sure that the servers are behaving well. The symptoms of the problem appear to be a greatly increased amount of CPU usage plus log messages about the server running out of file descriptors and/or available UDP ports.

** Long Term Fix **

Unfortunately, source port randomization will only buy some time. As the bandwidth available to everyday users increases, it will become feasible to use a modified version of the same attack to target name servers that use randomized source ports. With source port randomization, the effective cypher length changes from 16 bits to 32 bits, meaning the traffic required to reliably attack the target name server increases from around 10 MB (in 5-10 seconds) to around 1 TB; nevertheless, because the attack will then be much harder to defend against, a relatively low success rate (using only 5 GB of traffic, for example) will be acceptable to the criminals.

The only real fix is to increase the cypher length dramatically, and this means using DNSSEC.

** Help Is Available **

Men & Mice Professional Services stands ready to assist in any way necessary. We can help you deploy an updated name server version, configure forwarding, test your installation both before and after an upgrade, monitor your traffic, and more.

For more information, please contact your Men & Mice support contact or sales representative.

Professional Services
Men & Mice
Address: Noatun 17, IS-105, Reykjavik, Iceland
www.menandmice.com

The danger is now out there, two exploits for the security flaw have been released in source

http://www.caughq.org/exploits/CAU-EX-2008-0003.txt
http://www.caughq.org/exploits/CAU-EX-2008-0002.txt

Update you DNS now, or contact you OS vendor to release an update!

Apple has released a security update that will (among other things) install a new BIND versions that has the patches for the DNS cache poisioning issue.

The security update for Intel Workstations can be downloaded from
http://www.apple.com/downloads/macosx/apple/security_updates/securityupdate2008005intel.html

PPC Workstation
http://www.apple.com/downloads/macosx/apple/security_updates/securityupdate2008005ppc.html

Because there already have been cache poisioning attacks on caching DNS Servers in the Internet, whith the effect to redirect the Apple Update Service (so that users using the Apple Update Service in the MacOS X System will install a torjan program instead of an real update), we recommend to download the fix from the above site and after downloading, verify the SHA1 checksum printed on the site with the checksum calculated on your machine. Only if the checksum matches, it is safe to install the update.

The checksum is
(Intel) SHA 1 digest 1ff3242935c98325769b33148a2a8b1e72db567c
(PPC) SHA 1 digest 2f56ea4311d5b85de3c494f6fee46360e5b7317e

After downloading, open Terminal.App, change to the download location of the file

Code:

cd Downloads

and calculate the SHA 1 checksum (hash)

Code:

/usr/bin/openssl sha1 SecUpd2003-005Intel.dmg

The updates for MacOS X Server can be found at

(PPC)
http://www.apple.com/downloads/macosx/apple/security_updates/securityupdate2008005serverppc.html
(Intel)
http://www.apple.com/downloads/macosx/apple/security_updates/securityupdate2008005serverintel.html

Keep in mind that the new BIND patches can have side-effects on busy DNS Servers (see Paul Vixies statements on the -P1 releases), so monitor your DNS Server closely the next days after the upgrade.

For Mac OS X v10.4.11 systems, BIND is updated to version 9.3.5-P1. For Mac OS X v10.5.4 systems, BIND is updated to version 9.4.2-P1.

Will QuickDNS 5.1.3 work fine with this update? Any configuration files need to be changed, etc?

Any idea if Apple will be releasing the update for 10.3.x as well?

- John

Men & Mice Suite 5.1.3 will be fine after the update. These updates do not upgrade you from 9.3.x to 9.4.x (although it's possible they will downgrade you, on Tiger), so no configuration changes are needed.

They will not be releasing an update for Panther. Panther users are urged to install XCode Tools and build BIND 9.3.5-P1 from source code. If updating from 9.2.x to 9.3.5-P1, watch out for zones that don't load due to invalid characters.

Instructions for building the binary from source code are available in another forum topic.

My 10.3.x install is currently running BIND 9.4.1-P1. Should I up(down)grade to 9.3.5-P1 or 9.4.2-P1?

I have successfully run the OS X Server update on our other DNS box which is running 10.4.x server and is now BIND 9.3.5-P1.

Note we're running QuickDNS 5.1.3

- John

Since you're already at 9.4.x, go to 9.4.2-P1.

Note that -P2 is expected to be out sometime today. However, don't wait - upgrading again is pretty painless if you just record what you did and repeat it.