Attacking the DNS Protocol
DNS stands for Domain Name System and it is used to resolve domain names to IP addresses and vice versa. A DNS server will listen on UDP port 53 for name resolution queries and TCP port 53 for zone transfers which are conducted most typically by other DNS servers. Estimates put DNS as occupying almost 20% of all Internet traffic.
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 DNS client runs a service called a resolver. The resolver handles all interaction with the DNS server in order to resolve names to IP addresses using what are called records. There are many types of records, but the most common are A, CNAME and MX records.
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. Generally recursion is the most common form of resolution used.
Typical DNS Attacks
DNS servers have been attacked and compromised using a number of techniques. Examples include:
• Buffer overflow attacks to gain command level access on the DNS server or to modify zone files.
• Information Disclosure attacks such as zone transfers and obtaining version information.
• Cache poisoning attacks whereby the cache of the DNS is deliberately contaminated by an attacker. This is done using DNS Transaction ID predication or Recursive queries.
Buffer overflow attacks follow the typical network infrastructure mapping and research steps followed by execution of an exploit as outlined previously. Similarly information disclosure attacks have been discussed in the same network infrastructure mapping and research sections.
The advanced and skilled technique of cache poisoning will be discussed next. The assumption is the target DNS server is a BIND server as the majority of DNS servers on the Internet are BIND.
Cache Poisoning using DNS Transaction ID Prediction
When a client in the domain sa.com makes a request to resolve www.microsoft.com the below sequence events will typically occur.
1. The client will contact its configured DNS server and ask for www.microsoft.com to be resolved. This query will contain information about the client’s source UDP port, IP address and a DNS transaction ID.
2. The client’s DNS server since it is not authoritative for the microsoft.com domain will through recursive queries via the Internet root DNS servers contact the Microsoft DNS server and get an answer for the query.
3. This successful query will then be passed back to the client and this information is cached by both the sa.com name server and the client
The important things to note here are:
• In step 3 the client will only accept the information returned if the DNS server uses the clients correct source port and address in addition to the correct DNS transaction ID as noted in step1. These three pieces of information are the only form of authentication used to accept DNS replies.
• The returned www.microsoft.com information is cached by both the client and the server for a specified TTL (time to live) period. If another client was to ask ns1.sa.com to resolve www.microsoft.com during this TTL the name server will return the information from its cache and not ask ns1.microsoft.com
A distinction needs to be made to the transaction ID as used between the client and the name server and the transaction ID as used between name server to name server. These are in fact two different transaction ID’s as in essence they are two different requests.
The above steps can be abused by an attacker to place false information in ns1.sa.com’s cache. In the below illustration the attacker attempts to correctly guess the transaction ID used during the name server to name server communication stage.
To achieve this an attacker would:
1. Send a large number of resolution requests each spoofed with different source IP information for www.microsoft.com to ns1.sa.com. The logic of sending many requests is that each request will be assigned a unique transaction ID and even though all requests are for the same domain name, each will be processed independently.
2. The ns1.sa.com will send each of these requests to the other DNS servers and eventually ns1.microsoft.com as highlighted at the top of this section. Hence the ns1.sa.com server is awaiting a large number of replies from ns1.microsoft.com.
3. The attacker uses this wait stage to bombard ns1.sa.com with spoofed replies from ns1.microsoft.com stating that www.microsoft.com points to an IP address which is under the attacker’s control i.e. false information. Each spoofed reply has a different transaction ID. The attacker hopes to guess the correct transaction ID as used the two name servers.
If the attacker is successful the false information will be stored in ns1.sa.com’s cache. Note this is very much a name server to name server attack which will affect clients who use the target name server with false information.
BIND transactional ID’s are in the range of 1-65535.
Recall how three pieces of information are required for the query to be accepted, notably the transaction ID, the source IP and the source port. Knowing the source IP is straight forward as we know the address of the name server to be queried. The source port however presents a challenge.
More often than not BIND will reuse the same source port for queries on behalf of the same client i.e. the BIND name server. Hence, if an attacker is working from an authoritative name server, he can first issue a request for a DNS lookup of a hostname on his server from the target server and when the recursive query packet arrives the source port can be obtained.
It is likely this will be the same source port used when the victim sends the queries for the domain to be hijacked. Examine the below sniffed output of three subsequent queries for different domain names
172.16.1.2.22343 > 184.108.40.206.53
172.16.1.2.22343 > 220.127.116.11.53
172.16.1.2.22343 > 18.104.22.168.53
All three queries used source port 22343 while querying four different name servers. This is illustrated in the below diagram.
BIND versions 4 and 8 use sequential transaction ID’s. This means an attacker can easily find the current ID simply by making a query to the server and observing the ID number and be in the knowledge that the next query BIND will make to say another name server will be simply +1 of this value.
BIND version 9 assigns transaction ID’s on a random basis and does not send multiple recursive queries for the same domain name.
Example of a Cache Poisoning Attack on a DNS Server
We will examine two scripts which have been released which provide a demonstration of a cache poisoning attack.
Assume our target name server is ns1.sa.com (22.214.171.124) and we wish to poison its cache to believe www.microsoft.com resolves to 10.10.10.10 in the hope that all future queries it will receive for the TTL this information is in the cache will be directed to this 10.10.10.10. address. We know microsoft.com’s DNS server is ns1.microsoft.com (126.96.36.199).
The first of the scripts is called dns1.pl1 and was released as a proof of concept but is modified in our example to obtain the source port of the DNS server. 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. Say in our example the script is running from ns1.happydays.com and the attacker queries the target name server for www.happydays.com: dns1.pl 188.8.131.52 www.happydays.com source port: 54532
Having obtained the source port we run the second script written by Ramon Izaguirre called hds0.pl2 (this script requires the RAW IP Perl Module) which actually executes the attack.
./hds0.pl 184.108.40.206 220.127.116.11 54532 www.microsoft.com 10.10.10.10 (ns1.microsoft.com) (ns1.sa.com) (source port) (spoof targets)
To observe if the attack was successful simply query the target name server:
dig @18.104.22.168 www.microsoft.com www.microsoft.com 86400 IN A 10.10.10.10
In the above case www.microsoft.com resolves to 10.10.10.10, hence the attack has been successful. Note that if the attack was unsuccessful and the correct IP address for www.microsoft.com was obtained that you will have to wait for the duration of the TTL to expire in the cache before you can try again. Additionally it is likely the domain microsoft.com has more than one DNS server, it is highly likely that it also has an ns2.microsoft.com server. The attacker does not know which of the authoritative DNS servers of the target domain will get queried.
DNS Vulnerabilities in Shared Host Environments
A shared host environment is where one DNS server is shared amongst many users and domains. Domain parking and free DNS services facilities provide this feature whereby a user can add a domain name they have just registered.
This vulnerability is not with any specific DNS server but rather an abuse of the open trust relationship of the Internet DNS system. As such this is very much a architecture flaw than a vulnerability.
Say an attacker using a shared DNS server creates a zone file for the microsoft.com domain and adds relevant A and MX records. Now any user who has the said DNS server configured as primary from a client will when attempting to go to microsoft.com be directed to the records as configured by the client i.e. potentially false information This is because as far the DNS server is concerned it is authoritative for the microsoft.com domain and therefore does not need to query the Internet root servers and .com name servers to find the IP address of the primary Microsoft name server as it already has the required information in its zone files. Potentially if the attacker configures MX records all mail destined for the victim and which has the victims MX records queried by the abused name server could be redirected to the attacker.
This attack is illustrated in the below diagram:
Note step 3 whereby the DNS server since it has the information in its zone file does not send further recursive queries. If this information had not been present in its zone files, then the DNS server would have first contacted the Internet root servers and then the .com name servers before asking the question asked to it by the client to the given microsoft.com name server.
Example DNS Flooding – Creating a DNS Denial of Service Attack
DNS servers like other Internet resources are prone to denial of service attacks. Since DNS uses UDP queries for name resolution, meaning a full circuit is never established (as contrasted with TCP) denial of service attacks are almost impossible to trace and block as they are highly spoofable.
To create a denial of service on a DNS server a script such as dnsflood.pl3 can be used simultaneously from multiple machines to starve the server of resources. 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.
In the below example dnsflood is run from one machine and the DNS server queried from another machine.
First the attacker runs the script: [root@fanta dns]# perl dnsflood.pl 22.214.171.124 attacked: 126.96.36.199… Notice from the below tcpdump sniffed output from the attacking machine the different types of DNS packets sent, each with a different spoofed source port
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.
The attacker then stops the attack and then once again from another machine queries the target name server after once again clearing the cache. D:\>ipconfig /flushdns
Windows IP Configuration
Successfully flushed the DNS Resolver Cache.
Notice the distinction between the queries conducted during the attack and after the attack was stopped. It seems evident the attack had a performance impact on the server. If this attack was multiplied from a number of machines then the impact would be even greater.
DNS Man in the Middle Attacks – DNS Hijacking
If an attacker is able to insert himself between the client and the DNS server he may be able to intercept replies to client name resolution queries and send false information mapping addresses to incorrect addresses. This type of attack is very much a race condition, in that the attacker needs to get his reply back to the client before the legitimate server does. The odds may be stacked in the favour of the client as a number of recursive queries may need to be made and the attacker may be able to slow the client’s primary DNS server down by using a denial of service attack.
This attack is illustrated in the below diagram:
The diagram above shows:
1. The attacker places himself between the client and name server
2. The client makes a DNS request for resolution of www.microsoft.com
3. This request is intercepted by the attacker who replies with false information
4. The DNS server replies with the correct information
Once again this is a race condition, the winner will be the first packet which hits the client.
To execute this attack a tool called DNS Hijacker4 is used and run on the attackers man in the middle machine. DNS Hijacker uses a fabrication table to store the falsified information to be returned. The below table shows the hostname ms2.sa.com configured to reply with a address of 10.10.10.10. The actual address for ms2.sa.com as configured by the DNS administrator is 188.8.131.52.
[root@fanta dnshijacker]# more ftable 10.10.10.10 ms2.sa.com
Next the attacker starts the DNS Hijacker program as shown below:
Notice the first request asking for resolution of ms2.sa.com and the spoofed answer returned by the attacker of 10.10.10.10. Below from the client side this information is accepted:
The incorrect information is returned to the client and accepted as valid. DNS hijacker has a –d option with which all DNS requests intercepted will be returned false information.
Document References and Credits
 – http://www.rnp.br/cais/alertas/2002/cais-ALR19112002a.html
 – http://www.securityfocus.com/guest/17905
The below tools were used in this document and can be downloaded from the Security Associates Institute’s website. These are Open Source tools not written by the Institute and are provided for download “as is” and full respect provided to the authors of these tools. Read the README file of each distribution or the source code for authors information.
Dns1.pl1 – http://www.sainstitute.org/articles/tools/Dns1.pl
Dnsflood.pl3 – http://www.sainstitute.org/articles/tools/Dnsflood.pl
DNS Hijacker4 – http://www.sainstitute.org/articles/tools/DNS Hijacker