Monday, 4 August 2008

Determning DNS Version

There are several ways to determine the version of a DNS server. The more common ones include NSLOOKUP and DIG.

  • nslookup -q=txt -class=CHAOS version.bind [DNS Server IP or name]
  • dig -t txt -c chaos VERSION.BIND @dns.server.net

Each of these are essentially the same. They query the version ID of the server (if it has not been altered or deleted. Changing this is a simple exercise in BIND, though few servers have been thus secured.

A more complex way of doing this (where access to either DIG or NSLookup have been restrited) can be achieved in the following script:

which_dns() {
printf 'begin-base64 644 -\np8IBAAABAAAAAAAAB3ZlcnNpb24EYmluZAAAEAADCg==\n===='
uudecode nc -uw 1 $1 domain strings tail -1; }

This is run as follows:

  • which_dns [DNS Server IP or name]

Ths simple function is useful in testing systems. If access to a shell can be obtained, tests through a firewall could provide information from the servers inside the DMZ or internal network. These systems are commonly not well secured and access to a script such as the previous one can be invaluable in systems testing.

Another way

The methods listed initially all require that the DNS server administrator has not changed the version number. Good practice calls for this to be changed. In my presentation at CACLS (Sydney) 2008 in September for ISACA, I am addressing some new ways of determining versioning.


Using a combination of Neural networks and Random Forest algorithims, I have created a test engine for DNS. The NMAP and PoF databases where used are an initial feed. This data was tested with many of the versions of DNS (both BIND and Windows). This led to a multilayer perceptron that can determine the DNS version even when the versioning information is disabled.

This method can be used to find server versions using standard calls to the DNS server. This appears as standard traffic to the server and does not register as an attack.

I also used this in the DNS paper I am publishing later this month.

Unfortunately, what this demonstrated is that some of the higher level DNS servers are not patched. One of the com servers in particular was very poorly patched when tested. A strong reliance on obscurity through hiding the version information has led to a state of apathy.

This leaves us all vulnerable.

No comments: