A New DNS Exploitation technique - Ghost domain names

DNS is a naming system which coverts human readable domain names into computer readable IP addresses. Whenever there is a query for a domain which is not in the resolver’s cache, the process happens by traversing through the entire DNS hierarchy from the root servers to the top level domain (for e.g .com). The top level domain then gives us the information about the nameserver that has been delegated the responsibility of the domain whose IP address we are looking for. We then get the information about that domain from it’s nameserver. The results are then cached by the DNS resolver with a particular value of TTL(time to live) after which the entry in the cache expires. In some cases a domain may be identified as malicious and needs to be removed. This could be because of various reasons like malware propogation, phishing etc. One of the steps to prevent users from accessing this domain is by deleting the domain from its TLD (top level domain) servers. However this does not completely remove the threat because the domain will still be resolved by the resolver until the TTL expires. In this article we will discuss about a recent DNS exploit discovered by researchers which is present in most of the DNS servers which exploits a weakness in the cache update logic of some of the DNS servers. This allows their cache to be overwritten in such a way that it is possible to continuously extend the TTL for the delegation data of a particular domain and prevent it from expiring. Hence the domain will be completely resolvable even though it has been deleted from the TLD servers. These types of domains have been named as Ghost Domain Names.

This article is based on the recent work by Jian Jiang, Jinjin Liang, Kang Li, Jun Li, Haixin Duan and Jianping Wu. The research paper by them can be found here.

DNS Basics

So Lets understand how DNS resolution works. Lets say the user opens up the browser and types in infosecinstitute.com. It is now the responsibility of the DNS resolver in the user operating system to fetch the IP address. It first checks its local cache to see if it can find a record for the queried domain name. A cache usually contains a mapping of IP-addresses to hostnames which are saved during recent lookups so that the resolver does not have to fetch the IP address again and again. If it cannot find the IP address in its cache it queries the DNS server to see if it has a record for it. A DNS server is usually given to you by the ISP or you can manually set up a DNS server for yourself. If it still cannot find the IP Address then it goes through a recursive DNS query in which it queries different nameservers to get the IP-address of the domain. As soon as it finds the IP-address it returns the IP-address back to the user and also caches it for its future use.

Understanding DNS lookup

It is important to understand how a DNS lookup works. We will do this by traversing the entire DNS hierarchy from the root servers to the top level domain. Open up the terminal in Backtrack (you can use your own favourite distro) and type in “dig”. You will get something as shown in the figure below.

What we get is a list of the Root DNS Servers. Let’s use this root DNS server to query infosecinstitute.com. We do this as shown in the figure below

What we get is a list of authoritative name servers for the com domain. Notice the dot (.) at the end, this is what makes this a fully qualified domain name (FQDN). Let’s use these Name servers to query again.

Now we get the list of authoritative name servers for infosecinstitute.com (which is ns1.pairnic.com and ns2.pairnic.com). Now we need to query these name servers to get the IP-address of Infosecinstitute.com

And now in the Answer Section we can see that the Ip-address for infosecinstitute.com is 216.92.251.5. SUCCESS !

It is also possible for us to set custom DNS servers to query for different records. In the figure below, we will be using DIG to perform a DNS query for the A record of infosecinstitute.com using Google’s DNS server (8.8.8.8).

The thing 3599 basically indicates the time to live for that particular record provided by the DNS query. If we do the same process again we can see that the TTL has now reduced to 3503.

In case a domain is identified as malicious, then its removal from the global domain name space is basically a 2 step process. The first is to remove its records from the TLD servers and the second is to wait for the TTL to expire across all DNS servers.

To identify the IP address of a domain, one of the important things to know is the delegation data of that particular domain. The delegation data contains the NS record of a domain and its corresponding A record, i.e the IP address of the nameserver. The delegation data also has a particular TTL which tells us the time until which the delegation data will be in the cache. In the figure below, i am querying one of the TLD servers for .com to give me the address of an unexisting subdomain. It replies back with an Authority and an Additional section which has the NS records for the domain as we as the IP address (i.e A record) of the nameservers.

Let’s see this through an example. Let me create a subdomain named infosec.searching-eye.com on my website.

Once it is done, let’s use a particular open DNS server say 8.8.8.8 (OpenDNS) to query the domain.

We can see the response in the answer section. Also we can see that it has a particular TTL value of 14399. The delegation data is now cached by this server. So let’s go ahead and remove the subdomain now.

As we can see, the subdomain infosec.searching-eye.com has been successfully removed. Now let’s go ahead and make the same query for the subdomain infosec.searching-eye.com from the same DNS server.

Surprise, we still get a response. This is because of the cached records that are present in Google’s DNS server. As we can see the TTL has decreased down to 12790. We know why this response is here. This is because of the fact that the delegation data for the subdomain has been cached into the DNS server because of the query we made while the subdomain was live. Let’s make the same query for the same subdomain through our default DNS server.

As we can see from the image above, we get no response. This is because there were no cached records present in our default DNS server due to which it had to traverse the entire DNS hierarchy in order to find the IP address of the subdomain we were looking for. Once it reached the TLD (i.e .com), it found out that there were no records there. Hence it returned no results.

The Vulnerability

The vulnerability exists in the DNS cache update policy of a particular DNS server. As discussed earlier in the article, a domain can be completely removed from the global domain name space by removing it from the TLD and allowing enough time for the delegation data to expire across all DNS servers. If somehow it is possible to extend the TTL of delegation data such that it doesn’t touch 0, then the domain will still be resolvable.

Note that not all the DNS servers will be vulnerable to this kind of an exploit. However it is discussed in the paper that most of the DNS servers were found vulnerable simply because they did not follow a strict cache update logic.

The first step is to register a nameserver. This service is generally provided by your domain service provider. This is because i want my nameserver to be of the type xyz.mydomain.com rather than xyz.hostingcompany.com. Note that the IP address you provide must be a valid IP address of a nameserver.

Once we have registered a nameserver, we have to set it as our nameserver as shown in the figure below.

We can confirm that testns.searching-eye.com has been successfully set as a nameserver by querying for an non-existent subdomain as shown in the figure below.

We then create another subdomain named ghost.searching-eye.com.

Once this is done, we take a particular DNS server(which we think is vulnerable) and use it to query the subdomain.

So now we know that the delegation data has been cached by the DNS server. So now we go ahead and delete the subdomain. So now the delegation data of the domain will have a TTL which will be constantly decreasing. As we know that the delegation data is the NS record of a domain and the A record of the name server. It could be represented as..

ghost.searching-eye.com 86400 IN NS testns.searching-eye.com testns.searching-eye.com 86400 IN A abc.32.31.xy

After the subdomain has been deleted and some time has passed by, the delegation data could look something like this.

ghost.searching-eye.com 46400 IN NS testns.searching-eye.com testns.searching-eye.com 46400 IN A abc.32.31.xy

The next step is to change the name of the nameserver to something else like test2.searching-eye.com. Using the same DNS server (4.2.2.4) as before, we then query for the A record of the nameserver, i.e test2.searching-eye.com. The resolver will look into the delegation data and make a query to the IP address of testns.searching-eye.com which is infact the IP address of test2.searching-eye.com. It will return the IP address of the nameserver. But it will also notice that their is a new nameserver now (because the name has changed), and it will overwrite the current cache with the new one (cache update logic will vary across different DNS servers ). After the cache is overwritten, the delegation data could look something like this(depending on the fact that the DNS server does not follow a strict cache update logic and is vulnerable to the exploit discussed in this article).

ghost.searching-eye.com 86400 IN NS test2.searching-eye.com test2.searching-eye.com 86400 IN A 192.32.31.xy

We can notice that the new delegation data has a new TTL value. If this process is repeated over and over again, it is possible to continuously keep the TTL value from reaching zero. (Though in some cases it will touch 0 after a long period of time, read the paper for more details).

In order to successfully carry out this attack over a large range, the attacker had to make query through as many vulnerable DNS servers as possible before the TTL for the delegation data of the attacker domain expires on those DNS servers. As the number of DNS servers which still cache the delegation data increases, the number of users who still resolve the domain to an IP address controlled by the attacker also increase.

Detecting Ghost Domain Names

Ghost domain names are those domains that have been removed from the TLD but are still resolvable by the DNS server. There could basically be two reasons for it.

1. The TTL value for the delegation data of the domain has not expired. Note that these kind of domains may not qualify under the category of Ghost domain names simply because their is a possibility that their TTL is not being renewed.
2. The TTL value for the delegation data is being renewed somehow by using the vulnerability in the DNS server.

These are the steps that could be followed to identify the Ghost domain names.

1. Perform a DNS lookup on the domain by traversing the DNS hierarchy as discussed in the “DNS lookup” section in this article.
2. Query for an A record of the domain using a particular DNS server

If the DNS lookup step doesn’t give us an IP-address but we get a result from the DNS query step using a particular DNS server, then there is a possibility that the domain is a Ghost domain. We cannot be sure because the results might be coming because the TTL for the delegation data on the DNS server may not have expired (excluding the possibility of resetting the TTL). Hence the challenge is now to identify which are the ghost domains and which are not. The following steps could be followed for that.

1. Note down the TTL value for the delegation data.
2. Wait for the time equivalent to the TTL value of that domain. Perform the same query again. If the DNS server still resolves the domain then we can be convinced that the domain is a Ghost domain.

Conclusion

In this article we discussed a vulnerability recently discussed in a paper which signifies how it is possible to illegally update the cache of a DNS server and renew its TTL value for the delegation data of a particular domain. This would mean that the domain will still be resolvable even though it has been removed from the TLD. We then discussed some of the possible methods through which it is possible to determine if a particular domain is a Ghost domain or not.

References

1. Ghost Domain Names: Revoked Yet Still Resolvable
   https://www.isc.org/files/imce/ghostdomain_camera.pdf

2. DNS Hacking (Beginner to Advanced)
   http://resources.infosecinstitute.com/dns-hacking/

This article was originally published on the resources page at Infosec Institute. For more information, please visit my author page.