Looks like UKOnline/Easynet nameservers (possibly Sky Broadband too?) are still unpatched .. nice

...but couldnt get to it..... Oh!... ermm... oh well! Go Virgin!

^_^

I patched all our nameservers and customers on the day Debian shipped them.

Today I raised a ticket on both our upstream work DNS servers and Eclipse.

Eclipse replied:

Thank you for letting us know.

We are currently aware of this issue. Our entire DNS platform is currently due

for upgrade, And we will be installing measures to prevent exploitation of DNS

protocols.

--EOF--

Whilst it's not too bad, why does it take _so_ long. It's not that difficult - it needs testing on a test environment (which of course they will have) and then rolling out. 2-3 days tops.

"When they typed bankofamerica.com into their browser, they'd have no way of knowing whether they were being directed to the real site or one designed to steal their money."

No way of knowing? Try SSL.

If your bank is relying on DNS to prove their identity for online banking, then it's time to take your cash somewhere else.

"When they typed bankofamerica.com into their browser, they'd have no way of knowing whether they were being directed to the real site or one designed to steal their money"

This is why commercial, sensitive operations take place over SSL/TLS. This is not just to ensure that there is no eavesdropping of your information as it traverses the net, but also to ensure that the server at the other end is trusted, and is who it says it is. It does this by having a certificate, which indicates the site that it purports to be, which is signed by a 'trustworthy' body.

Even if a 'hacker' could hijack a domain name (either by DNS poisoning, or old school social hackery), they would not be able to replicate the trusted, signed certifacte that the real site could offer, and wouldnt be a significant threat.

Honestly, you'd think you would know that, being an IT journo covering security. and not tap out mindless, fear mongering drivel. Has el reg been syndicated by the Daily Fail or something?

And if your ISP's DNS servers are not patched, you're equally as boned.

Paris, boned.

Tom and Chris, what you say is true. However, some users might not notice if they are on an SSL/TLS secured site or not and might enter their information anyway. I believe that most users are now educated when it comes to making sure SSL/TLS is in use, but there must be some that aren't and there *not* being something on the screen might slip past many of them. Hopefully not too many.

This exploit is a pain, as they all are. What really scares me though is how so many banks still require the user to enter the complete password to get in.

Some are better with, "Enter characters 4, 8 and 5" prompts (for example), but I can think of many where people are totally vulnerable to keyloggers. I've seen one which uses drop-down menus which goes a little further to protect against this.

In the end, nothing is secure is it... we just have to do our best to stay ahead of the game and users need to take a bit of responsibility and care. The world needs sysadmins so although this stuff is a pain, at least it keeps us in a job!

Ah, but what you are missing is 1) the people who are going to the site for the first time and are about to hand over all the details required to set up online accounts, and 2) the people who, on seeing a popup saying "the certificate has changed and maybe owned by alien beings and agreeing to this will mean that you give away your first born", will just click "ok" anyway because they don't know any better. This adds up to a significant number of people at risk from this.

It's why SSL/TLS on its own is not really good enough for online banking.

Enough of the FUD, already. The flaw is no different to the many other hypothesised flaws against DNS implementations we've seen, with regard to the RNG; it's just that it's been exploited in a fairly clever way to achieve the same ends. It's media hipe, plain and simple. Nothing changes the fact that non-vulnerable servers are non-vulnerable precisely because their authors and users gave two short craps about the security implications of bad PRNGs. Coincidentally, I just joined bind-users to ask a question about additional section data caching and so learned of this live exploit, because I don't like what I've found about RFC 2181 ranking by default in BIND of additional section response caching. Since this actually is very slightly relevant to this security problem, in that additional section caching is necessary for the exploit to work as it stands (it can be trivially improved to work around it though), I can't wait to get to the bottom of it. In the process, I found this gem in the BIND FAQ:

Q: Is there a bugzilla (or other tool) database that mere mortals can have

(read-only) access to for bind?

A: No. The BIND 9 bug database is kept closed for a number of reasons.

These include, but are not limited to, that the database contains

proprietory information from people reporting bugs. The database has in

the past and may in future contain unfixed bugs which are capable of

bringing down most of the Internet's DNS infrastructure.

The release pages for each version contain up to date lists of bugs

that have been fixed post release. That is as close as we can get to

providing a bug database.

<Sigh.> First the Linux Kernel maintainers, and now the ISC. Seems nobody wants to be honest about security issues in their software. Of course, there's a real risk in exposing innocent people to real vulnerabilities without available patches; but if it's important to do full-disclosure, it's also important to do it properly and so using a bug database and treating security bugs like any old ordinary bug is very silly. Besides, does that make it right to do as has been done here - to pull wool over peoples' eyes? I wonder - how many of those servers would be resistant to the flaw, as compared to now, if Kaminsky and his cohorts had outed the flaw at the moment the patches became widely, generally available, as they have been, for immediate consumption? I'll put money that, even factoring in the laziest admins, the net would be safer than it is now. Panic and exploits, alas, make for an incomplacent admin. Incomplacent admins are valuable things. And detailed security announcements, complete with descriptions of affected software and the means by which the attacks are possible, make for happier ones, who very occasionally can and do apply workarounds while patches are not available.

There. I don't feel much better, but at least it's all out now.

Cheers,

Sabahattin

I've no problem with stupid people losing money through their own stupidity :)

I predict that over the next 5-10 years we will see a marked growth in identity protection and verification. Both users and providers will need clear and unambigous ways of both providing and verifying identities. Establishing trusted relationships between a user and a company will become fine grained, and I would hope that banks may start issueing client certificates to users, before they can start using the online service.

Its similar to how internal services inside company networks now work. 5 years ago, they would be unencrypted, unverifiable raw data, probably in some arbitrary on the wire protocol. Nowadays, they are typically XML, and either requested over a TLS channel set up with both client and server certificate validation, or the XML itself is signed and encrypted with keys that are pre-exchanged to establish trust relationships. The net result is the same - bob is sure that alice actually is alice, and alice knows that only bob can read the message she sent.

This sort of technology isn't new, but it is starting to become much more mainstream. The days of relying on insecure protocols are fast dying out - time for DNSSEC to go mainstream I think, rather than continuing to fix up BIND (although BIND is truly getting much much more secure as time passes, a testament to "many eyes make all bugs shallow".)

There are people using BIND? I thought the DNS protocol alone was crock enough.

Used it once for a few months after Y2K, found it impossibly confusing and sick to configure, had to patch it in a hurry at one point, left it rotting on the sidewalk. Never looked back.

There's another exploit as well, that doesn't require the (admittedly pretty basic) skills needed to install and run Metasploit:

http://www.milw0rm.com/exploits/6123

Gosh, I bet the Apple users are glad they don't have security problems on their platform.

Jolly Roger because before there was the wild west, there was the Spanish Main, and that's where we'll be for the next few weeks...

Here's the text from the test I ran on Tiscali (Homechoice).

"Your name server, at 81.1.113.56, appears vulnerable to DNS Cache Poisoning."

I've just tried speaking to Tiscali support to find out when they are patching. Let's just say that it was not an informative conversation. So now I'm left with an internet service that is useless for anything practical!

I'm on Sky, and the test reports the DNS looks OK. 90.207.242.18

My comment is why is this worse than the general issue with patching.

If I go audit an ISP and discover root comprimises on all their DNS's - as has occured twice in the last 2 weeks, why is this the big issue?

I still do not see basic security in place.

Woosh are open, what a surprise. 202.74.207.10. This is an NZ ISP, so I'll expect a patch in 5 years...

Wont run the DNS check, says the site isn't found

"Your name server, at 195.27.150.138, appears vulnerable to DNS Cache Poisoning."

gg 3 mobile broadband...

What you've said is true but the attack is much simpler...Who actually checks a certificate? All it needs is a good mock up and the good old "lock" icon (showing us that everything is surely fine?) and it's enough to spoof most people who don't bother looking at the certificate.

Even if you did look, how many people would actually be able to determine if it was a real/fake cert?

It's careless on some peoples part but I would suspect most people are probably still caught in change management....groans