Kaminsky Vulnerabilty Leads to Increased DNSSEC Adoption

Eric Osterweil gave an interesting talk at the NANOG44 DNSSEC BOF. His data (shown below) from SecSpider indicates a significant increase in signed zones right around the time that CERT VU #800113 was released:



(click for larger)

The blue line shows a large increase in the number of signed zones automatically discovered by the SecSpider crawlers in August 2008. A message to the dnssec-deployment list confirms this as well.

Submitted by wessels@dns-oarc.net on Mon, 2008-10-13 22:02.

DSC now reports EDNS buffer sizes

Last week David Conrad of ICANN asked if I could make DSC show the EDNS buffer sizes advertized by clients. This is now available in DSC versions dated after 2008-08-22. Furthermore, the new version is running on the F-root collector nodes.

The breakdown of buffer sizes looked different than I remembered for recent DITL data, so I generated some graphs for the 2006 through 2008 DITL data (F-root nodes) using the same size ranges.


January 2006


January 2007


March 2008


August 2008

The trend is good news. Back in Jan 2007, 50% of queries did not indicate any EDNS support. 20% had bufsiz=2048, and 30% had bufsiz=4096. Now we have about 65% of queries with bufsiz=4096, while 35% still don't support EDNS.

DW

Submitted by wessels on Mon, 2008-08-25 20:17.

ISC SIE cache poisoning attempt detection tool

Date: Mon, 4 Aug 2008 18:22:46 -0400
From: Robert Edmonds
To: dns-operations
Subject: [dns-operations] release of ISC SIE cache poisoning attempt detection tool

hi,

ISC SIE has developed a tool for detecting cache poisoning attempts. it consists of two parts: ncaptool, the part which performs packet gathering, reassembly, and dns filtering; and mod_urstate, a message processing module which attempts to statefully detect unsolicited responses that may be indicative of cache poisoning attempts. specifically, the tool is designed to listen at the network layer of a recursive dns server, auditing the query-response stream between recursive and authoritative dns servers. when a potential cache poisoning attempt is detected, both the offending and original dns responses will be emitted into the output stream.

ncaptool and mod_urstate may be obtained via ftp:

ftp://ftp.isc.org/isc/ncap/

the defaults are tuned for a dedicated IDS-style setup; e.g. fairly fast machines with >= 1 GB of memory and aggregated taps of dns traffic between recursive and authoritative nameservers. it ought to be possible to run it directly on a machine running a recursive nameserver, however.

we would like people to use it, and if possible provide feed back or contribute the data it generates to SIE.

mod_urstate is an ncaptool dns message parsing plugin that attempts to detect unsolicited dns responses that may be indicative of cache poisoning attempts. it does this by statefully tracking the application layer state of the dns transactions between recursive and authoritative dns servers. it gracefully handles query retransmissions due to client timeouts and byte identical responses from dns authorities.

two data collections are employed by mod_urstate:

  1. a fifo cache of the query / response payloads generated by dns transactions. a hard limit on the number of entries in this cache will be enforced to bound memory consumption. the default limit of 1048576 entries tends to consume around 700 MB of memory. the larger this cache is, the more accurate the output will be. as a rule of thumb, the cache should be large enough to hold at least 5 to 30 seconds or so of the most recent dns transactions.
  2. an associative array for locating entries in the cache based on a tuple of fields from the packet headers and payload.

when a query for a previously unknown tuple arrives, the query payload is cached so that subsequent byte identical queries may be discarded. when the first response for this query arrives, its payload is also cached. the vast majority of dns queries will only elicit a single response, so most cache entries will be quietly expired in fifo order.

however, in the usual case that a domain name's authoritative nameservers are reachable and functioning, a potentially successful cache poisoning attempt has these properties:

  • the malicious response payload differs in some way from legitimate response payloads.
  • the malicious response matches the tuple for an outstanding query.
  • the malicious response arrives at approximately the same time as a legitimate response.

(it should be noted that certain types of benign dns responses unfortunately also match these criteria. it will be possible to filter these out in the post-processing / analysis phase.)

the mod_urstate module will output dns responses matching the above criteria. this output can then be analyzed to help answer the following questions:

  • was an attempt made to introduce malicious data into my cache?
  • did the attempt succeed? i.e., did the malicious response arrive prior to the legitimate response?
  • what are the contents of the malicious dns response? e.g., in the most common scenario, where is the attacker's doppelgaenger located?

it should be noted that an out of band method of distinguishing malicious from legitimate responses will be needed by the analyst.

--
Robert Edmonds

Submitted by wessels on Fri, 2008-08-08 22:30.

Information about CERT VU #800113

This page provides information relating to CERT VU #800113. Please write to Admin if you have corrections or additions.

Timeline of Events

?, 2008

Dan Kaminsky stumbles upon a serious problem in the DNS protocol that makes poisoning easier than most everyone previously thought.

March 31, 2008

DNS Summit at Microsoft's offices to discuss the problem and solutions.

July 8, 2008

CERT VU #800113 published in conjunction with patches/updates from almost all DNS vendors. Attack details are to be kept secret until August 6th.

July 9, 2008

Kaminsky gives details to skeptical security colleages in confidence.

July 21, 2008

A so-called security expert publicly speculates about the flaw on his blog and more-or-less gets it right. The speculation is confirmed when Matasano publishes a blog-post-in-waiting, which is later retracted. At this point the flaw is effectively leaked.

July 23, 2008

Working exploit code is released.

July 24, 2008

Another metasploit script is released, as well as a python implementation.

July 30, 2008

PCWorld reports that an AT&T nameserver is poisoned, which ends up affecting the author who published the first exploit code.

August 7,2008

Dan Kaminsky gives his talk (ppt file) at the Blackhat conference.

Tools for Testing and Monitoring

porttest.dns-oarc.net

OARC's own porttest tool is a DNS server that will tell you if the queries coming from your resolver appear to be random. Use it with command-line tools like dig and nslookup.

txidtest.dns-oarc.net

Very similar to porttest, except that this one reports on transaction IDs. Most DNS resolver implementations were already using random transaction IDs well before this vulnerability came out, but now you can double-check it with this service.

OARC's Web-based entropy test

Similar to porttest and txidtest, except that the test provides more information and is done with your web browser, rather than command line tools. Another benefit to the web-based test is that you can see scatter plots of the received ports and IDs to visualize the data.

DNS Checker at doxpara.com

Dan's DNS checker also reports on source ports and transaction IDs, although it uses fewer queries than OARC's, and requires javascript.

Niels Provos home page

When you visit Neils' page, an image at the top will tell you if your DNS resolver is using random ports or not.

ONZRA's CacheAudit

CacheAudit is a BSD-licensed tool that allows recursive providers to detect cache poisoning events using cache dumps from
their DNS servers.

ISC's SIE cache poisoning attempt detection tool

ISC SIE has developed a tool for detecting cache poisoning attempts. It consists of two parts: ncaptool, the part which performs packet gathering, reassembly, and dns filtering; and mod_urstate, a message processing module which attempts to statefully detect unsolicited responses that may be indicative of cache poisoning attempts.

Data, Documentation, Papers, and Presentations

Dan's Blackhat talk

Straight from the horse's mouth.

Sid's DNS Ephemeral Port Measurement

Sid Faber is generates data showing levels of patching from SIE data.

Report from CERT.at

CERT.at reports on patch rates based on the queries they see at the .at authoritative nameservers.

Kaminsky Viz

A flashy visualization of patch adoption from Dan's data.

Steve Friedl's Illustrated Guide to the Kaminsky DNS Vulnerability

A very nice explanation of how DNS works and of the poisoning vulnerability.

Submitted by wessels on Thu, 2008-07-31 22:36.

txidtest.dns-oarc.net -- Check your resolver's transaction ID behavior

A number of people have been asking for a way to check transaction ID randomness, in addition to source port randomness. OARC's porttest tool has now been expanded to also report on transaction IDs. To use it, issue a TXT query for the name txidtest.dns-oarc.net. For example, with dig:

$ dig +short txidtest.dns-oarc.net TXT
"12.160.37.12 is GREAT: 26 queries in 2.7 seconds from 26 txids with std dev 20574.11"

Also note that in conjunction with this enhancement, the scoring critera for porttest and txidtest have been changed to match the web-based port test. The scoring is as follows:


Submitted by wessels on Mon, 2008-07-28 17:24. categories [ ]

Web-based DNS Randomness Test

US-CERT's Vulnerability Note VU#800113 describes deficiencies in the DNS protocol and implementations that can facilitate cache poisoning attacks. The answers from a poisoned nameserver cannot be trusted. You may be redirected to malicious web sites that will try to steal your identity or infect your computers with malware. Working exploits for this issue are already widely circulated! Upgrade your nameservers ASAP if you haven't done so already! On August 7, 2008, Dan Kaminsky will release additional details about these poisoning attacks.

The essence of the problem is that DNS resolvers don't always use enough randomness in their transaction IDs and query source ports. Increasing the amount of randomness increases the difficulty of a successful poisoning attack.

This page exists to help you learn if your ISP's nameservers are vulnerable to this type of attack. If you click on the button below, we will test the randomness of your ISP DNS resolver.

The test takes a few seconds to complete. When its done you'll see a page where the transaction ID and source port randomness will be rated either GREAT, GOOD, or POOR. If you see a POOR rating, we recommend that contact your ISP and ask if they have plans to upgrade their nameserver software
before August 7th.

See porttest for another way to check your resolver from a Unix commandline.

Submitted by wessels on Wed, 2008-07-16 18:26. categories [ ]

porttest.dns-oarc.net -- Check your resolver's source port behavior

Yesterday's announcement of CERT VU#800113 makes it clear that resolvers should use random source source ports when sending queries. Here at OARC, we've crafted a special DNS name and server that you can query to learn whether or not your own resolver is using random ports. 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

On Windows you can use this command:

> nslookup -querytype=TXT -timeout=10 porttest.dns-oarc.net.

You can test a specific resolver address by appending it to the end of the command.

Update 2008-07-28

The scoring critera has been changed to match the web-based port test. The scoring is now as follows:


Rating Standard Deviation Bits of Entropy
GREAT 3980 -- 20,000+ 13.75 -- 16.0
GOOD 296 -- 3980 10.0 --13.75
POOR 0 -- 296 0 -- 10.0

Submitted by wessels on Thu, 2008-07-10 06:10.

CERT VU#800113 DNS Cache Poisoning Issue

CERT and numerous vendors are making a major announcement today regarding a DNS protocol vulnerability that may enable cache poisoning of recursive resolvers. From the CERT page:

Recent additional research into [DNS defects and deficiencies] and methods of combining them to conduct improved cache poisoning attacks have yielded extremely effective exploitation techniques. Caching DNS resolvers are primarily at risk--both those that are open (a DNS resolver is open if it provides recursive name resolution for clients outside of its administrative domain), and those that are not. These caching resolvers are the most common target for attackers; however, stub resolvers are also at risk.

We can expect patches from most vendors that will implement randomization of query source ports. According to ISC, source port randomization only increases the difficulty of the attack, but does not entirely prevent it. The best prevention, they say, is to implement DNSSEC.

Here are some vendor announcements:

The vulnerability was discovered by Dan Kaminsky of IOActive.

Submitted by wessels on Tue, 2008-07-08 18:47.

IANA and ICANN domains hacked

Within a day of ICANN's gTLD announcement, ZDNet reports that a Turkish hacking group has hijacked domain names belonging to IANA and ICANN. Interestingly, only thier "alternative" names were hijacked. For example, ICANN.COM and ICANN.NET were, but ICANN.ORG was not. Similarly, IANA.COM was, but IANA.ORG was not. The same group is apparently responsible for other recent high profile domain hijinks as well.

One thing all of the hijacked names have in common is their registrar, Register.com, which was apparently able to fix the problem within about 20 minutes. Let's hope the parties involved are up-front enough to explain what happened.

See also Zone-H, Circle-ID, and dnssec-deployment.

DW

Submitted by wessels on Sun, 2008-06-29 20:38.

ICANN announces significant change to TLD creation policy

Yesterday, during their meeting in Paris, ICANN announced a change in their policy for adding new generic TLDs to the DNS. Although this change has been planned for a while, I think it caught quite a few of us off guard.

Many details are not available at this time, but it sounds like a new gTLD will cost on the order of $100,000 and we won't be seeing many new ones for another year or so.

Some interesting discussions are taking place on the NANOG and dnssec-deployment mailing lists and Circle-ID has some good, articles as well.

DW

Submitted by wessels on Fri, 2008-06-27 17:09.