Security Vulnerability In The Dns Explained in detail

[longtimeago 0]

We all of us know well about the Domain Naming System. The Domain Naming System is the axis around which the whole internet revolves in todays world. Internet without the Domain Naming System is practically no possible in todays cyber era. To brief it up Domain Naming System is one in which the Domain Names are mapped to its corresponding IP address. So if you think that without the Domain Naming System will the internet work ? Yeah the internet as a whole will work perfectly without the domain naming system but on the other hand human beings will find it difficult to work on the internet if that system was not present. If our computer fore fathers had not introduced the Naming system then today every one would be forced to remember all the IP address of various websites inorder to access them. But is that really difficult ? I would personally say its possible though it is difficult. Dont we remember few of the phone numbers which we very often call ? Likewise we will be remembering the IP address of the websites if there was no Domain Naming System. But to make it in a crisp sentence, a world without the Domain Naming system is possible, but very difficult. So here I draw the attention to the importance of the domain naming system in todays cyber era. When such is the case just think about what if there is a very serious vulnerability in that system. If that Domain Naming System is vulnerable then it can cause some damages which no one can never ever imagine of .Let me quote an simple example about the same. Think that you are connected to a particular Domain Name server which provides you information about the host to IP address mapping that is the Domain Naming service . When you try to query for https://www.paypal.com/de/webapps/mpp/home,'>https://www.paypal.com/de/webapps/mpp/home, the responsibility of that server is to provide the IP address of paypal.com so that you may get connected to www,paypal.com. On the other hand think what if that Domain Namer server replies with a IP address of a web server in which a site is hosted which looks like paypal.com but actually it is not paypal.com. In such a case the user can be easily misled. This kind of attack which is imposed on the Domain Naming System is termed as Pharming. Here in pharming the DNS is poisoned with a fake IP address. The pathetic thing in this kind of attack is the user will not be able to recognize that the website is a fake one. This may look like phishing but this is not phishing. In phishing very often the user is tricked with some fake mails which claims to be from a particular company and the user is made to click a Link or something similar to that. In that kind of attack if the user is cautious enough to look at the URL bar of the web page he may get himself in a safe boat. Though phishing is a serious threat, it can be counter attacked to a certain extent with the help of users alert ness. On the other hand if you check out pharming , here where in as explained above the DNS is poisoned. So here in this case the user will open a normal browser window and will be typing the exact web page name. for example https://www.paypal.com/de/webapps/mpp/home.'>https://www.paypal.com/de/webapps/mpp/home. Unlike phishing , here in pharming the URL points towards the website which user intends to visit, by this I mean that the visual appearance in the URL bar is displayed as the genuine one. But on the other hand due to that DNS poisoning the user has been linked to some other server. Once the user sees the webpage loaded all he does is enter the sensitive information thinking that it is the orginal webage. In such case even if the user is alert enough to check out the URL bar he cannot escape. So this is all about pharming. So now let me take a look where in is that DNS poisoning really feasible in todays cyber era. Many people have been doing a lots of research in this topic to find out the available security exploits in the Domain Naming Server. Now I came across a major security vulnurablity where in the DNS is poisoned very easily and pharming takes place therby many people loose their sensitive data like passwords and other credit card information. So just think, in todays world if such a major security threat would exist will it be possible for organizations to run their DNS server successfully without getting poisoned. Let me put forth a simple DNS security vulnerability which many researchers had thought about and recently it was proved that such a vulnerability really do exist in todays cyber era. So to start with the vulnerability in the DNS let me tell that the below vulnerability was not invented by me. It was actually discovered in the summer of 2008 by Dan Kaminsky who worked with CISCO then. I am not very sure where he is now. Thanks to Dan Kaminsky. And also please note that the below thing which is explained is just for educational purpose and to bring out the security exploits available in todays cyber era. This shall not be used for hacking or breaching into any network. I do not hold any responsibility for the same. Now moving on, let me brush up quickly how this DNS works, How the Domain names are resolved to their IP addresses. First the user enters the website name in the URL bar of the browser, let me say http://forums.xisto.com/no_longer_exists/'>http://forums.xisto.com/no_longer_exists/ e the user makes a request for Xisto.com, and this request si routed to the nameserver provided by the user's ISP. It requests the information which represents an IP address. The ISP's nameserver knows that it's not authoritative for Xisto.com, so it can't look it up in its local zone database. This local Data base is maintained by the ISP for its customers where from the customers (users) can retrieve the IP address quickly. It also doesn't find the name it its cache of recently-seen data, so it knows it has to go out to the internet to find the IP address for Xisto.com and return to the user so that he may get connected to that server on which Xisto.com is hosted .There are 13 root servers for the Domain naming system which are preconfigured in the Recurssive server. And thanks to the Root servers for their IP address dont change very often. Here the query is sent to a particular root server, query in the sense the record is sent. The root server handles it. The thing which has to be noted here is that the root server doesent know any thing about http://forums.xisto.com/.'>http://forums.xisto.com/. It gives the way of the Global Top Level Domain (GTLD) servers responsible for the .com domains. Its some thing like the root servers replying to the request Hey I dont know where it is but this guy knows it and it points to the authoritative server.The root server actually gives a list of authoritative server and the name server chooses one in random. Now the Name server asks the authoritative server the same question like I was told to ask you where is http://forums.xisto.com/ .Like the root server this also gives us a reply which helps us to get closer to the target of achieving the IP address of Xisto.com. and so one it goes and in the third query following a chain of referrals it gets the name server of Xisto.com which is om1.computinghost.com om2.computinghost.com, om3.computinghost.com, om4.computinghost.com. Now after picking one server from this list. The buck is not transferred now else where . These server has the exact address, that is the information which we are looking for that is the IP address of Trap 17 which may be 208.87.242.120 ( I am not sure, because they might have used some router on a stick technique and they might have multiple logical interfaces in their router ). Finally now the client got the IP address and it gets connected to the server. This is the working of the domain name server. Now the thing that has to be noted here is that every time the query goes around the internet day in and day out as DNS packets. So let me give a quick glance about what is DNS Packet and what does it contains.The main constituents of a DNS packets are Source and Destination IP address,source and destination port numbers which is port 53/udp for queries from the outside world, the first packet of any exchange always includes 53 as the UDP destination port. The source port varies. Sometimes it is also port 53/udp, sometimes it is a fixed port chosen at random by the operating system.As far as DNS functionality is concerned, the source port is not a big deal.As long as the replies get is sent to it properly.Next comes the Query ID, This is a unique identifier created in the query packet that's left intact by the server sending the reply: it allows the server which makes the request to associate the answer with the question. Some thing like to reply to the one who asked the question. Now there is something known as the DNS Cache where some important data is stored.These data are nothing but the IP address for the corresponding domain names. For example above we have seen how Xistos IP address is being resolved and given back to the user who requested it. On the other hand just think if some other user requsest for the same domain namess IP address is it necessary to again go into the internet and search and come and then give it back to the user ? It consumes time and resources.By saying it consumes time what I mean is that when the DNS packets goes arount the internet and and it fetches the required record and it comes back. By mentioning "Resources are wasted " what i mean here is that when the query goes out into the internet, there is a consumption of bandwidth, though the DNS packet is going to be less in size still when million of DNS packets travel around the internet there is a considerable amount of bandwidth being consumed . Inorder to avoid this the DNS server goes for caching technique. Here i dont reffer to web caching where in the webpages are cached and kept in store. On the other hand this is DNS Caching where in the IP addresses which are already resolved are cached and stored in the DNS server for retrival . Which means if a user requests for some webpage , and if that webpage IP address is already stored in the DNS Cache , then the DNS returns it to the user who has requested it instead of going to the internet and finding it all again. So by this there is a conservation of bandwidth and time which can be used for something else. So the conclusion over here is that DNS Caching is good. So now is there any vulnerability in the DNS Caching or is it that the DNS caching technique is totally safe ? I would say there is definitely lots of vulnarablity in the DNS and only a few has been found till now. The pathetic situation in that is that the vulnarablities that has been found till date exists even today. One such vulnarablity is to exploit the sequential incrementation of the query ID . when the DNS request goes out to the internet to fetch the IP address, the DNS packet uses a query ID to map the request and get the response. So just imagine what if some one gets the query ID right ? If some one get s the query ID then easily they can create fake DNS packets and send it to the DNS, so that it accepts it and puts an entry in the cache which will be serverd to its users. So just Imagine if some one requests for https://www.paypal.com/de/webapps/mpp/home and if the requests goes outside into the internet and before the reply comes if the attacker sends a DNS packet to server with the same query ID and with the details that https://www.paypal.com/de/webapps/mpp/home has the IP of xxx.xx.xxx.xxx then the Domin name server will accept the packet which the attacker has sent. So lets examine why does the Domain name server accepts that packet which is fake . If you see to this the answer is simple the Domain Name Server will accept any reply provided the Query ID matches to the one which it has sent. So if you see this carefully the Domain Name Server accepts the reply which it has got first. Let it be the orginal reply for the DNS query or the Fake reply which it has got, the first reply which matches the query ID is accepted by the server. Taking this into advantage attackers send Fake DNS Packets to the Server, thereby poisoning the DNS Cache. So just imagine here if the Cache is poisoned, its just not the only user who requested the IP is getting affected , all those who try to vist the same domain name are affected because of this. So the attacker aims not at one user but on a whole network . So now the question is how is that the attacker gets the exact query ID of the DNS packet which has been sent to the internet which is searching for the IP address of the domain https://www.paypal.com/de/webapps/mpp/home.'>https://www.paypal.com/de/webapps/mpp/home. Here the attacker uses a simple trick like; the attacker himself hosts a Domain Name server outside the network and a web server. Let me call it http://www.attacker.com/ now in this situation if the attacker visits his website from some other network, the DNS query is raised by that network and finally the requests comes to his own doming name server where he can see the request DNS packet. Now that the attacker has full control over his own DNS server he can easily get the query ID for attacker.com DNS request packet. In such a case let me say the query ID he got for http://www.attacker.com/ is 1023, then 1024 is the query ID for the next DNS request which falls after http://www.attacker.com/ . So in this case if the attacker visits http://www.attacker.com/ and immediately if he visits https://www.paypal.com/de/webapps/mpp/home,'>https://www.paypal.com/de/webapps/mpp/home, and if paypal.com IP is not present in the DNS cache, then the Query ID for the DNS packet of paypal.com us going to be 1024, approximately it may be between 1024 to 1034. So now if the attacker floods DNS reply packets to the DNS server with those query ID and with that data which says the IP address of pay pal.com is xxx. Xxx.xxx.xx , the DNS server accepts it and stores it in its cache ( this remains in the cache till it is cleared or till TTL ) . Here there is a sad part, when theoriginall reply comes, the DNS server rejects that reply because already it has got a reply which has been matching the query ID. So in this case the DNS packet containing the original reply is discarded. This vulnerability is tested and it works perfectly . Now looking at this particular vulnerability Dan Kaminski suggested a simple solution, why to increment the query ID in the DNS packer sequentially. Instead some random incrementation of the query ID can be carried out which will help to over come this problem. But the sad thing is that , that solution is not implemented proplerly today and even today many DNS server goes for sequential incrementation of the query id in the DNS packet which is such a big vulnerability for the whole domain naming system.