huge bind exploit

[Red Squirrel]

I heard theres an exploit in bind allowing anyone go to and change DNS records around. The news articles I seen are very broad on what the flaw exactly does and don't provide any technical details, but I just want to fix it.

I did yum update bind. Is this enough? or do I need to do a special case when it comes to security updates? I'm using CentOS5.

 

[child of wonder]

Keep your system up2date and you should be fine. Keep up with the latest, however, and study the vulnerability.

However, if UDP 53 isn't open to the internet on your server then you don't have much to worry about.

 

[Red Squirrel]

I updated bind but its only showing version 9.3.4-P1 and i've read that even 9.4 is vulnerable. Any way to go higher? I used yum update but guess they did not put in the package for centOS yet. any way to manually patch it?

Also, what exactly IS the flaw? it seems no sites are really explaining it properly. I really can't see why anyone could modify DNS records through DNS, but thats what the flaw sounds like it allows. DNS is modified by being logged in as root and modify the zone files, so why and how can it be done through DNS itself by connecting to the port?

Also this flaw seems to work is MS's DNS too, kinda odd all of them have it, they use the same code or something? lol

 

[child of wonder]

It has to do with the DNS protocol itself so it's not limited to any particular OS or application.

What version of CentOS are you running?

 

[lousydood]

Bind is a security hole, period. If you run it, do so in a chroot jail. I'm a fan of TinyDNS (DJB), personally.

Besides that, there are ways for DNS servers to be modified other than changing the zone records directly. DNS allows servers to be setup as slaves to other servers, and they receive updates accordingly. Never struck me as terribly secure.

 

[Red Squirrel]

DNS can't be that complex of a protocol, what is there to mess up? And how can a protocol itself have a security hole? And why did it take so long for them to figure it out? DNS has been around for what, 20 years? it seems most articles are trying to hide something so I'm guessing there's more to it then what I'm catching.

I am running my DNS in a chroot jail as that seems to be the default (never seen it run in a different way) though that does not mean I'm safe right? AS the hack is through the DNS port itself?

AS for which version I believe it's 5.2 but not 100% sure. That's what uname -a shows: 2.6.18-53.el5 #1 SMP Mon Nov 12 02:22:48 EST 2007 i686 i686 i386 GNU/Linux

As for dig:

; <<>> DiG 9.3.4-P1 <<>>
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 55787
;; flags: qr rd ra; QUERY: 1, ANSWER: 13, AUTHORITY: 0, ADDITIONAL: 14

;; QUESTION SECTION:
;. IN NS

;; ANSWER SECTION:
. 509289 IN NS M.ROOT-SERVERS.NET.
. 509289 IN NS A.ROOT-SERVERS.NET.
. 509289 IN NS B.ROOT-SERVERS.NET.
. 509289 IN NS C.ROOT-SERVERS.NET.
. 509289 IN NS D.ROOT-SERVERS.NET.
. 509289 IN NS E.ROOT-SERVERS.NET.
. 509289 IN NS F.ROOT-SERVERS.NET.
. 509289 IN NS G.ROOT-SERVERS.NET.
. 509289 IN NS H.ROOT-SERVERS.NET.
. 509289 IN NS I.ROOT-SERVERS.NET.
. 509289 IN NS J.ROOT-SERVERS.NET.
. 509289 IN NS K.ROOT-SERVERS.NET.
. 509289 IN NS L.ROOT-SERVERS.NET.

;; ADDITIONAL SECTION:
A.ROOT-SERVERS.NET. 164805 IN A 198.41.0.4
A.ROOT-SERVERS.NET. 595690 IN AAAA 2001:503:ba3e::2:30
B.ROOT-SERVERS.NET. 602464 IN A 192.228.79.201
C.ROOT-SERVERS.NET. 164805 IN A 192.33.4.12
D.ROOT-SERVERS.NET. 602464 IN A 128.8.10.90
E.ROOT-SERVERS.NET. 602464 IN A 192.203.230.10
F.ROOT-SERVERS.NET. 602464 IN A 192.5.5.241
F.ROOT-SERVERS.NET. 595690 IN AAAA 2001:500:2f::f
G.ROOT-SERVERS.NET. 602464 IN A 192.112.36.4
H.ROOT-SERVERS.NET. 597783 IN A 128.63.2.53
H.ROOT-SERVERS.NET. 595690 IN AAAA 2001:500:1::803f:235
I.ROOT-SERVERS.NET. 602464 IN A 192.36.148.17
J.ROOT-SERVERS.NET. 164805 IN A 192.58.128.30
J.ROOT-SERVERS.NET. 164805 IN AAAA 2001:503:c27::2:30

;; Query time: 3 msec

 

[Red Squirrel]

I used lynx from my server and used one of those sites that test and looks like I'm safe, so thats good to know.

I'm very surprised I have yet to run into sites that have been redirected though, as this is such an easy exploit from the sound of it.

 

[Red Squirrel]

Here we go.... http://news.bbc.co.uk/1/hi/technology/7525206.stm this is gonna be a ride.

This should get real interesting. I'm guessing the major sites have already patched so sites like google.com and bank sites should be safe... hopefully.

 

[Nothinman]

And how can a protocol itself have a security hole?

Easy, just look at telnet. The fact that your password is sent in clear-text is considered a security hole these days.

And why did it take so long for them to figure it out?

Because it's working as designed and no one thought about it that way until now. Same thing with telnet, for years it was fine because so few people were on the Internet so it was a much more trusting environment. It's not like you noticed it either.

DNS has been around for what, 20 years? it seems most articles are trying to hide something so I'm guessing there's more to it then what I'm catching.

They're being vague because it affects such a core part of the Internet and they want to give people time to patch before exploits start happening. It's annoying but I can understand why they're doing it.

I am running my DNS in a chroot jail as that seems to be the default (never seen it run in a different way) though that does not mean I'm safe right? AS the hack is through the DNS port itself?

Correct, this has nothing to do with someone accessing your system via bind so how it's run on your machine is irrelevant.

AS for which version I believe it's 5.2 but not 100% sure. That's what uname -a shows: 2.6.18-53.el5 #1 SMP Mon Nov 12 02:22:48 EST 2007 i686 i686 i386 GNU/Linux

uname shows the kernel version, not the distribution version.

This should get real interesting. I'm guessing the major sites have already patched so sites like google.com and bank sites should be safe... hopefully.

This isn't something that website owners can fix, if the DNS servers you're using get attacked you're screwed no matter what Google does.

 

[Red Squirrel]

Well assuming big sites like google are using their own then they have to patch or if the authoritative servers get hacked then it will just make its way down all the cache servers regardless of if they are patched or not. so the authoritative servers are most important to patch. Ex: mine is ns1.iceteks.net. if that server gets hacked then all my sites can point somewhere else so its important to patch it. Though I suppose I could chmod my DNS records as like 400 or something and I should be good. (owned by user named)

 

[Crusty]

Originally posted by: RedSquirrel
Well assuming big sites like google are using their own then they have to patch or if the authoritative servers get hacked then it will just make its way down all the cache servers regardless of if they are patched or not. so the authoritative servers are most important to patch. Ex: mine is ns1.iceteks.net. if that server gets hacked then all my sites can point somewhere else so its important to patch it. Though I suppose I could chmod my DNS records as like 400 or something and I should be good. (owned by user named)

You're not understanding the exploit. There is nothing you can do if a user of your site is using an unpatched DNS server. Even if your server is returning the correct records, the unpatched server that someone is using can still return a poisoned record.

 

[Red Squirrel]

Yeah but I don't operate those servers so I just have to hope the others fix it. But I'm concerned about mine and am responsible to fix it. Authoritative servers are more important as if they do get hacked then the results will propagate.

 

[Crusty]

Originally posted by: RedSquirrel
Yeah but I don't operate those servers so I just have to hope the others fix it. But I'm concerned about mine and am responsible to fix it. Authoritative servers are more important as if they do get hacked then the results will propagate.

Servers that are not patched are not 'hackable' in the sense you are thinking. From the information I've seen about the exploit it's similar to a man in middle attack. The only way for someone to be affected by this exploit is if the server they are using for dns lookups is not patched, then it's possible for the end user to receive invalid records from their request, but it's not because someone hacked the server and changed the records, it's because you are fooled into thinking the response you got back is actually from the server you requested it from.

 

[Nothinman]

Google will have their own servers to patch for their users, but the exploit is aimed at users and not servers so you need to worry about your DNS servers and whatever DNS servers you're trusting upstream.

Though I suppose I could chmod my DNS records as like 400 or something and I should be good. (owned by user named)

No, the attack affects your DNS cache which is only in memory. Unless there's an aspect of it that I haven't seen talked about it only affects requests for domains other than what you're authoritative for.

 

[Red Squirrel]

Well as a precaution I removed write rights to the named data. No reason the server would need to write to it anyway.
The details of the exploit seem to be lacking of detail so its really hard to tell at this point what's going on. I'm looking forward to the full details when they come out at the Blackhat Conference.