Biz & IT —

How Anonymous plans to use DNS as a weapon

An Anonymous threat to take down the global Domain Name Service may have been …

How Anonymous plans to use DNS as a weapon

After engaging in a recent rash of attacks in retaliation for the takedown of file-sharing site Megaupload, the Anonymous denial of service "cannons" have been firing considerably fewer shells of late.

While Anonymous group members managed to take down Interpol's website on February 28 (largely by using a Web version of their "Low Orbit Ion Cannon" denial of service tool) and have defaced a number of vulnerable sites (including, most recently, sites belonging to Panda Security), threats to take down bigger targets have failed to materialize. What some believed to be the group's boldest plan yet—an effort to bring down the Internet's entire Domain Name System (DNS)—is now being called a "troll" by members of the group.

But this doesn't mean the threat of more targeted denial of service attacks based on DNS attacks have gone away. Disappointed with the current denial of service tools at their disposal, members of Anonymous are working to develop a next-generation attack tool that will, among other options, use DNS itself as a weapon.

An amplifier

The scale and stealthiness of the technique, called DNS amplification, is its main draw for Anonymous. DNS amplification hijacks an integral part of the Internet’s global address book, turning a relatively small stream of requests from attacking machines into a torrent of data sent to the target machines, potentially delivering network traffic of tens or hundreds of gigabytes per second without revealing the source of the attack. It does so by using a vulnerability in the DNS service that's been known since at least 2002.

The DNS system is organized hierarchically. At the top of the hierarchy are the "root" nameservers. These contain information on where to find the nameservers responsible for the next level down in the hierarchy, the nameservers for things like ".com" and ".org" and ".uk." In turn, those nameservers contain information about the next level of the hierarchy, so the ".com" nameserver provides information on where to find the "arstechnica" nameserver. The "arstechnica" nameserver is then able to provide the actual mapping from a descriptive name to a numerical IP address.

Doing a DNS lookup requires accessing all these different levels of the hierarchy. There are two ways that a DNS resolver (the piece of software that looks up DNS entries, which can either be a standalone thing on a client machine, or a part of a DNS server) can work: an iterative mode and a recursive mode. In the iterative mode, the resolver first queries the root nameservers for the top-level domain's nameservers, then queries the top-level domain's nameservers for the second level domain's nameservers, and so on and so forth. The resolver contacts the different nameservers directly, one by one, until it has either found the answer it needs or given up because the answer doesn't exist.

In recursive mode, the resolver's job is much simpler: it asks one DNS server for the whole name, then leaves it to the server to perform all the necessary requests (either recursive or iterative) on its behalf.

How DNS recursion is supposed to work, in three easy steps.
How DNS recursion is supposed to work, in three easy steps.
Sean Gallagher

There is also extensive caching by all the servers involved; many requests are serviced by using information stores in the cache rather than having to query other servers each time a machine wants to know how to find "google.com," for instance.

Typically, the DNS resolvers built into client operating systems ask nameservers (usually the ones provided by ISPs) to perform recursive queries on their behalf. The lookups then performed by these servers to fulfill the requests are typically iterative.

Here's where the problem arises. The response to a DNS query can be considerably larger than the query itself. In the best (or worst) case, a query of just a few dozen bytes can ask for every name within a domain and receive hundreds or thousands of bytes in response. Every request sent to a DNS server has a source address—an IP address to which the reply should be sent—but these source addresses can be spoofed. That is, a request can be sent from one IP address but the DNS server will think it was sent by a different address.

Using these two things—recursive lookups that return large amounts of data to small queries, and spoofed source addresses—attacks can be made. The attacker first finds a server that is configured to enable recursive lookups. He then sends a large number of requests to the server, spoofing the source address so that the server thinks that the victim machine is making the request. Each of these requests is chosen so that it generates a large response, much larger than the queries themselves. The server will then send these large responses to the victim machine, inundating it with traffic. The disparity between the request size and the response is why these attacks are known as "amplification" attacks.

While consensus is that publicly accessible DNS servers should have recursion disabled, precisely to avoid this kind of problem, the reality is that not all do. Given enough servers that enable recursion, large quantities of traffic can be produced from relatively modest numbers of queries.

An attacker's benefits

A paper (PDF) presented at the 2006 DefCon security conference by Baylor University's Randal Vaughan and Israeli security consultant Gadi Evron documented a series of DNS amplification attacks in late 2005 and early 2006—including one on Internet service provider Sharktech that achieved volumes of packets "as high as 10Gbps and used as many as 140,000 exploited name servers." Depending on the number and network capacity of servers targeted, it’s reasonable to assume a coordinated attack by Anonymous could generate several times that volume.

As Vaughan and Evron wrote, "A DNS query consisting of a 60 byte request can be answered with responses of over 4000 bytes, amplifying the response packet by a factor of 60."

In a variant of the attack described by SecureWorks' Don Jackson, the query simply asks the server for a "root hint": the addresses of the name servers for the "." domain, the home of the Internet's root DNS servers. Because there are a large number of root name servers, and because the implementation of DNS-SEC has added certificate data to root server responses, the data returned for each request is about 20 times larger than the query packet.

A comparison of the payloads of a DNS "root hint" query and its response. Not all data shown.
A comparison of the payloads of a DNS "root hint" query and its response. Not all data shown.
Sean Gallagher

Since it’s possible to hide the source of an attack with UDP through forged headers, and because it requires relatively little bandwidth from the attack side, DNS amplification has some obvious benefits to groups like Anonymous. While attackers can't use the Tor anonymizing network (Tor doesn't transfer UDP traffic), they can use various VPNs to add another layer of security.

Aside from the mass of data a DNS amplification attack can create, an attacker gets other benefits from the technique. DNS amplification relies on UDP, a "connectionless" protocol under which packets get sent to a destination without any sort of "handshake" or even a guarantee it will be received. Because there's no sort of negotiation (and because DNS data isn't something usually filtered by application firewalls or other systems), this isn't a simple attack to prevent.

Can anything be done?

Channel Ars Technica