DNS hacking (beginner to advanced) 203

Today we will learn about DNS hacking (beginner to advanced) in this article.

DNS is a naming system for computers that translates human-readable domain names such as (infosecinstitute.com) into computer-readable IP addresses. However, some vulnerabilities exist due to misconfigured DNS nameservers that can lead to the disclosure of domain information. This forms an important step of the information gathering phase during a penetration test or vulnerability assessment. In this article we will look at the following areas.

• DNS Basics
• Resource records and zone file
• DNS lookups and reverse DNS lookups
• Comprehension by typing wildcards
• DNS zone transfer
• DNS Bruteforce

1) DNS hacking Basics

DNS translates human domain names into IP addresses. This is because domain names are much easier to remember than IP addresses. This process can be through a local cache or through a zone file that is present on the server. A zone file is a file on the server that contains entries for various resource records (RRs). These records can give us a lot of information about the domain. In the next section, we’ll look more at Resource Records and the Zone File.

So let’s understand how DNS resolution works. Let’s say a user opens a browser and types in infosecinstitute.com. It is now the responsibility of the DNS resolver in the user’s operating system to obtain an IP address. It first checks its local cache to see if it can find an entry for the domain name being queried. The cache usually contains mappings of IP addresses to hostnames that are saved during recent lookups, so that the resolver does not have to retrieve the IP address again and again. If it can’t find an IP address in its cache, it queries the DNS server to see if it has a record for it. A DNS server is usually provided to you by your ISP, or you can set up a DNS server manually. If it still can’t find an IP address, it goes through a process or recursive DNS query where it queries different name servers to get the domain’s IP address. Once it finds the IP address, it returns the IP address back to the user and also caches it for future use.

Let’s do a quick demo. For this demo we will use the “nslookup” tool. Just enter the commands as shown in the image below.

Introduction to Nslookup

• a) In the second line, we set type = a. This means that we are querying the A records, which will return the IP address in return for the domain we are querying. We will look more at the records in the next section.
• b) Once we enter google.com, we get an output showing the server and IP-address#port. This server is basically the current DNS server that will serve our request. In this case it is 10.0.1.1 and the port number is 53. This is because DNS uses UDP port 53 to service its requests. We can also set the current DNS server using the “server IP-address” command
• c) The third line in the output shows “Non-authoritative response”. This basically means that our DNS server has asked an external DNS server to get an IP address. Below we see all the IP addresses associated with google.com. This is usually the case with large organizations. They use multiple servers to service the request because one server is generally unable to handle all requests.

QUICK EXERCISE – Set the current server to ns1.google.com using the “server ns1.google.com” command and see if the output for querying the google.com domain still shows “Non-authoritative response”. . Also explore Dig and see if you can do the above exercise with Dig.

2) Resource records and zone file

A zone file is basically a text file present on the server hosting the domain that contains entries for various resource records. Each row is represented by a different record. In some cases, these records may exceed one line and must therefore be enclosed in parentheses. Each zone file must begin with a Start of Authority (SOA) record containing the authoritative name server for the domain (eg ns1.google.com for google.com ) and the email address of the person responsible for managing the name server. Below is an example of a zone file.

• $ORIGIN infosecinstitute.com.;This marks the beginning of the file
• $86400 TTL; TTL is 24 hours, it can also be 1d or 1h
• infosecinstitute.com IN SOA ns1.infosecinstitute.com. webmaster.infosecinstitute.com. (
• 2002026801; the serial number of this zone file
• 2d; refresh time for slave
• 5h; repeat time for slave
• 2w; expiration time for slave
• 1h; maximum cache time)

• NS ns1.infosecinstitute.com. ; ns1 is the name server for infosecinstitute.com
• NS ns2.infosecinstitute.com. ; ns2 is the backup name server for infosecinstitute.com
• MX 10 mail.infosecinstitute.com. ; mail server
• ns1 A 192.168.1.1; IPv4 address for ns1.infosecinstitute.com
• www CNAME infosecinstitute.com ; www.infosecinstitute.com is an alias for infosecinstitute.com
• ftp IN CNAME www.infosecinstitute.com. ; CNAME for ftp
• mail A 192.0.3.2 ; IPv4 address for mail.infosecinstitute.com

a) As we can see that on the second line it contains a TTL value, which means that all resource records have an expiration time of 1 hour, after this time each record will have to do another query and refresh its data.

b) We can also see the various records that are present in the zone file. The general way to write a resource record is to write the domain name, record class, record type, and then some other information.

There are different types of resource records in a zone file. However, we will discuss some important ones

Entries – Maps an IP address to a hostname. E.g. 74.125.236.80 for google.com.
NS Records-Delegates the given zone to use the given authoritative name server. For example, ns1.google.com is the authoritative name server for google.com
MX records basically tell us which server is responsible for receiving emails sent to that domain name.
TXT records – consists of freely readable text in the record.
CNAME Records- Assigns an alias of one name to another.
Let’s do a demo to make it clear. I’ve intentionally added some entries for this article to my search-eye.com site so they may not be available when you do this, but you can try the same exercise on other domains, enter the commands as shown in the image below.

Nslookup detail

a) In the first command in nslookup, I set the type to A, which means I want the IP address for a specific domain. As the second command, I enter the domain name and get the corresponding IP address for it.

b) In the third command, I set the type to NS because I’m interested in finding the nameservers for search-eye.com. Enter the domain name as the fourth command and we will get the matching nameservers for the search-eye.com domain. Please note that finding nameservers can provide us with some information about the domain hosting provider. Some large organizations use their own name servers, eg ns2.google.com.

c) Now I will set the current server to one of the nameservers because I am interested in finding the latest information about the domain. Please note that querying your own DNS server may not always give you accurate information. I set the type to MX and enter the domain name again. We will receive a list of mail servers responsible for handling emails sent to this domain. The number in front of them indicates the priority with which the messages should be loaded. The lower the number, the higher the priority.

d) Next, I set the type to CNAME and write the subdomain, I get a canonical name like infosecinstitute.com. This means that any request to the queried domain (in this case prateek.searching-eye.com) will be redirected to infosecinstitute.com.

I’ll take this moment to introduce DIG, which is a nifty little tool, we can do the same queries with DIG as well. Let’s search for MX records in the same domain. I would suggest that you try to search for other domains yourself.

3) DNS lookup and reverse DNS lookup

DNS lookup

We will do a DNS lookup for infosecinstitute.com ourselves. We do this by traversing the entire DNS hierarchy from the root servers to the top-level domain. Open a terminal in Backtrack (you can use your own favorite distro) and type “dig”. You will get something as shown in the image below.

We get a list of DNS root servers. Let’s use this DNS root server to query infosecinstitute.com. We do this as shown in the image below

Do the 1st query

We get a list of authoritative name servers for the domain com. Note the dot (.) at the end, this makes it a fully qualified domain name (FQDN). Let’s use these nameservers to query again.

Do the 2nd query

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

Do the 3rd query

And now in the response section we can see that the IP address for infosecinstitute.com is 216.92.251.5. SUCCESS!

Reverse DNS lookup

Performing a Reverse DNS Lookup will convert an IP address to its hostname. To do this, we need to write the IP address in reverse order (eg 192.168.1.1 will be 1.1.168.192) and then append “.in-addr.arpa”. to. Next, we need to create a PTR record query using DIG. Let’s do a DNS PTR query for 216.92.251.5, the command here will be “dig 5.251.92.216.in-addr.arpa PTR”

4) Understanding wildcard input

Wild card

A wildcard is used to provide answers for subdomains that do not exist. For example, let’s say we have the domain example.com. If we set a wildcard for *.example.com and assign it the value example.com , then requests for all non-existent subdomains of example.com (eg abcd.example , blah.example.com ) will point to example .com . In the information gathering phase of a website penetration test, it is important to identify subdomains and their corresponding IP addresses. The introduction of the wildcard feature limits this to a small extent.

Bypassing wildcard entries

If wildcards are set on a particular domain, they can be bypassed to reveal information about its subdomains. This is done by brute forcing subdomains. We have a word list that contains the names of the subdomains we want to test the domain against. We then ping all those subdomains, if those domains translate to an IP address other than the host’s IP address, then we can confidently say that that subdomain actually exists. However, it would be better to actually check if wildcard entries are allowed or not before brute force. For that, we can ping some random subdomains like 434234.example.com and see if its IP address is the same as the IP address of the host (example.com in this case). If this is the case for some random subdomains, then we can clearly say that Wildcards are allowed for that domain. We will do a demo in the upcoming section.

5) DNS zone transfer

In the previous exercises, we saw that each domain has some authoritative name servers associated with it. For example, in the case of google.com, the name servers were ns1.google.com through ns4.google.com. These name servers are used to handle requests related to the google.com domain. Let’s say we have a domain example.com and it has its two name servers as ns1.example.com and ns2.example.com. A large organization will typically have more than one name server, so that if one fails for a period of time, the other is ready to back it up and handle requests. Typically, one of these servers will be the master server and the other will be the slave server. So, to stay in sync with each other, the slave server must query the master server and retrieve the latest records after a certain period of time. The master server will provide the slave server with all the information it has. This is basically what is called a “zone transfer”. It’s like asking a nameserver “Give me everything you’ve got”. A properly configured nameserver should only be allowed to service zone transfer requests from other nameservers of the same domain. However, if the server is not configured correctly, it will serve all zone transfer requests made to it without checking the querying client. This leads to leakage of valuable information. DNS zone transfer is sometimes denoted by the mnemonic AXFR.

Let’s look at an example of zone conversion. We will use the Fierce tool that is present in Backtrack by default. Fierce is one of the best DNS analysis tools available. Enter the following command “perl fierce.pl -dns search-eye.com”. We get something that is shown in the image below.

The wild thing is that it first finds out the nameservers for the domain. It then checks to see if they allow zone transfers. Because one of the nameservers is not configured correctly, it allows the zone to be transferred and what we see is a dump of all the information (records, subdomains, etc.).

Also read:An Evolution of MBR and VBR Infection Techniques : 0lmasco

Why is zone transfer a security issue?

Converting a zone reveals a lot of information about a domain. This forms a very important part of the “gathering information” phase during a penetration test, vulnerability assessment, etc. There are a lot of things we can find out by looking at a dump. For e.g. we can find different subdomains. Some of them may run on different servers. This server may not be fully patched and therefore may be vulnerable. From this point we can start thinking about Metasploit, Nessus, Nmap, etc. and do a full domain vulnerability assessment. Therefore, this kind of information increases our attack vector by a decent amount that cannot be ignored.

To protect your name servers from leaking valuable information, you must allow zone transfer only to other name servers of the same domain. For eg ns1.example.com it should only allow zone transfer to ns2.example.com and drop all other requests.

6) Brute force DNS

DNS zone transfers may not always work. In fact, most of the time it won’t work. Most DNS servers are properly configured and do not allow zone transfers to every client. Well, what do we do then? Simple answer, the same thing we do when nothing works, BRUTE FORCE! Basically we have a list of words containing a huge list of hosts. We first check for wildcard entries by checking that a random subdomain for eg 132qdssac.example.com resolves to the same IP address as example.com. If this is the case, we know that wildcards are set. We then query the domain using each word in our list of words. For example, if one of the items in the file with the word list is “ads”, we create a query for ads.example.com. If it translates to another IP address, then we are sure that this subdomain actually exists. So now we have information about the subdomain name and its IP address. If no wildcards are set, we’ll do the same and see if we get a response from whatever subdomain we’re querying. If we get a response back, we can be sure that the subdomain actually exists. Finally, we get a lot of information about the domain.

Let’s see it through a demo. We’ll use the “Fierce” tool again. Fierce is a very useful DNS analysis tool and something everyone should have in their arsenal. Fierce will first check if zone transfers are enabled or not, if zone transfers are enabled it will output all the information and happily exit, otherwise it will brute force. We need to supply Fierce with a wordlist containing a list of all possible subdomain names (eg hosts, ads, contracts). Fierce comes with a built-in word list file “hosts.txt” and we will use the same for our demo.

Conclusion

The DNS protocol is a very critical part of the Internet because it converts IP addresses into hostnames and makes our lives easier. However, if name servers are not configured properly, they can leak the entire DNS server database to any malicious hacker. Even if servers are properly configured, they can be brute force to leak information about their mail servers, IP addresses, etc. It is therefore important to properly configure DNS servers and be aware of DNS security issues.