Home / News I have a News Tip

Possible First Attacks on DNS Flaw Have Been Reported

The existence of the DNS flaw was revealed earlier this month by security researcher Dan Kaminsky and the code that could act as a blueprint for an attack via the flaw was published last week by Metasploit. On Friday, a user named James Kosin posted an excerpt from a server log to a Fedora Linux mailing list, claiming it proved attacks based on the DNS flaw had begun. Kosin post reads:

"The DNS attacks are starting!!! Below is a snippet of a logwatch from last night. Be sure all DNS servers are updated if at all possible. The spooks are out in full on this security vulnerability in force. THIS IS YOUR LAST WARNING...!!! Patch or Upgrade NOW!"

Read full story: ZDNet

Follow CircleID on
SHARE THIS POST

If you are pressed for time ...

... this is for you. More and more professionals are choosing to publish critical posts on CircleID from all corners of the Internet industry. If you find it hard to keep up daily, consider subscribing to our weekly digest. We will provide you a convenient summary report once a week sent directly to your inbox. It's a quick and easy read.

I make a point of reading CircleID. There is no getting around the utility of knowing what thoughtful people are thinking and saying about our industry.

Vinton Cerf, Co-designer of the TCP/IP Protocols & the Architecture of the Internet

Share your comments

The evidence is very weak. Probably not an attack. Alan U. Kennington  –  Jul 29, 2008 9:21 AM PDT

The packet log which is reported by Kosin is of the exact same type that I have been seeing since July 14, more than a week before the publication of full details of the DNS vulnerability. I have seen 227 packets of this type (denied cache queries) in the last 5 days on one DNS server and 839 in the same 5x24 hours another DNS server. I have been logging all port 53 packets with a packet sniffer (tcpdump), and these supposed attacks are never followed up by anything else, such as a suspicious barrage of spoofed DNS responses.

When you look at the IP addresses of the DNS clients for these denied cache requests, they turn out to be in the networks of some fairly respectable organizations. The majority of the packets (including those in the Kosin report) have reverse DNS translation somewhere within the control of ns1.gatech.edu. This has been so since 14 July when I first noticed these packets. Some of the reverse DNS translations are complete (down to the last nibble), like drudgeon4.cc.gt.atl.ga.us (143.215.129.25).

For example: client 143.215.129.25#10053 query (cache) 'rB6CIo_XgRk6BkFBOLqNSAAAAAAnzwUAAAAAANDECgA=.ports.dns-integrity-scan.com/A/IN' denied.

Other IP source addresses in my logs include:
149.20.54.35 dns-surveyor.measurement-factory.com
216.235.12.1 ricky.afilias-nst.info
132.239.1.115 portscan.ucsd.edu
38.229.0.10 bahamut.iad01.cymru.com

Shortly after I installed the patched BIND from source, I was getting almost identical scans from Dan's own servers every 6 hours. He confirmed to me in e-mail that he was doing this.

A large number of these denied cache requests also come from within the reverse DNS zone of stargate.com, like 208.78.169.236. Even though these come in sets of three in less than a second, once again there is no follow-up with spoofed DNS responses.

So far, I've seen nothing that looks like a barrage of spoofed responses. That would be a strong indication of a serious attack.

Now it could be that the 1000 denied recursive DNS requests I have seen in the last 5 days are programmed to only follow up with DNS responses if they don't get a denial. And they could be spoofed IP source addresses. However, they just don't look suspicious to me. They look just like researchers collecting survey data. If you use on of the various DNS resolver tests on the web, you're likely to attract these surveybots.

On the other hand, it is quite possible that some bad guys are probing all the DNS servers which allow recursion from any client IP address for future attacks. That's all that these probes discover, after all. So this would be useful to bad guys who want to launch a DNS poisoning attack where the initial DNS request comes from the wide open Internet, not from, say, some javascript code in a user's browser. But this would be picking only the very low-lying fruit. Surely no self-respecting bad guy would stoop so low!

Not evidence of an exploit -- I concur Richard Klein  –  Jul 29, 2008 7:30 PM PDT

The querry is suffixed with Dan Kaminsky's "ports.dns-integrity-scan.com" and originates from the correct IP address (143.215.129.25). I found 419 such denied querry cache requests on our primary, 392 on our secondary, and 397 on our tertiary nameservers from July 22-29.

I was pleased to see that all of our machines rated "GREAT" when using Duane Wessel's Standard Deviation DNS Port dig test:

dig +short porttest.dns-oarc.net TXT

Our primary nameserver scored a stand dev of 4018, which, until yesterday, was off the scale for Duane's published table:

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
(revised 07/28)
https://www.dns-oarc.net/oarc/services/porttest

I will continue to run CacheAudit, but I highly doubt that there will be any post-patch issues.

Expected standard deviation for Wessels' test. Interpretation. Alan U. Kennington  –  Jul 29, 2008 9:13 PM PDT

Richard,
That std dev 4018 seems very low to me. By my calculations, the std dev should be sqrt((N^2 - 1)/12) for a uniform distribution with N values, which is almost exactly N/(2sqrt(3)). For 64,000 UDP source ports, you should get std dev = 18475. Your std dev = 4018 suggests N = 4018 * 2sqrt(3) = 13918. Is that the range of UDP source ports you think you are using?

The good thing about Wessels' graphical test dnsentropy is that you can check that your NAT is not converting random UDP source ports to sequential ones or more predictable ones.

By the way, since 4.4 hours ago I have been getting these info messages in the BIND logs.

149.20.56.10#10053: query (cache) 'not-an-attack.dan-kaminsky.browse-deluvian.doxpara.com/ANY/IN' denied

This is either Dan trying to reassure net admins, or a rather shabby disreputable bad guy pretending to be Dan!

How a bad guy can get around the limitation on allow-recursion subnets. Alan U. Kennington  –  Jul 29, 2008 9:44 PM PDT

I stated above that cache queries from the outside Internet would only be a danger for a DNS server which allows recursion from the outside Internet. In BIND configuration files, the set of subnets which are permitted to request such recursion is specified in the allow-recursion block.

In theory, if the allow-recursion block of subnets includes only hosts on the customer premises, the bad guy would need to run code (such as javascript or java or even just html) from an application (such as a browser) inside the customer premises to launch the "race" to satisfy a DNS request, thereby poisoning the cache.

However, since then it has occurred to me that if the CP's firewall/router does not prevent the arrival of UDP packets which spoof IP source addresses which are within the CP's local subnets, the DNS request "race" could be initiated from outside the customer premises, e.g. from hosts controlled by the bad guys. In this case, the bad guy could launch DNS "races" all day long, thereby very greatly increasing the chances of success. A fairly good guess for a CP's local subnet would be the /28 subnet including the IP address of the good guy's DNS server.

My observation (about the need to block spoofed UDP packets) is surely common knowledge, but if Dan Kaminsky's new cache poisoning exploit is combined with an incorrectly firewalled DNS server, whatever protection is given by DNS request UDP source packet randomization would be seriously weakened by the opportunity given to the bad guy to launch "DNS races" 24 hours a day, every day.

Conclusion:
If the IP source addresses in those "query (cache) denied" messages start to look like your local subnets, I would start to get very worried.
Solution:
Check that the firewall/router is blocking UDP packets which spoof IP source addresses in your local subnets.

My observation (about the need The Famous Brett Watson  –  Jul 29, 2008 10:32 PM PDT

My observation (about the need to block spoofed UDP packets) is surely common knowledge…

One would certainly hope that it's common knowledge in the appropriate circles. Even so, just in case it's slipped someone's notice, it's worth mentioning that address filtering at the network boundary (based on static knowledge as to which addresses are on which side of the router) is a long-recognised best current practice. In particular, see BCP 38 ("Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing"), and BCP 84 ("Ingress Filtering for Multihomed Networks"). None of this is a cure for the current problem as a whole, but every little bit of defence helps.

To post comments, please login or create an account.

Related

Topics

New TLDs

Sponsored byAfilias

IP Addressing

Sponsored byAvenue4 LLC

Domain Names

Sponsored byVerisign

DNS Security

Sponsored byAfilias

Whois

Sponsored byWhoisXML API

Cybersecurity

Sponsored byVerisign