Attacking the DNS System Tutorial

This tutorial is written by mango1122 from governmentsecurity. Since its very informative, I have decided to post this tutorial over here.

--------------
INTRODUCTION
--------------

Domain Name System (DNS) associates various sorts of information with so-called domain names;
most importantly, it serves as the "phone book" for the Internet: it translates human-readable
computer hostnames, e.g. en.wikipedia.org, into the IP addresses that networking equipment
needs for delivering information. It also stores other information such as the list of mail exchange
servers that accept email for a given domain

The Berkley Internet Name Service (BIND) is the most common form of DNS server used on the Internet.
BIND typically runs on UNIX type systems. The DNS server stores information which it serves out about a
particular domain (also referred to as a namespace) in text files called zone files.A client (the resolver)
maintains a small amount of local cache which it will refer to first before looking at a local static host�s file
and then finally the DNS server. The result returned will then be cached by the client for a small period of time.

When a DNS server is contacted for a resolution query, and if it is authoritative (has the answer to the question
in its own database) for a particular domain (referred to as a zone) it will return the answer to the client. If it is
not authoritative for the domain, the DNS server will contact other name servers and eventually it will get the
answer it needs which is passed back to the client. This process is known as recursion.

Additionally the client itself can attempt to contact additional DNS servers to resolve a name. When a client does
so, it uses separate and additional queries based on referral answers from servers. This process is known as iteration


----------------------------
ATTACKING THE DNS CACHE
----------------------------

The most common attacks on DNS can be classified as

Zone Transfers or information disclosure attacks
Cache poisioning


CACHE POISIONING

Lets say a client in domain xyz.com wants to resolve www.google.com

1. The client will contact its configured DNS server and ask for www.google.com to be resolved.
This query will contain information about the client�s source UDP port, IP address and a DNS transaction ID.

2.If the information is available locally i.e cached ,it is returned to the client

3. If not then the client�s DNS server will contact the authoritive name server for google.com and resolve the query

4. The answer is passed back to the client and also cached locally in the DNS server of xyz.com (say ns1.xyz.com) and the client

5. Note the client only accepts the DNS information if the server replies with the correct client�s source UDP port, IP address and the DNS transaction ID




--------------------------------
Attack #1 � The Birthday Attack
--------------------------------

To poison the cache the attacker needs to

1 Send a number of resolution requests for google.com.An important thing
to note here is that each query for google.com is assigned a different transactio ID.

2. While the DNS resolves this the attacker sends a large number of spoofed replies
from ns1.google.com with different transaction ID.The attacker hopes to guess the
correct transaction ID as used the two name servers

Finding the correct IP addresses is easy; we know our target, and we know the addresses of the legitimate
nameservers for the domain to be hijacked. Finding the port is slightly harder. We know that the destination
port of the recursive query is UDP port 53, but the source port is a moving target. Fortunately for our attacker,
BIND will more often than not reuse the same source port for queries on behalf of the same client. So, if the
attacker is working from an authoritative nameserver, he can first issue a request for a DNS 3lookup of a
hostname on his server. When the recursive query packet arrives, he can look at the source port. Chances are
this will be the same source port used when the victim sends the queries for the domain to be hijacked.


--------------------------------
Attck #2 - Poisioning the Cache
--------------------------------

1. To obtain the source port we use a perl script.It needs to be run from an authoritative name server which
the attacker controls to query the target name server for a hostname for which the attacker�s machine is authoritative.

Another alternative would be to use a packet sniffer.

dns1.pl 10.10.10.50 www.google.com
source port: 34567

2. Now we run the second script written by Ramon Izaguirre called hds0.pl2.The script does most of the work by spoofing the reply from ns1.google.com

./hds0.pl (ns1.google.com) (ns1.xyz.com) (source port obtained from the earlier script) (spoof target)


To observe if the attack was successful simply query the target name server:

dig @12.12.12.12 www.google.com
www.google.com 86400 IN A 10.10.10.10

The attack is successful as google resolves yo 10.10.10.10

The script is available here-hxxp://securityvulns.com/files/birthday.pl


--------------------------------------
Attack #3 - DOS Attack on DNS servers
--------------------------------------

DNS servers like other Internet resources are prone to denial of service attacks.The only difference here would
be that DNS server uses UDP for name resolution.To create a DOS attack on the DNS server a script such as
dnsflood.pl can be executed on multiple clients to create the traffic.DNSflood works by sending many thousands
of rapid DNS requests, thereby giving the server more traffic than it can handle resulting in slower and slower
response times for legitimate requests.

The script can be obtained from - hxxp://packetstormsecurity.org/DoS/dnsflood.pl

In the following example we use the scrip to create a DOS effect on the DNS server and then query the DNS for name resolution

perl dnsflood.pl 192.168.10.1
attacked: 192.168.10.1...

To assess the impact of this attack on performance the attacker from another machine first clears his local cache and then
queries the target name server. Clearing the local cache will ensure the resolver gets the information from the server and not locally.


C:\>ipconfig /flushdns
Windows IP Configuration
Successfully flushed the DNS Resolver Cache.

C:\>nslookup
DNS request timed out.
timeout was 2 seconds.
*** Can't find server name for address 192.168.10.1: Timed out
*** Default servers are not available
Default Server: UnKnown
Address: 192.168.10.1

> ms2.xyz.com
Server: UnKnown
Address: 192.168.10.1

DNS request timed out.
timeout was 2 seconds.
DNS request timed out.
timeout was 2 seconds.
*** Request to UnKnown timed-out

>exit

If this attack was multiplied from a number of machines then the impact would be even greater.


------------
CONCLUSION
------------

These are only a few possible exploits involving the DNS Spoofing vulnerability and there are,probably,
many more waiting to be discovered. Discovery and implementation is limited only by the active imagination of the attacker