In this post we are going to talk about the Domain Name System, explore what this protocol consists of, list possible vulnerabilities and show the tools with which it can be exploited.
The DNS service is used to translate domain names into IP addresses. It runs on port 53. Let’s look at a simple example to understand all the roles involved in the hierarchical DNS communication:
We want to connect to www.google.com. As this address is not stored in our DNS Cache, we ask the Resolver, which is a DNS server of our Internet Service Provider (ISP).
The Resolver checks if it has www.google.com in its cache. It doesn’t, so it asks the Root Server. The Root Servers are 13 and are at the root of the hierarchical DNS system:
The Root Server sees that the request is to a .COM domain, so it redirects the request to a TLD Server.
A TLD Server stores the information of top-level domains such as .COM, .NET, .ORG, etc. It redirects the request to the Authority Name Server that knows the information about the google.com domain.
Finally, the Authority Name Server of google.com receives the request and returns the IP address belonging to the subdomain www.google.com.
Both our DNS cache and that of the ISP’s DNS server are updated, so that the next time we want to access www.google.com there is no need to ask for the IP (as long as it is cached).
DNS in Nmap
The DNS protocol normally only uses UDP, however it uses TCP in cases where the response is larger than 512 bytes. And the response is larger than 512 bytes when DNS zone transfer is enabled.
Zone transfers are acts of database replication between related DNS servers. Normally when there is a change in a DNS file (e.g. a domain changes IP) the change is made on the primary DNS server, and then the change is replicated to the secondary servers.
Zone transfer is used for this purpose. However, if it is misconfigured, not only the secondary DNS servers will be able to replicate the file, but anyone who requests it.
The purpose of a zone transfer is to get the different domains and subdomains on the server to collect information.
Finding in nmap that the DNS is using TCP is therefore a clear sign that we should try to do a zone transfer:
In this other example we can see that it shows us the microsoft DNS version, searching in google we find that it is associated to Windows Server 2008 R2 SP1.
Always look out for possible subdomains that we find exposed anywhere, for example on this machine we can find many subdomains in the nmap information for port 8080.
To make a zone transfer we can use the dig tool, but first let’s try to get more information with other tools:
Now we have been able to perform a zone transfer and obtain the subdomains chris.bank.htb, ns.bank.htb, and www.bank.htb.
What we must do is add these domains to our /etc/ hosts file, to include them in our dns cache indicating that they correspond to the IP 10.10.10.29.
There are times when indicating a different subdomain the server shows us something else on the web, as we saw in the game of thrones CTF.
Another option is, since the machine has DNS, we can add the line “nameserver 10.10.10.29” to our /etc/ resolv.conf file to add the machine as our DNS to query.
Export DNS zone with powershell
The resulting file with the information can be found in C:\Windows\system32\dns:
Spying on UDP port 53 traffic
If there is an application that we know sends traffic to a DNS server, we can spy on the traffic with tcpdump:
DNS Server in Active Directory
Using this program https://github.com/GhostPack/Seatbelt
We discovered the DNS Admin ssid:
If you notice, the DNS doesn’t end in 500 something, that means it’s not a default, like all the users above, so it’s something we need to investigate.
We are going to do queries using rpcclient:
If we obtain this user’s credentials and get a shell, we can execute code in the Domain Controller by escalating privileges in this way:
Basically you create a malicious dll and run the dnscmd.exe program.
The only problem is that the dns service will hang. To get a shell without crashing, you should wait until next week post.
I hope all this information about the DNS protocol has been useful for you. See you in future posts with more protocol vulnerabilities.