30 Days of DNS Attack Activity
With the array of activity as of late surrounding Kaminsky’s DNS Cache Poisoning vulnerability, we checked some of our various data sources to get an idea of what folks are seeing activity-wise as a result – if anything discernible. There are three discrete data sources I had a look at in hopes of identifying any increased activity levels surrounding DNS cache poisoning attacks, reconnaissance, and any other apparently related activity. Of the three, two were illustrative of pronounced activity levels:
- Single packet UDP/53 DNS version queries targeting ATLAS sensor networks
- DNS “misuse” activity detected by Arbor’s Peakflow CP & TMS systems
Regarding the third, I had a look at global UDP/53 and ICMP traffic levels from across 96 networks for the last 30 days, representing an aggregate of ~16 Tbps, and even when analyzing each individual network, saw no aggregate traffic increases potentially indicative of DNS cache poisoning attempts. That’s not to say they’re not there, they clearly are (as you’ll see below), but when observing from a network-wide perspective, the actual impact on aggregate traffic levels within those Network & Transport Layer and IP Protocol sets appears to be largely negligible.
When analyzing single packet DNS version queries (i.e., in order to generate lists of vulnerable or immune servers) targeting ATLAS sensor IPs (millions of unique IPv4 addresses distributed globally) we saw a 49.8% increase in the past 30 days over the prior 30 days. While UDP/53 traffic doesn’t represent a considerable amount of the total activity observed by our darknet sensors, the version queries themselves represent ~87% of all UDP/53 traffic we receive on our ATLAS sensors. These queries are targeting IPs that have no valid resolvers or authoritative DNS servers, or legitimate hosts, for that matter, so it’s either misconfigured or malicious traffic, and most likely the latter. While much of this “malicious” traffic is likely vulnerable DNS server “census” queries from research types, a good bit of it is likely attributed to miscreant reconnaissance as well. While I don’t intend to share details of the source ASNs or IPs here, you can pretty easily distinguish legitimate research efforts from potentially malicious activities with such data.
While the country code data may help to shine a light on some of the motivations, alone it’s not particularly interesting. That said… As illustrated in the graphic above, U.S. IP address sources top the source country list for version scanning activity, accounting for ~38%. Taiwan and Spain sources account for about 12% each,with Brazil, Greece, Germany and China rounding out the top source countries list.
Plotting UDP/53 attack activity (the thicker dark “pinkish red” line below) across Arbor’s “anonymous statistics program” participants (~70 ISPs) illustrates an order of magnitude increase in UDP/53 and/or DNS events beginning around July 9, 2008. Note that while most of the data from the anonymous statistics program is based on Network and Transport layer attributes of traffic, there are specific DNS capabilities that exist in our Threat Management System (TMS) product that deal extensively with payloads as well. Given that this vulnerability was partially disclosed on July 8, I suspect a great deal of this traffic is name server vulnerability scanning, as opposed to malicious cache poisoning attempts, although there may well be a mix of the latter.
Also interesting in the chart is the obvious and near corresponding uptick in ICMP events – the brown line in the chart. A great deal of this may be participating ISP sensors detecting ICMP backscatter activity from scanning and/or cache poisoning attempts. Activity, that from an aggregate perspective, when simply looking at traffic across 96 ISPs, as noted above, wasn’t perceptible. I guess this goes to show that digging a bit deeper often reveals more interesting data.
One other interesting observation is that most of the activity we’ve seen thus far kicked off in conjunction with the disclosure itself, although there is a perceptible activity level increase just subsequent to the 13-day “leak” as well. This could be more vulnerability scanning, although it could also be actual cache poisoning attempts, and given that several exploit tools are now openly available, I don’t expect this to improve any time soon.
Finally, these numbers are a couple days old, as many of our teams’ analysis systems are still offline during our Ann Arbor office move. So, if we get any more interesting data worth highlighting, we’ll pass it along.
In summary – better patch’m if ya got’m!