The Domain Name System (DNS) is a naming system for devices and services that are connected to an internal or external network. The DNS system can easily equate to a phone book which provides translation services from hostnames to IP addresses. To resolve the domain name google.com, DNS is used to map google.com into an understandable IP (Internet Protocol) address for your device, 126.96.36.199. The device is able to connect to the IP address at which google.com is located as a result of the DNS service correctly providing the information to where this hostname is pointing. DNS is used almost everywhere because of the ease of use that it provides to the average user. A user would not want to remember a bunch of IP addresses to access the information desired. An easy to remember domain name is much more convenient for a user to remember in comparison with a string of numbers. DNS names take the format of a name followed by a period and followed by a TLD (Top-Level Domain). In the previously used example of google.com, ‘google’ would be the name followed by TLD of ‘com’ separated by the period. Recently there has been a large number of additional TLDs that have become available for public use such as .club or .me which give additional personality for users, allowing for domains such as google.me to be possible.
When a client wants to resolve a particular address (we will continue with the example of google.com), it petitions the DNS server with a query to receive the appropriate information. The handling of the query is done by a DNS resolver that is client-side and is responsible for initiating the recursive or non-recursive query to the DNS server to resolve the domain name into an IP address. A non-recursive query provides a DNS record for a domain which it has ownership over or provides a partial result. A recursive query may query other servers in a recursive manner as needed until it has all of the information required. Most DNS servers will issue a recursive query to find out the information requested about the particular domain, asking other DNS servers in the form of a DNS forwarder for the queried information (Hanley, 2000).
DNS has additional uses other than just providing translation services for domain names into IP addresses for devices. The DNS server’s files can be queried to find other relevant information about the records of a particular domain. Continuing with the example of google.com, mailing systems utilize MX (mail exchange) records to correctly forward email for a particular email address on that domain. DNS servers are also commonly utilized for the creation and distribution of blacklists for spam emails and other services such that a easy to remember domain could be queried to find out if a particular host is a member of the blacklist. If a particular host is indeed a member of the blacklist then often the host is denied connection. Another example of how DNS has a variety of uses is utilization of DDNS (Dynamic DNS) to update DNS entries in the case of a dynamic IP address which frequently changes. DDNS is useful if a particular host device needs to be accessed at a consistent location, but the IP address that is tied to it is constantly changing. With DDNS the changing of the IP address can be compensated for as a result of the DNS system being updated with the new information as it changes. It is possible to poison or spoof the DNS records that are returned to a host, diverting traffic away from its intended target and often to an attacker’s device. For DNS to be functional, there must be a DNS server running to handle the protocol.
The BIND (Berkeley Internet Name Domain) package was created at the University of California at Berkeley (BIND, 2014). BIND is an open source software that implements DNS protocols. BIND is by far the most widely used DNS software on the Internet and is currently in use by everyone ranging from government agencies to hobbyists. The BIND package is so popular because it allows authoritative functionality, recursive functionality, access control, caching features, IPv6 support, is open sourced, wildcard support and split horizon support (BIND, 2014). BIND can be used on both private and public networks alike without considerable changes to the configuration process, making it very simple to setup and get started using. BIND has taken some precautions against DNS spoofing attacks on their servers. Implementation has been made on BIND servers running version 9.5 and above to ignore DNS records that are passed back to the server without a relevant query for them (Graves, 2014). Other DNS servers also are available that are not as prevalent such as Dnsmasq (a more lightweight alternative to BIND) or djbdns. DNS servers are commonly susceptible to DNS spoofing, creating issues in trust between the client and the server.
DNS Spoofing differs from ARP Spoofing in that it replies to DNS requests with falsified information as opposed to sending false ARP requests to impersonate a router. As noted in Man in the Middle (MITM) ARP Cache Poisoning Explained article, ARP packets are considered to reside within the second layer of the OSI model (Briscoe, 2000). The second layer of the OSI model represents the data link layer. ARP packets are never routed meaning it is only meaningful in network situations where the devices involved in the ARP communication are locally visible to each other. The third layer of the OSI model represents the network layer; DNS packets are considered to be part of layer 3 because they are routable. The DNS packets are able to be spoofed from any location, not just locally visible locations such as the case of ARP packets. The possible remote nature of DNS spoofing makes it much more of a threat in comparison with ARP spoofing which must be done internally.
DNS spoofing is carried out by replying back to a DNS server with a DNS packet with falsified information. The process allows an attacker to make changes to a DNS entry so that DNS entry is directed to an IP of the attacker’s choosing. Originally, BIND was configured such that DNS packets produced were incremented by one for each query that was produced. The easy to predict the nature of the query ID allows an attacker to pose as a legitimate response to that query before the actual response comes back, potentially allowing the storage of incorrect information in DNS records. The other piece of information that would generally be required is the port at which the DNS transactions were taking place. The port that is used by BIND and most other DNS software is generally consistent and acting on a particular port and the port is reused. As a result of the almost universal use of BIND, figuring out that the port number is not much of a hurdle for an attacker to figure out. To find the source port, an attacker would only need to issue a lookup request through the DNS server. Upon receiving the valid information from the server, the port at which the BIND server communicated on can be identified easily as the source port. The source port for that transaction that was just carried out is not randomized by BIND and as a result, it does not do itself any service in thwarting attacks in this manner. An attacker generally would bombard the DNS server with a large amount of DNS packets with a large TTL (Time to Live). The TTL represents the amount of time that the data that is received in the packet is thought to last before needing to be refreshed. Generally, TTL is used to improve on system performance by caching certain information such that the same lookups do not have to be done over and over. After a query is made by the DNS server and a record is received back, the TTL specifies the amount of time that that record will remain valid before having to be rechecked. When a request is made for google.com for example, if the DNS server has a cached record for that DNS, it will provide the client that information as opposed to starting a new query to translate the domain every time. The ability to store this information greatly increases the performance of the server and allows lesser loads on nameservers. If an organization has multiple users and user A makes a query for google.com and that record has not previously been stored in the cache or the TTL of the previous record has expired, that record will be queried for. When user B attempts to reach the same domain name, the cached information will be supplied as opposed to starting a new query.
Generally, when making modifications to DNS records, an administrator will change the TTL on certain information such as MX (Mail Exchange) records to lower values such that when the change is applied it is more quickly refreshed and the correct information is applied. At the time of introduction of BIND and other DNS software, the common value for a TTL of a DNS packet was about 24 hours. The common value for a TTL for such packets has gone down as a result of realization of possibility of malicious activities as a result of the high TTL time from DNS spoofing and cache poisoning. A lowered value of TTL does not solve the issue and DNS spoofing and cache poisoning attacks are still possible. If a DNS server has a poisoned cache, an attacker would be able to control the translation processes from hostname to IP address and effectively control the traffic of those devices, directing them to wherever they please, regardless of the validity of the record. The vulnerabilities that are seen in the DNS system can be directly attributed to the lack of any sort of authentication mechanisms in the DNS system.
A popular method of an attack on DNS servers is often referred to as the birthday attack. The birthday attack is based on the birthday problem and subsequent birthday paradox, first discussed by W.W. Ball in relation to mathematical probability and statistics (Ball, 1914). The birthday problem deals with the problem of finding the percentage probability that a pair of people in a set of randomly chosen people will have the same birthday (Stewart, 2003). There are 366 possible birthdays for an individual, counting the possibility of a leap year ; as a result the probability of a pair of people will share the same birthday would be 100% when the number of people included in the study is greater than 366. The birthday paradox with this problem is that in order to reach a 99.9% probability rate that there would indeed be a pair of individuals in the set with the same birthday, only 70 people will need to be included; even more interesting is that the probability of a pair of people sharing the same birthday is just over 50% when only 23 people are included in the study.
A method of DNS poisoning would be to bombard a DNS server with responses that are crafted by the attacker. Protocols in the DNS system are already in place that require the responses to include the ID of the request of which it is a response as well as the port on which the transaction took place on. As previously discussed, the issue of the attacker to figure out the communication port is trivial and often a non-issue for an intent attacker. A birthday attack is carried out by an attacker by causing the DNS resolver to “issue multiple queries for the same domain in order to increase the probability of a match” with one of the fake responses that have been generated by the attacker (Herzberg, 2012). In this manner, a birthday attack is a very efficient brute force type of attack that can be easily applied with minimal resources. In the case of a birthday attack on a DNS server, the same methodology can be applied as seen in the birthday paradox, but instead of the limit of possible birthdays being 366, the possible limit of transaction IDs that are produced by the DNS server is 65535 (Stewart, 2003).
In application, the birthday attack is a very powerful tool in spoofing DNS records as it is able to reach a 50% probability rate of being successful in only 300 attempts. Each attempt in our application would be a response to the DNS server with forged information, attempting to get lucky and forge the correct transaction ID such that the DNS server accepts it. A 99.9% success rate is found in the 600-700 packet range, meaning the time required for a successful attack is very minimal using this method (Herzberg, 2012).
The time at which the real nameserver replies back with the legitimate information is the only hurdle that is left for an attacker utilizing the birthday attack to overcome. The attacker must ensure that the correct packet that is part of the batch of packets that are being bombarded to the DNS server reaches the server before the legitimate packet from the real nameserver is received. Because of the speed at which the birthday attack is able to narrow down the possibilities, the amount of time required for this process is minimal, but an attacker could utilize methods such as flooding to slow down the server to ensure that the attacking packets get there first (Stewart, 2003). Once the attacker beats the real nameserver in the reply, the attack is complete for the duration of the TTL that was specified by the attacker when creating the falsified response that was sent to the target DNS server.
One of the most important parts about the BIND system is that the transaction ID needs to be matched for the response to be accepted. A tool has been created that does analysis of the random number generation processes. The tool was applied to BIND 8 and it was found that the random number generation process was not an ideal random number generator, meaning some numbers had a far higher likelihood of being selected in comparison with others (Stewart, 2003). An algorithm was created, proving that, when provided with the previous three transaction IDs, it would be possible for an attacker to guess with a probability of 100% the next transaction ID that is to be generated based on the random number generation process within BIND 8. Changes as a result of this issue with the random number generation within BIND 8 were made in the subsequent release of BIND, slightly alleviating this issue. In BIND 9, the random number sequence that is generated is a little more secure. Instead of being able to guess the next transaction ID with 100% certainty with only three previous transaction IDs, BIND 9 solves some of the problems and lowers the certainty to predicting a random number to be generated to 20% while having access to 5,000 previous transaction IDs (Klein, 2007). While this random number generation process in BIND 9 is still not good enough as it is still somewhat predictable (and as a result, susceptible) as to the random numbers that are being generated, the percentage likelihood is greatly reduced in comparison with previous versions (Stewart, 2003). Djbdns’s random number generation is slightly worse than that of BIND 9, allowing a predictability of 30% on the same sample size, but because the source ports are also randomized every time in addition to the transaction ID, it would take billions of combinations to correctly match a query (Stewart, 2003). Microsoft DNS server is another commonly used DNS software that is used in enterprise environments that is equally susceptible to DNS spoofing as BIND as a result of the fixed source port. Microsoft DNS server keeps the source port for queries fixed and as a result the attacker does not need to make attempts to guess the source port. The advantages shown through djbdns and the randomization of the source port can be seen in the ability to effectively provide a large amount of protection just from the extra randomization.
Once an attacker has become successful with a DNS spoofing attack, the attacker has full control over web traffic and is able to launch man in the middle (MITM) type attacks. An attacker could redirect the users of the network to phishing sites that trick users into entering sensitive information, thinking they are visiting a legitimate site, allowing the attackers access to their credentials.
More and more people are switching to use VoIP (Voice over Internet Protocol) services for their home and cellular phone needs. DNS spoofing can be used by an attacker to exploit the VoIP protocols and cause havoc on a user’s VoIP service. A case study investigated the possibility of attacking Vonage service VoIP phones utilizing DNS spoofing, showing the feasibility of such an attack is much more effective than previously thought (Zhang et al., 2009). An attacker, possibly through some of the methods previously discussed, could redirect traffic through their own SIP server by sending spoofed DNS responses back to the phone. All of the calls that are made through the Vonage phone would then be passed through the attacker, at which point the attacker could “wiretap and hijack any calls to or from the targeted phone” (Zhang et al., 2009). The implications of properly securing the DNS server and ensuring the DNS server does not have a poisoned cache has severe implications. As technology grows, DNS will continue to be depended on by various devices and services to properly route information. Ensuring DNS servers are properly configured and secured such that the possibility of attack is minimized should be at the forefront of efforts as often it is overlooked and utilized by attackers as an easy means of access to a network.
Ensuring that DNS software is fully updated to the most recent versions will allow an organization to assist to ensure that issues that are found are patched on the machine running the DNS server. Although the process of patching software is sometimes tedious, the benefits of updating to the most recent version of BIND or other software are far greater. Often it is not possible to upgrade the DNS software, for example, in the case of government regulations where a particular set of software is supposed to be running on the server and upgrading or manipulating that is not allowed. Many servers still run older versions of BIND that are susceptible to the types of DNS attacks that have been talked about previously. Some of the exploits have since been patched or severely reduced in more recent versions, lingering on outdated software versions opens up the network environment to possible exploits and attackers. In more recent versions of BIND, a credibility indicator has been included to identify the credibility of the source of the data. When BIND detects information from a higher credible source differing from what it has already stored, it will refresh the information with the information gained from the highest credible source that is possible (Vixie, 1995). While still possible to launch a DNS attack on an updated BIND server, the amount of exploits is greatly reduced.
DNS rebinding attacks deal with browsers and plugins that allow an attack server to manipulate the client machine into believing that they are communicating from within the same “origin,” allowing easy access to personal resources of the client machine. Preventative measures have been put in place to assist in stopping this sort of activity, but the measures in place are easily manipulated and bypassed. Most modern browsers have implementation of something called a same-origin policy which attempts to differentiate between different sites, protecting each from one another (Jackson et al., 2009).
A would-be attacker would find benefit from the act of launching a DNS rebinding attack upon an unsuspecting client computer for a multitude of reasons ranging from commission of click fraud to hijacking an IP address for other malicious deeds such as circumventing a firewall to gain access to sensitive information. Utilizing a DNS rebinding attack is much more cost-effective than other means of IP hijacking. An attacker would need to spend pennies on the dollar to gain access to tens of thousands of IP addresses. The attacker would be utilizing their own server (hypothetically) to launch these attacks and would be able to “legitimately sign all DNS records provided by his or her DNS server in the attacks” making it easier and in some ways a more legal route of committing these attacks (Jackson et al., 2009).
After committing the attack and gaining access to a large number IP addresses for their own use, click fraud is a common use, that can generate a good amount of income to the attacker through fraudulently using the hijacked IP addresses to create impressions on their own advertisements and also create a believable click through rate to the advertising server (Google AdWords for example). Often mail servers are hit with large amounts of spam and eventually blacklist those IP addresses responsible. Through utilization of these tens of thousands of new IP addresses, spam can be sent once again and the responsible party would not appear to be the IP address of the responsible party. Lastly, access to IP based authentication services could be exploited such that these new IP addresses that were hijacked could serve as an authentication method in itself to certain services (Jackson et al., 2009).
In a proof of concept demonstration, Stanford spent 50 cents per 1000 impressions, costing them about $10 per day for a duration of three days. The proof of concept demonstration resulted with about 45,000 unique IP addresses for rebinding attempts; 60% of the attacks were successful (Jackson et al., 2009). Subversion of DNS pinning in this regard is one of the most cost-effective methods to exploit these IP addresses and as a result is something that should be taken seriously from a security standpoint.
Originally, the concept of DNS pinning was introduced to attempt to combat possible loopholes in the system to prevent DNS rebinding attacks. DNS pinning caches the resolved IP address of the hostname attempting the connection into its own database, disregarding any TTL specification (Jackson et al., 2009). The concept of DNS pinning began to show its flaws with the introduction of various extensions and plugins for browsers. These various third party plugins, such as Adobe Flash, Microsoft Silverlight or Java to name a few examples, hold their own pinning databases, which creates new vulnerabilities in the DNS pinning system. Firewalls can be circumvented in this manner through DNS rebinding such that the firewall would allow access and not block the threat presented properly or even at all. It is now possible to introduce a situation in which the browser pins one resolved IP address into its database and a plugin for that browser pins a differing IP address into its own database, allowing for an attacker to “read and write data directly on sockets to a host” as a result of there being multiple distinct databases instead of just one (Jackson et al., 2009).
Some plugins such as Adobe Flash Player, attempt to protect against DNS rebinding by requiring a response back from the server with a XML policy ensuring that the access is ok. The attacker can circumvent this easily by responding back to the client with their own XML allowing access from all domains and ports, giving the impression back to the client that all is well and this is not an issue. Other plugins restrict certain types of access but are circumventable through multi-pin vulnerabilities, allowing direct socket access to the attacker (Jackson et al., 2009).
DNS spoofing and other exploits on the DNS system are commonly used by attackers to gain access to sensitive information. DNS spoofing should be considered a real threat in a network environment and precautions should be taken to best mitigate possible exploits relating to DNS. Significant strides have been made recently in properly securing popular DNS software and other loopholes that are commonly used by attackers. Secure systems should not rely on DNS. Typically on highly secured systems, access to the internet is limited to begin with reducing the need to use DNS altogether on those machines. By not using DNS on secure systems you in effect reduce the possible exploitation of the DNS protocol (Sanders, 2010). Constant monitoring of network activity should be a standard in assisting to ensure that even a properly secured network is not falling prey to a DNS based attack.
Ball, W. W. R. (1914). Mathematical recreations and essays. MacMillan.
BIND. (2014, January 1). Internet Systems Consortium. Retrieved May 8, 2014, from https://www.isc.org/downloads/bind/
Briscoe, N. (2000). Understanding the OSI 7-layer model. PC Network Advisor, 120(2).
Graves, S. (2014, May 8). BIND 9 Security Vulnerability Matrix. . Retrieved May 8, 2014, from https://kb.isc.org/article/AA-00913/0/BIND-9-Security-Vulnerability-Matrix.html
Hanley, S. (2000). DNS overview with a discussion of DNS spoofing.
Herzberg, A., & Shulman, H. (2012). Security of patched DNS. In Computer Security–ESORICS 2012 (pp. 271-288). Springer Berlin Heidelberg.
Jackson, C., Barth, A., Bortz, A., Shao, W., & Boneh, D. (2009). Protecting browsers from DNS rebinding attacks. ACM Transactions on the Web (TWEB),3(1), 2.
Klein, A. (2007). BIND 8 DNS cache poisoning.
Sanders, C. (2010, August 7). Understanding Man-In-The-Middle Attacks – Part2: DNS Spoofing. WindowSecurity.com. Retrieved May 8, 2014, from http://www.windowsecurity.com/articles-tutorials/authentication_and_encryption/Understanding-Man-in-the-Middle-Attacks-ARP-Part2.html
Stewart, J. (2003). DNS cache poisoning–the next generation. 2007-08-25). http://www. secureworks. com/research/articles/dns-cache-poisoning.
Vixie, P. (1995, June). DNS and BIND security issues. In Proceedings of the 5th USENIX UNIX Security Symposium, USENIX Association, Berkeley, CA.
Zhang, R., Wang, X., Farley, R., Yang, X., & Jiang, X. (2009, March). On the feasibility of launching the man-in-the-middle attacks on VoIP from remote attackers. In Proceedings of the 4th International Symposium on Information, Computer, and Communications Security (pp. 61-69). ACM.