the secure:channel

Click here to read more about SpamStopsHere, the e-mail security company that brings you this blog.

I wrote earlier this week that there is a new exploit that makes it easy to poison the cache of public recursive DNS servers. Here it is after Dan Kaminsky’s presentation at the Black Hat conference, where he made it painfully obvious that even private recursive nameservers can be very vulnerable due to the hierarchical DNS chain. I wrote how this can be a security issue, but it can also be used in a DoS attack.

The acronym DoS stands for denial of service, which is where a service is made unavailable by taxing it beyond it’s current limits. The acronym DNS stands for domain name system which is the hierarchical system that resolves mnemonic Internet site names to their numeric Internet addresses, also known as Internet protocol or IP addresses. Many users share a DNS server to resolve names.

Using this exploit, it’s possible for hackers to have a DNS server resolve a computer’s name to the wrong numeric address, basically redirecting any traffic sent to the host with that name. Anyone sharing that DNS server would then have specific traffic misdirected.

Today I provided some security consulting for a company that had a Web site that was receiving too many requests for it to process. When reviewing the web site’s logs, it appeared that the site was getting requests for Web sites that it wasn’t hosting. The requests were for very popular sites such as ads.doubleclick.net and yahoo.com. These hostnames shouldn’t have been resolving to the IP address of the target Web site. Instead, these names should have been resolving to the IP addresses of Web servers that can handle much larger amounts of traffic.

There was unfortunately no way with the tools that we had to filter out traffic by hostname. The apache Web server, without recompiling, could only handle 256 connections per second. The traffic destined for the IP address of the Web site was arriving at a rate above that limit. I offered two suggestions.

Reverse Proxy

One way to resolve an issue like this is to set up a reverse proxy in front of the apache Web server. Since the web server was running Fedora Linux, the squid caching proxy server was readily available to us as a package. As a result, this could have been quickly configured to answer web requests and even filter out requests to sites other than the hosted site. For requests for the hosted site, squid would be configured to send them to the local apache web server. This increases the amount of traffic that the Web services can handle while keeping apache in the back end.

Changing IP Addresses

Another alternative, if your Web server has other IP addresses available that aren’t being used, is to check to see if the flood of traffic arriving is destined for those available IP address also. If one of those IP addresses is not being flooded, you can change the public DNS records for the Web site address to resolve it to that fresh IP address. Anyone who hadn’t visited the site recently could then instantly visit the site at the new trouble free IP address. Anyone that had visited the site recently might have to wait until the old DNS records expired from their own DNS server’s cache. A DNS server caches records to speed up response times. The length of time that a record is cached is specified in a DNS record by the TTL setting, which is short for time to live. Keeping a reasonably short TTL on your DNS records can allow one to respond quicker to emergency changes of IP addresses.

In conclusion, it appears that the new DNS cache poisoning vulnerability is being used to resolve very popular Web site addresses to a target Web site’s IP address. When a user of that poisoned DNS server attempts to visit the popular site, they end up visiting the target Web site. The target Web site then get’s all of the traffic for not only one popular Web site, but multiple sites, even if the target site can’t handle the traffic. This basically turns all of the users of that DNS server into attack vectors, making this new exploit a force multiplier for any typical DoS attack and turning it into a very powerful distributed denial of service attack, also known as a DDoS attack.

Although I can only guess that this is what happened, it seems a likely scenario. To determine that this was actually what was occuring, I could have had the visitors query a name that I provided DNS for and then monitored DNS queries arriving for that name to see if they were coming from the same DNS server, and possibly even see if that DNS server was offering public recursion and resolving the redirected hostnames to the target IP address. Unfortunately neither I nor the company targetd had the time to do this research.