I am currently working in the RCNTEC company where I have a deal with distributed environments everyday. Once I had to work with the ISC BIND to implement DNS service and asked myself - are there only those DNS servers for domain are used, that are listed as NS servers for this domain? Are there really only two nameservers for ‘yandex.ru’ zone and four for ‘google.com’ zone?
Obviously, no. I think that a lot of companies, that have their work with Internet services, have distibuted DNS infrastructure standing behind load balancer, firewall or some kind of reverse proxy.
But how can we solve the mystery and get some info about backend DNS servers?
It was a time to dive into DNS.
Chaosnet
You can read more about Chaosnet here. In two words, it is another network protocol working on Layer 3 of the ISO OSI.
Regarding DNS, Chaosnet was recognized as one of the network classes (with code CH) like IN (for Internet) and HS (for Hesiod).
Chaosnet is very interesting, because CH class is used frequently to serve zone ‘bind.’ containing several useful info about DNS server. I think that you know about ‘version.bind.’ record that allows you to determine DNS server version.
There is commonly used DNS fingerprint technique based on this record.
Just see an example:
As you can see above, I requested Chaosnet TXT-record ‘version.bind.’ from my own DNS-server and got the response containing my DNS server’s version.
We can get DNS server version, but we still couldn’t enumerate DNS servers behind a relay. Also, a lot of system administrators know about this ‘feature’ and know how to fix this and hide version.
Even if our target’s system administrator has not patched zone ‘bind.’, we can’t enumerate DNS anyway - this is only version, not IP or anything similar.
Another CH TXT-record
TXT-record ‘hostname.bind’ is another record available in CH zone ‘bind.’. Let’s see, what happens if we will request this record from our DNS-server:
Great! We got server hostname. In my case, hostname is only internal server name. But what about distributed environments?
My experience said that this is very convenient and common to have servers hostnames equals with their external DNS names. In this case, with internal hostname we will get external DNS name too. And we can simply resolve external DNS name to obtain server IP.
Unhidens
I had written a small utility to run ‘dig’ against relay to determine versions, hostnames and resolve received hostnames.
Let’s see output of unhidens launched against russian domain registar’s nameserver:
As you can see, there is only one DNS placed behind 31.177.85.186. In fact, we just extended our testing scope with IP 31.177.85.194 and name ‘ns9-1.nic.ru’.
What about Yandex?
I launched my script against their systems too :)
Booom! We completely enumerated Yandex’s backend DNS-servers placed behind public machines. We can request hostnames and resolve them to get their addresses.
In case of Yandex all found machines were firewalled, so I was unable to contact them directly. But I tried unhidens against couple of other companies and sometimes I saw machines with vulnerable versions of the DNS software and even machines with opened TCP/53 port.
Conclusion
Information disclosure described in this article is not a critical bug, but can be used by attacker to extend attack surface.
Try unhidens against different domains and I am sure you will like this!
And remember that ‘bind.’ zone is not only ISC BIND feature - I saw a lot of different DNS servers affected to that information disclosure.
If you want to close this issue on your DNS servers, I recommend you to manually handle CH zone ‘bind.’.
Just add something like that in ‘named.conf’ in case of using ISC BIND:
And create ‘bind.dns’ zone-file:
This is not the easiest way to hide your version and hostname, but with this configuration you are able to log requests to the ‘bind.’ zone - and track all clients trying to request sensitive info about your machines.
Written by German Namestnikov.
Find more here: BLOG
Author
Latest Articles
New Edition
