Arbor Networks: Security to the Core

We’ve all been aflutter over the past few days, wild with speculation as to the attack in this vulnerability note: Multiple DNS implementations vulnerable to cache poisoning (via CERT/CC). Disclosed on Tuesday (and patched by Microsoft in MS08-037, patched by BIND, by a whole host of vendors) the attack can lead to cache poisoning. Here’s the NVD description:

The DNS protocol, as implemented in (1) BIND 8 and 9 before 9.5.0-P1, 9.4.2-P1, and 9.3.5-P1; (2) Microsoft DNS in Windows 2000 SP4, XP SP2 and SP3, and Server 2003 SP1 and SP2; and other implementations allow remote attackers to spoof DNS traffic via certain cache poisoning techniques against recursive resolvers, related to insufficient randomness of DNS transaction IDs and source ports, aka “DNS Insufficient Socket Entropy Vulnerability.”

Information that’s been disclosed publicly – from vendors, from vulnerability analysts, and from patch analysis – suggests it’s a lack of entropy in the query ID field together with a lack of source port entropy. Kaminsky’s been working hard with a boatload of vendors to get this fixed. He’s also taken a lot of flack from folks (myself included; I’ll get to that in a minute). Some of them have relented.

Disclaimer: I don’t have any additional details above and beyond what is publicly available.

As for myself, so far this sounds like something we’ve known about for a long time:

6.1. Query ID Prediction

With only 16 bits worth of query ID and 16 bits worth of UDP port
number, it’s hard not to be predictable. A determined attacker
can try all the numbers in a very short time and can use patterns
derived from examination of the freely available BIND source
code. Even if we had a white noise generator to help randomize
our numbers, it’s just too easy to try them all.

The date on that paper – from Paul Vixie, one of the primary architects of BIND, arguably the major DNS server in the world – is from 1995. Never mind that Amit Klein has been looking at this topic in the past few years. Some of this reminds me of the Zalewsky TCP sequence number stuff and all of the RFC 1948 problems that were brought up in 2001 (CERT) because vendors didn’t apply best known practices.

We’ll keep an eye out for “the goods” come Blackhat. ATLAS hasn’t picked up any significant jump in scanning for DNS:

TCP/53 scans, 1 week

UDP/53 scans, 1 week. That orange jump? I think that’s Poland. Probably Zalewski and his buddies scanning and inventorying…

In the meantime, you can test your server – and verify they’ve been correctly patched – via a great tool from our friends at DNS OARC: porttest.dns-oarc.net.

This entry was posted on Friday, July 11th, 2008 at 2:29 pm and is filed under ATLAS, Attacks, Critical Infrastructure, Interesting Research, Vulnerabilities. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.