Cyber Attacks Explained - DNS Invasion - Cyber Security Blogs - Valency Networks - Best VAPT Penetration Testing Cyber Security Company - Pune Mumbai Hyderabad Delhi Bangalore Ahmedabad Kolkata India Dubai Bahrain Qatar Kuwait Singapore Australia USA UK Germany Croatia Botswana Mauritius

Author
Recent Posts

Latest posts by Prashant (see all)

Is XSS Vulnerability Possible on Mobile Apps - 17/04/2024
Difference Between Privilege Escalation Attack and IDOR Attack - 04/03/2024
Exploring TISAX Version 6 – A Comprehensive Guide - 10/01/2024

Title: Cyber Attacks Explained: DNS Invasion
Scope of article
We always read in the news about some website defaced and its pages changed to reflect some malicious content. It makes us wonder how exactly hackers can do it, and how do we prevent our infrastructure. Today we are going to learn about DNS (domain name system) and the ways hackers use to invade it. DNS invasion is a technically advanced technique and hence proved to be a harmful attack on a network or web infrastructure. By means of presenting this article, network administrators are encouraged to learn about it and devise ways to secure the network infrastructure under their management.
How DNS works?
As we all know, the DNS system was put in place because it is impossible for human being to remember the number coded IP addresses, whereas it is easy to remember user friendly character based names. DNS system was created in the era when internet was a friendly place. As for the underlying technology, domain name system uses UDP (User Datagram Protocol) to fetch IP address for a give domain name. Fig 1 shows how a name resolution fundamentally works. When an application such as a browser wants to connect to a destination service, it queries the DNS server asking for the IP address. This query is sent over UDP port 53 as a single request, and receives a single packet reply from the server. Please note that since the UDP data space is limited to 512 bytes, the protocol stack automatically uses TCP protocol for query and reply. When the client machine receives a reply, it updates its own local cache with the received entry which is useful for subsequent queries to the same domain, thus speeding up the name resolution process. Entries in the local cache carry their own TTL (Time to Live), after which those are purged automatically.
DNS system uses various record types such as A, CNAME, SOA, MX etc. While the explanation for these records is beyond the scope of this article, it is important for network administrators to know the usage of each record and they should think from the security standpoint while implementing those records. Before we learn about DNS based attacks, it is essential to know about two types of DNS queries, namely the iterative query and recursive query.
Iterative DNS Query: When a client queries DNS server asking if it has the answer for given domain name, the DNS server may or may not have the answer ready. If the DNS server doesn’t have an answer, instead of shutting the request down, it sends the name of an upstream DNS server who might have the answer. This is usually called as a DNS referral. The client machine sends the query to this referral server, and again if the referral server doesn’t have an answer it provides name of another upstream server. This process continues till the client either gets an IP address or gets a query failed error message.
Recursive DNS Query: In this type, the client who is querying a DNS server must perform aggressive actions till it gets an answer. Instead of getting a referral server name, the client traverses through the recursive chain of available DNS servers till it either gets an IP address or an error message stating that the query failed.
Iterative queries are usually made by the DNS servers, whereas the recursive queries are made by the client host, which helps them reduce the burden of performing referral search process. From the security perspective, it is important to know basics of DNS such as, there can be multiple DNS servers in an organization replicating their zone records to each other in order to maintain the name resolution consistency. DNS data can be updated dynamically without needing any service to be restarted, and when a change is made on the master server, it triggers the replication to the replicating partner servers automatically. The actual time required for replication is defined by the TTL value associated with each record. In case of geographically dispersed DNS servers, this time can be as high as a day. It is worth mentioning here, that all the servers in the chain maintain their own cache entries to speed up the replication process.
DNS Security Attacks
It is observed that system administrators spend a lot of time in designing security around the applications, servers and other infrastructure components but unfortunately tend to forget hardening DNS servers. Please refer to Fig 2 which shows possible hack points where a domain name system can be vulnerable and hence prone to attacks. By its design, DNS heavily relies on UDP protocol, does not contain security by itself and does not contain foolproof built-in authentication which makes it more susceptible to hacking than other network based services. Let’s take a look at few very common DNS attacks and understand how it works.
DNS cache poisoning – This is a very commonly used attack in which the name resolution can be tweaked in two ways. In one method, hacker installs a root kit or a virus which is intended to take control of the local dns cache of the client machine. Once it is achieved, the entries in the local DNS database are altered to point to a different IP address. For example, if a browser is trying to access a website such as www.cnn.com, instead of resolving to CNN’s IP address, the hacked machine resolves the name to the IP set by the hackers’ script. Usually this machine is hackers’ own web farm which hosts viruses or shows some derogatory information. In a different and a more dangerous approach, the hacker makes his way to a DNS server itself and alters local cache on that machine. Thus all the servers using that DNS server for name resolution end up landing on a wrong IP address, causing a corporate-wide system failure and information loss or stealing.
In a rare case, hackers can access a root DNS server which holds the base entries that form the root domain such as .com, .net or any country specific name system. Hackers then modify entries on that server which triggers an automatic replication as we learnt earlier, and thus can cause serious global outages for multiple businesses and website. Though such situations are rare, those have happened and that too very recently in case of a famous social community chatting website.
DNS Hijacking – This attack is also commonly used to bend the DNS system. In this method, the entries of name and IP addresses cache on a client machine are not altered, but instead the client’s DNS servers are changed to point to hacker’s own DNS server. Usually the purpose of this is not to steal data but to gather statistical data from the client computer. When a DNS server is changed, all name resolution requests go to hacker, and are actually resolved successfully to the correct addresses. At the same time however, the hacker is able to gain knowledge in terms of typical sites being visited by the client machine. This information can further be used by online advertisers to target client computer with their web visit specific ads. Some ill-behaved e-thieves also redirect users to their own websites, or search engines, either to gain money from advertisements or simply to steal data and use it for social engineering. While it is inappropriate to use this feature for any personal gain, it is being used by many big and famous websites and internet service providers to collect user’s browsing experiences and statistics.
DNS spoofing – This is simply a man in the middle type of attack. In this type, the hacker gains access to the same network as the DNS server is on, and performs ARP cache poisoning and spoofing on that network. Once a MAC level control is achieved, hacker then fetches IP address of DNS server and starts sniffing and spoofing all requests which are actually meant for the real DNS server. This results in hacker’s machine resolving all DNS queries by completely bypassing the real DNS server. This has serious consequences, because all the machines on that network can be completely unaware of this, and end up sending DNS traffic to hacker’s machine.
There is an alternate method called as DNS ID spoofing. Each DNS request and response carries a unique identifier, in order to differentiate between various simultaneously generated requests which are bombarded on to a DNS server. This unique number is usually a function of MAC address and the date/time stamp and is created by the protocol stack software automatically. A hacker uses a sniffer to look at one or more DNS requests and responds with their respective unique number, but with a false IP address. This ultimately results into the local cache of the client machine being updated, pointing to this falsely fabricated IP address. A further damage can be caused by hosting a virus on the machine at that IP address.
DNS Rebinding – Also called as DNS pinning, this is bit of an advanced type of attack. In this method, the hacker first registers his own domain name and configures it on the DNS server he owns. As we learnt earlier, the records carry their own time to live. In this case hacker intentionally keeps TTL value very small, thus preventing entries from being cached. The hacker then waits till someone browses to this newly formed domain. Once that happens, a malicious script is sent to browser to either install a virus, or simply to point browser to hacker’s own website. Lowered TTL thus plays a funny role in this case, because instead of being a feature it acts as vulnerability.
DNS denial of service – As we learnt in the very first article of this series, a simple bombarding of name resolution queries on UDP port 53, or TCP port 53 can cause a denial of service attack. Another method is to perform a ping of death, or a TCP SYN flood attack. The idea behind this type is to overwhelm the server resources such as CPU and memory to such an extent that it causes server to completely stop from responding to queries. Though a DNS server is protected by firewalls, if enough care is not taken to block DNS UDP ports from non-trusted networks, it exposes the name resolution system to this attack.
DNS Amplification – By amplification in case of a DNS server, it means to provide it with a task heavier than it is intended to handle. There are multiple ways to put server under stress, and make it non-functional eventually. In one method of amplification, a Trojan is written to poison and populate local cache of multiple client hosts. This forces all infected clients to send their name requests to a particular name server which has been made a target by the hackers. Each server is capable of responding only to a certain number of queries based on its CPU speed and configuration, and eventually starts queuing up the requests. As more and more clients get infected, the name server receives increasing number of queries and ultimately it gives up. In another type, a hacker poisons cache of DNS server itself and instead of changing the associated IP address of an A or CNAME record, a change is made to the domain name. To make it worse, the domain name is made to contain few hundreds or thousands of characters. This starts replication process and hence the download of multiple kilobytes of data from main name server to its replicating partners and eventually to the client hosts. Upon expiration of the TTL, the replication process initiates again and results in the breakdown of one or more DNS servers in the chain. This trick actually simulates a distributed denial of service attack, and hence it is very dangerous to control.
DNS URL Phishing – This method is bit old but still in use, as found in multiple cases. The hacker simply registers a website url, which looks very similar to that of a famous website. This website is usually of a bank or financial institution where users login to perform money transactions. Hacker then creates a login page looking exactly same as that of the bank to be targeted and sends phishing email to millions of addresses, where the email contains url pointing to this hoax website. Unaware users click the link thinking that it is legitimate and login on the page, thus revealing their user id and password to the hacker. Most of the banking firms either have faced this attack in the past, or still continue to face it.
Protecting FOSS systems
In the FOSS world, the DNS service is a famous implementation across the globe, simply because it proves to be the fastest available name resolution mechanism. A widely used and famous example is a Linux based Bind service. However since most of the DNS attacks exploit the basic design lacunas, it becomes a tougher task to protect FOSS based name resolution systems.
The very first step to protect a FOSS DNS server is to lock it down at network level. Besides the server management ports, only the DNS query ports should be allowed and the rest must be blocked on the firewall as well as on the OS based port filtering. The second important step is to not install any other software on a DNS server, other than the name server service itself. This must be followed especially in the case of an externally facing corporate root name server which holds all internal name spaces, and resolves external name queries for the local area network. It is often found that vulnerability in another program on name server leaves a backdoor open, resulting into the intrusion of name service. While most of the critical infrastructures implement a firewall, a UTM device and powerful antivirus or anti-trojan software, it becomes imperative to have an intrusion detection system (IDS) in place. IDS is capable of filtering out sneaky layer2 and layer3 attacks such as ARP spoofing, IP spoofing, packet sniffing etc.
Besides above crucial steps, there are few advanced methods to be followed too. As we learnt earlier, each query carries its own unique identifier and is marked in the UDP packet. Unfortunately due to the design of DNS stacks based on RFC standards, these identifiers are easily predictable and hence randomizing those can be a good idea to prevent spoofing attacks. Similarly, the UDP port on which the name server responds back with the answer is predictable too and can be randomized. There are open source tools available on internet just for this purpose, however please note that it adds bit of a delay into the query resolution, resulting into network latency. A fairly recent and popular protection technique is DNSSEC (DNS Security Extensions). It protects clients and systems from cache poisoning attacks by digitally signing the records using public key encryption. While working in a fashion similar to SSL protocol, the querying host and answering host need to establish a digital trust between each other and once it is achieved, a name resolution takes place. Once the process is completed, the session is torn out thus protecting the security at either ends. DNSSEC is being implemented by most of the internet service providers in the world.
Summary
DNS invasion is a common phenomenon in IT security world. It involves exploiting DNS design loopholes to gain access to the IT infrastructure or to lure the client computers to a phishing farm. FOSS is also susceptible to such attacks and hence the network administrators must understand techniques to protect their infrastructure from information loss or theft.
About the author
The author has over 18 years of experience in the field of IT hardware, networking, web technologies and IT security. Prashant is MCSE, MCDBA certified and also F5 load balancer expert. In the IT security world he is an ethical hacker and net-forensic specialist.
Prashant runs his own firm named Valency Networks in India (www.valencynetworks.com) providing consultancy in IT security design, security audit, infrastructure technology and business process management. He can be reached at prashant@valencynetworks.com.