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

"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"

Ah, the fatal flaw, caused by ignorance perhaps, is your erroneous belief that you can rely on DNS to know the "real" site rather than one designed to steal your money.

The bug is real, but the fix doesn't solve the problem you've cited above.

I use OpenDNS for my dns and they seem to be ok. I like the fact I can block sites (protect the wee ones!!)

Pretty quick as well.

...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.

Disable the DNS client service in Service Control Manager (after clearing the cache using ipconfig /flushdns at the command line)

That way. requests go to your ISPs DNS resolver and not to Windows' internal one.

"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.

T-Mobile Uk [mobile broadband] name server currently "appears vulnerable to dns cache poisoning", according to http://www.doxpara.com Dns Checker.

May protect you or me, but do you really think Joe Q Public is going to notice a missing padlock symbol when he goes to put in his online banking details? Or how about I poison Google or BBC (or even TheRegister :) and redirect to a duplicate site which inserts some drive-by code?

(OK, I know, I know, you're using Firefox in text-only mode on SecureBSD, so you're immune - but most folks aren't, which is why this is so potentially dangerous.)

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.

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!

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...

Plusnet seems to not have this flaw. Go plusnet!

Tom, you say "stupid people" deserve to be scammed but most people won't check the padlock. In a perfect world we'd all be computer experts, but if it looks genuine, most people will trust it - there's people out there falling for 419 scams, after all!

I couldn't agree more about the client certs. Something I've been shouting about for a long while. It just makes so much sense to validate both sides of the transaction.

I'm always shocked at how "ordinary users" can get caught out by misunderstandings. I had a friend complain to me that the virus checker I had installed for them had prevented them opening an email attachment. They said they had to unistall the virus checker before they could open the attachment.<gasp>

Change your DNS to OpenDNS.

Much faster and you have the ability to control the sites that you do not want - IE Adservers etc!!

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!

No worries on home broadband, but when I ran the check using Vodafone (IE) mobile internet, I got the following response:

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

All requests came from the following source port: 27597"

So unless Voda is doing something that this tool has not been setup to handle, there might be an issue.

would it be safe, from an 'incompetent ISP end user' view point, to visit sites by IP address instead of name, i.e. http://155.136.80.222 v. http://http://www.rbs.co.uk/

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.

As of 4pm Saturday, Optusnet Cable DNS in Australia has been pwned. Users who use the default DNS provided by Optusnet Cable and attempt to connect to Google's site are redirected to a malware delivery page.

The discussion can be found here, at Whirlpool.

http://forums.whirlpool.net.au/forum-replies.cfm?t=1021320

Note the doxpara website, to check if the DNS has been patched, is currently unavailable.

Regards,

TB

And doxpara came back up too ...

Regards,

TB

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

What have I told you about being a smart arse. You go and one-up everyone with a totally new DNS vuln, but then you have to blab it around to none other than your arch critic and rival - Thomas Ptacek. Who goes and verifies the exploit for someone else. That they probably know. And already Briefed.

I was going to infer two weeks ago that the "telephone" conversation with Ptacek would be like giving a loaded shotgun to a 5 yr. old - but I refrained for professional reasons.

A leopard never changes his spots.

"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. Trust on the internet, as flawed as it may be now, would completely break down."

Assuming bankofamerica.com doesn't use SSL or their browser doesn't bother to tell them the cert doesn't match the IP?

> 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.

Not quite, you need to think bigger.

SSL works by (and forgive me if I oversimplify):

1. Client sends server a list of crypto functions it supports

2. SSL server responds with its digital certificate and the strongest crypto function they have in common.

3. Client validates digital certificate against certificate authority

4. If client satisfied of authenticity, client generates a random number

5. Client encrypts random number (4) using public key inside certificate (2)

6. Client sends encrypted number to server (only server can decrypt)

The question that is really hard to answer is whether step 3 can be reliably done with a compromised DNS server. If they are spoofing the IP address for your banks website, are they able to create a fake certificate and spoof the IP address of the certificate authority?

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

Your comment in the article:

"Earlier this month, Microsoft issued an update patching the vulnerability. It was unclear if other OSes are vulnerable"

is misleading. As Dan Kaminsky said on his blog (http://www.doxpara.com/) on July 9th:

1) It’s a bug in many platforms

2) It’s the exact same bug in many platforms (design bugs, they are a pain)

3) After an enormous and secret effort, we’ve got fixes for all major platforms, all out on the same day.

So other platforms are affected and your comment is incorrect.

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

gg 3 mobile broadband...

Yes true but at least it takes MS' dodgy code out of the equation.

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