Ghost Domain Names: Targeting DNS Server Logic

[co4ie]

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 (e.g., .com). The top-level domain (TLD) then gives us the information about the name server 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 its name server. 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 propagation, phishing, etc. One of the more common methods to prevent users from accessing a domain is to delete the domain from its TLD servers. However this does not completely remove the threat because the domain will still be resolved by the resolver until the TTL expires. Normally, this is not an issue, as the TTL values are short and the offending domain will expire in seconds or minutes.

In this article we will discuss a recent DNS exploit which is present in most of the DNS servers that was discovered by researchers Jian Jiang, Jinjin Liang, Kang Li, Jun Li, Haixin Duan and Jianping Wu. Their full research paper can be found here.

The exploit targets a weakness in the cache update logic of some of the DNS servers. The exploit allows the 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 prevents it from ever expiring. The domain will be completely resolvable indefinitely even though it has been deleted from the TLD servers. These types of domains have been termed Ghost Domain Names.

DNS Basics

First, let’s understand how DNS resolution works.

Let’s say the user opens up the browser and types in infosecinstitute.com. It is now the responsibility of the DNS resolver in the user’s 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 name servers 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 favorite distribution) 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). Let’s query these name servers to get the IP-address of infosecinstitute.com

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).

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 name server. 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 a non-existing subdomain. It replies back with an Authority Section and an Additional Section which has the NS records for the domain, as well as the IP address (i.e., A record) of the name servers.

Let’s see this in an example. I’ll 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, thus 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 name server. This service is generally provided by your domain service provider. I want my name server 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 name server.

Once we have registered a name server, we have to set it as our name server as shown in the image below.

We can confirm that testns.searching-eye.com has been successfully set as a name server by querying for an non-existent subdomain, as shown in the image 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. Go ahead and delete the subdomain. Now the delegation data of the domain will have a TTL which will be constantly decreasing. Since we know that the delegation data is the NS record of a domain and the A record of the name server, it can be represented as:

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

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

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

The next step is to change the name of the name server 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 name server, 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 in fact the IP address of test2.searching-eye.com. It will return the IP address of the name server. But it will also notice that there is a new name server 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 (if indeed the DNS server does not follow a strict cache update logic and is vulnerable to the exploit discussed in this article):

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

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 reach 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 queries through as many vulnerable DNS servers as possible before the TTL for the delegation data of the attacker domain expired 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 be two reasons for it:

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 there is a possibility that their TTL is not being renewed.

The TTL value for the delegation data is being renewed by using the vulnerability in the DNS server.

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

Perform a DNS lookup on the domain by traversing the DNS hierarchy as discussed in the “DNS lookup” section in this article.

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 as 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 ghost domains and which are not.

The following steps could be followed for that:

Note down the TTL value for the delegation data.

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 methods through which it is possible to determine if a particular domain is a ghost domain or not.

References

Ghost Domain Names: Revoked Yet Still Resolvable

DNS Hacking (Beginner to Advanced)

Sursa