|
Brought to you by:
Suppliers of:
|
|
|
| |
Name servers that accept and forward external DNS queries may be abused to behave as traffic amplifiers, threatening network integrity by bandwidth saturation (DNS Smurf).
A "deaf" pseudo name server may be used to discover the query chain a DNS query takes through various name servers, allowing a trace-route like route discovery (DNS Traceroute).
This attack is a classic Denial-of-Service attack that can possibly bring an entire network to its knees. |
| |
Credit:
The information was provided by: TESO.
The DNS Smurf technique was discovered by the s0ftpj team.
See our article regarding Smurf:
NetScan.org raises awareness on "Smurf Amplifiers"
|
| |
Vulnerable systems:
All types of name servers that accept external queries might be vulnerable. Especially those that forward the queries to other name servers, or those that have excessive retry attempt values. The common value for retry is three times, but many misconfigured servers retry over 20 times when sending out a query packet.
Note that this attack is completely different from the DNS Smurf attack discovered by s0ftpr0ject. However, it does exploit weaknesses in default BIND configurations too.
Impact:
By abusing multiple name server chains as traffic amplifiers an attacker can easily saturate any network link. The traffic to the victim IP is caused by the query packets, which are sent by each name server in the chain to the fake authoritative name server in the victim network.
For the last few years denial of service (DoS) attacks that are based on bandwidth saturation have been a serious problem. A few years ago, when the Smurf ICMP denial of service attack got publicly known nearly everyone was able to saturate any link by abusing other networks as a traffic amplifier. Since then numerous amplify attacks have been discovered, such as The "MAC DoS Attack", a x37 traffic amplify attack and DNS Smurf (through query/answer ratio), the original posting of the Smurf attack is ICMP ECHO Requests to Broadcast addresses (ICMP Smurf attack).
Any method that allows an attacker to amplify his traffic can be abused for a denial of service attack.
Explanation:
When a name server receives a query, most name servers usually start forwarding the query to some other name servers. There can be quite a long path of forwarding queries. However if the query is not resolvable because there is no name server listening on the remote host, every forwarding name server will start to resolve it on their own, by querying the authoritative name server. In the default configuration each name server will send the query three times, after 0, 12 and 24 seconds.
This can be used to discover the path of name servers. To do this an attacker would query the first name server for a domain he can see the packets on, at best the domain points to the query host itself. Then the attacker would record all name servers that send out a packet to him. After having done this, the attacker would try with another name server of the ones he got queries from. In the best case he will receive queries from all hosts but one missing. The missing one is the first host in the route. After having reduced the list by one he will start over with the reduced list until there is only one name server remaining, which is the last in the querying chain.
Through seeking especially long paths, where a lot of name servers are queried, this can be abused as a traffic amplifier attack, as shown below.
Since the important entries such as the NS entry is in the cache of each name server after the first query, the attack is very fast pacing after the first query, since no additional packets are sent to the attacker and the attacker may spoof the UDP query packets. If the attacker were clever, he would use a very short lifetime for his NS entry, while using a long lifetime for the victim sub-domain. After the first query succeeded he will just shut his name server down and send out spoofed query packets at a very fast rate.
Example:
The following data is an excerpt from initial tests conducted against a vulnerable name server.
08:07:24.943598 ns2.domain > victim.domain: 15121 (35)
08:07:32.747253 ns3.domain > victim.domain: 8536 (35)
08:07:32.832604 ns2.domain > victim.domain: 15121 (35)
08:07:39.819289 ns3.domain > victim.domain: 8536 (35)
08:07:40.670228 ns1.1025 > victim.domain: 56483 (35)
08:07:44.405556 ns4.domain > victim.domain: 5306 (35) (DF)
08:07:48.928981 ns2.domain > victim.domain: 15121 (35)
08:07:52.669825 ns1.1025 > victim.domain: 56483 (35)
08:07:56.107063 ns3.domain > victim.domain: 8536 (35)
08:07:56.471586 ns4.domain > victim.domain: 5306 (35) (DF)
08:08:04.938187 ns6.domain > victim.domain: 26706 (35)
08:08:12.372097 ns5.2187 > victim.domain: 2352 (35)
08:08:13.826464 ns6.domain > victim.domain: 26706 (35)
08:08:16.669021 ns1.1025 > victim.domain: 56483 (35)
08:08:20.603050 ns4.domain > victim.domain: 5306 (35) (DF)
08:08:24.365990 ns5.2187 > victim.domain: 2352 (35)
08:08:30.873233 ns6.domain > victim.domain: 26706 (35)
08:08:32.658479 ns1.domain > querier.1025: 298 ServFail 0/0/0 (35)
08:08:48.369725 ns5.2187 > victim.domain: 2352 (35)
The initial DNS query packet had a size of 35 bytes, although packets up to a size of 500 bytes are possible. There are five name servers who indirectly got the query, which was send by "querier" (query packet not displayed). The first name-server that got queried was "ns1".
The query is forwarded to five other name servers, so all together there are six name servers that try to resolve the query domain. If the query domain is a normal existent domain name, the authoritative name server will answer promptly and the answer is returned to the original query host.
This is the normal case. However, if there is an authoritative name server that does not respond to the queries sent to it, all name servers will retry to resolve the domain by sending out the query packet, assuming the UDP packet they have previously sent got lost. Because all the name servers do this, the result is a traffic amplifier with factor 18 (18 packets send for each attacker packet).
Through testing about a few hundred name servers for this vulnerability, many name servers were found which will amplify with ratios well beyond 30, sometimes even exceeding 50.
Solution:
By protecting your own name servers from being abused by attackers you secure other sites at the same time. If you run BIND name servers in your network please care to read basic BIND configuration tutorials and especially documents on how to secure your BIND configuration.
Also notice that you may fall victim to the same attack, if only one name server in your network is vulnerable - That means if only one server is accepting queries for external domains from strangers, this name server inside your network will send out trusted queries to other name servers in your network, and hence can be abused too.
By taking more generic measures against being the originator network of denial of service attacks, such as improving your overall network security, you contribute to the security of all other networks in the Internet too.
In general there is no foolproof method to avoid getting a victim of a DNS Smurf. But what can you do if you get attacked?
To think of the correct response we have to think of why this attack works. It works because other name servers try to query a non-existent name server in your network and don't get any response, hence retrying again. To just filter DNS traffic to this IP is only of little use as a short-time measure. Instead, setting up a bogus DNS server on the victim IP address, which replies with bogus answers to any query it receives will reduce the impact of the attack.
However the real cause for the attack is still the number of misconfigured DNS servers out there, which accept queries for external domains from strangers. Another reason is the unreliable transport protocol, which makes it impossible for the name server to notice the unreachability of the remote victim name server.
Exploit:
TESO has created a working demonstration program to exploit the vulnerability. The program needs Libnet, a low-level network library installed, which can be obtained through:
http://www.packetfactory.net/
Exploit code can be downloaded from:
http://teso.scene.at/releases/adv3.tar.gz
|
|
|
|
|
