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:
NSLookup
First of all, we indicate the victim server on which we are going to operate:
We can then make a request to localhost (127.0.0.1) to see if we get lucky and the response exposes a hostname (not the case):
Next we try the IP of the server:
Reverse lookups in this case are disabled, so we can’t get any information from here.
Finally we can check the domain name, as in the nmap it appears in HTTP Title HTB Bank, maybe bank.htb responds something:
It does indeed respond.
In this other example, checking the domain name reveals an IPv6 address, which we can use to nmap that address to see if we get any different ports.
Next we can try another tool, dnsrecon, to brute force reverse lookups on a range:
DNSRecon
You have to try several ranges, such as 127.0.0.0.0/24, 127.0.1.0/24 and 10.10.10.0/24, because many host files include these ranges. No luck on this occasion.
We could do this more comprehensively with a small script like this that we would leave running:
Dig
Now we are going to try to make a zone transfer, for this we use the axfr flag of the dig tool:
We got nothing, so zone transfers are not enabled for the root zone. However, let’s try the same thing but indicating the domain we discovered earlier:
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
If we are on a windows machine and we want to export the DNS zone, we can do it with powershell as follows:
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:
Query to display the members of a group:
User 0x451 is the member of the Contractors group, which is the DNS Admins group.
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:
https://medium.com/techzap/dns-admin-privesc-in-active-directory-ad-windows-ecc7ed5a21a2
Basically you create a malicious dll and run the dnscmd.exe program.
If megabank.local doesn’t work you can try 127.0.0.1
Then we restart the dns service with the commands sc.exe stop dns and sc.exe start dns.
And in this way, listening on the port that we have configured in the dll, we will get an administrator shell:
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.
Lethani.
Be First to Comment