n this first couple of months of 2012 we have assisted to an escalation of cyber attacks made by groups of hacktivist, first Anonymous, that have hit main institutions and agencies all over the world. The modus operandi of the group is now well known, attacks that have crippled many victims were mainly of DDoS type, in this way the group has made many web sites inaccessible.
Despite the large number of operations carried out successfully, from the attack to FBI to the one against the CIA, up to now have been warded off attacks capable of making inaccessible the whole Internet. For a long time now, in Internet has persistently circulated the news of a possible attack on a global scale which has as its goal to bring down the entire Internet’s Domain Name System (DNS) called a “troll” by members of Anonymous.
Many experts believe the group is working for some time to a new generation of cyber weapon to use in future operations. Until today much of the success of the operation made by the group is related to two main factors, the surprise effect and the critical mass of supporters engaged in the actions. This means that in addition to conventional tools for DDoS (eg LOIC) it’s normal to expect the genesis of new methods of attack.
What would be an effective and attractive attack technique for the group of hacktivist?
A highly efficient method is known as DNS Amplification Attacks, although known for years could be extremely damaging to the current structure of internet, let’s examine it in detail.
The Domain Name System (DNS) is implemented through a tree-like system of delegations. A recursive process is used to follow the chain of delegations, starting at the Root zone, and ending up at the domain name requested by the client. A recursive name server may need to contact multiple authoritative name servers to resolve given name. Ideally, a recursive name server should only accept queries from a local, or authorized clients but in reality many recursive name servers accept DNS queries from any source. To worsen the situation, many DNS implementations enable recursion by default, even when the name server is intended to only serve
authoritative data. We say that a name server is an “open resolver” if it provides recursion to non-local users.
The DNS system has a hierarchical structure, at the top there are the “root” nameservers containing 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 and so on.
Imagine that we are interested to resolve the name securityaffairs.co so a client send the request to the DNS server. The root server will provide info regarding the “.co” and info regarding the next level in the structure “securityaffairs” domain. The “securityaffairs” nameserver is then able to provide the actual binding from the logical name and related IP address. Resuming a recursive process is used to follow the chain of delegations, starting at the Root zone, and ending up at the domain name requested by the client. A recursive name server may need to contact multiple authoritative name servers to resolve given name (e.g. http://www.net.compsci.googleplex.edu).
Let’s image the availability of a Botnet that send spoofed address queries to an Open Resolver causing it to send responses to the spoofed-address target. In this way the Resolver became the the cyber gun against the victims, for which we have spoofed the address, parteciping in an attack on it.
This way to operate of DNS ROOT server is called “recursive mode”, a client send the request to the DNS server for the entire name then leaves it to perform all the necessary requests (either recursive or iterative) on its behalf.
There is also another mode to resolve a logical name called “interactive mode“, in this case 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 to make the complete translation.
Of course to speed up the described process are used caching mechanism by the name servers involved. This is the vulnerability in the process. 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. Each request sent to a DNS server include a source address to which the reply should be sent, but this IP addresses can be spoofed, in this way is, a request can be sent from one IP address but the DNS server will think it was sent by a different address replying it.
The attack is really dangerous considering also the critic masses usable by groups of hacktivist and considering also that typically a DNS query consisting of a 60 byte request that can be answered with responses of over 4000 bytes, amplifying the response packet by a factor of 65. In literature there are several variant of the attack one of them include a query only for the root name servers, 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 request packet.
The attack method is really powerful, in fact sending small amount of data that compose a DNS request is it possible to redirect large quantity of data to a spoofed address, so sending a large number of requests to the server it is possible to flood the victims with the replies. The different size between the dimension of the request and related response is called “amplification” attacks. To hide the origin of the attacks it is possible to modify the header of each UDP request this means that group like Anonymous could maintain anonymity adopting VPNs.
Which are the main effects of this kind of attacks?
A DNS recursion attack is essentially an amplification DoS attack. There are sever related effects like:
- DNS servers configured to provide recursion receive the spoofed requests and generate replies to the spoofed address (i.e., the victim). The performance of these systems may be negatively affected when processing the spoofed requests.
- The spoofed DNS requests query the root name servers, part of the internet’s critical infrastructure, indirectly affecting them.
- The traffic then traverses the internet backbone, affecting the internet service provider and any upstream providers until it reaches the intended target.
- The intended target receives large amounts of inbound DNS replies that could consume all available resources on its router, depending on available bandwidth. Even if the traffic is reduced through rate limiting or other bandwidth throttling measures, the attack could impact other legitimate business along the path of the attack.
How to avoid this type of attacks?
It’s simple, it is enough to disable recursion as recommended by US-CERT bullettin, but as usually this setting for DNS ignored. Given enough servers that enable recursion, large quantities of traffic can be produced from relatively modest numbers of queries. The Internet Engineering Task Force has proposed a best practices to solve the problem, an approach to “ingress filtering” of packets, called BCP 38, that would block forged traffic like DNS amplification attacks. But the proposal hasn’t moved very far forward since it was first submitted in 2000.The best countermeasures against DNS amplification must be taken on server side do not returning replies to “.” queries and return shorter responses, reducing the amplification process. Another option is the limitation of DNS requests to authorized clients.
The interest in the attack technique of the group of hackers is shown by a document published recently on Pastebin announcing an operation called “Operation Global Blackout” an attack on the Internet’s root DNS servers.
Many experts are convinced that a similar attack would have little chance of success for several technical reasons. Despite their position I believe is fundamental to share information about what is considerable of a vulnerability in a process, hoping that the problem is not overlooked with disastrous consequences.