How to test BIND version running on DNS server?

Running an old version of BIND (version 4 or 8 in forwarding mode) on the DNS server you use leaves it vulnerable to DNS cache poisoning (Pharming).
Version 9 of BIND appears to not be vulnerable (even in forwarding mode?).
The problem is contacting the owner/admin/operator of the DNS Server is a dead end because they won't answer any questions about the server (rightfully so).
So how can I test what version is being used and if it is in forwarding mode?

 

I can't speak for the accuracy of this, but here is something I found with a quick google search:

However, it's not all good news...

I would hope that people canny enough to hide their version info would be on an non-vulnerable version.

Hope it helps. Would be very interested to know if it works.


Mike

 

Hi Mike,

Thanks for the looking into this.
I tried several variations but it came back server failed.

nslookup -q=txt -class=CHAOS version.bin.my.dns.server
nslookup -q=txt -class=CHAOS version.bin.my.dns.ip.address

I tried another DNS server, but it also came back server failed.
I used the exact syntax as above, replacing my.dns.server with the domain name for my DNS and replacing my.dns.ip.address with the ip address of my dns server.

Am I also supposed replace "version" and "bin" with something?
Could you point me in the right direction so I could research/learn more?

 

Hi Devinco,

I also found this referenced in a Redhat mailing list:

dig -t txt -c chaos VERSION.BIND @my.dns.server.net

So, it seems maybe version.bind should have been typed.

Do you have control of a test server that you are testing? because not all DNS runs on bind.


Mike

 

Mike,

I'm using XP Pro and from the DOS command prompt it replies with this:

'DIG' is not recognized as an internal or external command, operable program or batch file.

I guess Dig does not come standard with windows.
Do you know a trusted download location for dig?

As far as the test DNS server, no, I am just investigating ways to reduce the risks of pharming. But setting up your own DNS Server would certainly be one way to guarantee that it is running the latest version.

Thanks

 

Ok, a couple of things

Not all DNS servers run Bind. There are other ones (windows.. *shudder*), PowerDNS are two that come to mind. I am not sure if these servers provide a method by which you can tell if they are running. This is not really my area of expertise.

On windows, try nslookup -q=txt -class=CHAOS version.bind 192.168.51.250

Not sure if it will work or not - and there's not really a way for you to tell either, unless you can find a bind server that has its security options deactivated.

The way that we deal with DNS attacks in OA is to simply compare results of the local DNS against a central DNS. If they don't match, one of them may be compromised.


Mike

 

Thank you for the info.

It works!!!

The reply from one DNS server was:
VERSION.BIND text = "(actual bind version number here)-REL"

What does the -REL mean?

The reply from another DNS server was:
version.bind text = "Surely, you jest..."

While it is good that the DNS admin thought enough to conceal the actual version number (to prevent hacker profiling), it does not mean that it is not running an exploitable version. I guess one has to trust them??

Thank you.

When you say local DNS, do you mean the local (on my computer) DNS cache (DNS Client service)?
When you say central DNS, do you mean the DNS server I connect to (like my ISPs DNS)?
Or do you mean central DNS as one of the 13 root DNS servers?
Since the Pharming attack is done on the DNS server that I connect to, I don't understand how OA installed on my computer could protect me from a poisoned DNS cache on a remote server.

 

Excellent

No problemo. I have no idea what the REL comment means; Release? But, I did enjoy the "Surely, you jest..." comment.

Ok, this is deceptively simple. There are two attacks we are trying to detect here:

1. Your machine has been told to connect to a different DNS, owned by an attacker.

2. Your machine is connecting to a valid DNS, which has been compromised and is given Evil Results.

In either case, if we assume that the goal of the attacker is to make you go somewhere "nasty" instead of where you want to go, and he is doing this by changing a DNS entry. So, you type in www.mybank.com - which should point to <goodip> , but the attacker has somehow subverted the DNS so that it points to <badip>.

So, regardless of how the DNS is compromised, we simply do this:

a) Resolve the DNS on yoru machine.
b) Resolve the DNS on our trusted DNS server.
c) Compare.

If your machine resolves mybank.com to <badIP> and my servers resolve mybank.com to <goodip> then there is a difference, and this is flagged.

But, what, you say, happens if my DNS is compromised. Well, in this case
your machine resolves mybank.com to <GoodIP> and my servers resolve mybank.com to <Badip> then there is a difference, and this is flagged.

Hope that helps


Mike

 

It helps a lot. Thank you. That is a very cool simple solution to pharming.
I hope your central trusted DNS is scalable, because as your OA becomes more and more popular, the load will multiply.
I hope you have a lot of success!

 

There's heaps of capacity, and we can just keep adding servers to cope with the demand