That type of attack is a real problem as no consumer-education is every going to fix it. Another worrying quote from the article:

The researchers estimate that as many as 0.4 percent, or 68,000, open-recursive DNS servers are behaving maliciously, returning false answers to DNS queries. They also estimate that another two percent of them provide questionable results

Open DNS servers [webmasterworld.com] have been discussed here in the past. 2.5% of servers wrong, deliberately or otherwise would be pretty worrying though, as (if I understand the DNS system correctly) this could 'spread' to other servers if the numbers and authority of compromised servers reaches a high enough number.

[edited by: Receptional_Andy at 3:30 pm (utc) on Feb. 13, 2008]

There seems to be some confusion here (or maybe it's just me). There are two issues.

1. Corruption of client computers
   
2. Corruption of servers

As Joe Public, we can't do much about issue 2 but there is a possible (and definitive) solution to issue 1 - use a boot CD with browser for all financial actions. A pain in the *** but when one bank goes down this route, the rest will follow. In the meantime, we can create our own - I've already started researching this.

Of course, if the banks provide clean boot CDs, they can burn the IP address of their server onto the CD directly so that would also mitigate the potential of bad servers to get in the way. With custom encryption, that would bolt the door pretty darn tight.

Although this would be a nuisance, the sooner the banks go down this route the better because it will remove the motivation behind most of the hacking and virus writing that goes on.

Kaled.

the sooner the banks go down this route the better

What would stop the bad guys creating their own modified version of the CD?

"From: AnyBank Security <security@phisher.ru>
Subject: AnyBank CD update

Dear Customer,

Urgent update for your AnyBank CD. Download this ISO image [link], burn to CD, and immediately enjoy increased security when accessing your account"

With custom encryption, that would bolt the door pretty darn tight.

This is wrong. Standard scrutinized encryption is the best path forward. Custom (read not scrutinized) encrpytion always fails. Using something like AES is the path forward, not inventing your own.
Take a look at the competition to win AES: extremely bright minds participated, about half of the entries got withdrawn by their creators after the scrutiny of their colleagues pointed out drawbacks.
Most banks do not employ a top-10 crypto-analyst, even Microsoft with all their cash to throw about cannot make a secret encryption algorithm that actually faces the test of time.

Public not custom wins the test of time.
Custom encryption seems to always fail scrutiny by those who know more.

I agree the posts seem to confuse public available DNs servers that for some reason are
a- open
b- not responding witht eh right information

But the real problem is not there. The real problem is those client PC's getting reconfigured.

now banks should by now -come on!- use ssl. A pop=up warnign should be shown by the browser. Well The browser should stop there: no valid SSL cert, no showing of the content. Not a nice accept button that will make ist seem like the certificate is valid (it failed the only important test).

Options like "nspect the certificate" are utterly useless: human cannot validate, if the digital signature is wrong, it's final: wrong, what's still in there is pure informational only.

If we want to aloow self-signed certificates: the path forward is simple: user: please use out of band methods to get the fingerprint of the certificate. Verify youget it from the right source. and enter it here before we proceed.

With the curent attitude of browser crafters, we'll never defend against man in the middle attacks.

And nothing can defend against unreliable clients. Guess we'll need to pull out a few whips to those coding software and make them responsible (read:liable) for what they craft.

Ouch!

Is there any chance that OpenDNS isn't something I should be using?

I'm on a Mac, so I doubt malicious code could change my settings, but I do have a non-standard DNS since I'm not using that of my upstream ISP (which, itself, could be compromised, I guess).

there is a possible (and definitive) solution to issue 1 - use a boot CD with browser for all financial actions

No no no.

The correct solution is to (a) have the browser verify the IP address against the SSL certificate, as swa66 said.

And (b) get the operating system fixed so that the DNS server can't be maliciously changed.

joestern,

Is there any chance that OpenDNS isn't something I should be using?

I'm on a Mac, so I doubt malicious code could change my settings, but I do have a non-standard DNS since I'm not using that of my upstream ISP (which, itself, could be compromised, I guess).

Couple of things here. First, part of what the researchers seem to be talking about is that setting the registry entry on a Windows client machine handling where that client machine should get its DNS resolver information is easy.

Second, Mac clients must also know where to go to find a resolver in order to resolve (translate) DNS names to IP addresses and thus have a configuration setting to do so. Should a hacker want to write code to do the same thing on a Mac (or Linux box), I suspect that would be fairly easy to do too.

Finally, though I don't use OpenDNS because we run our own private resolvers, my guess is if it is a trusted resolver service, the odds are great that using it is just fine.

However, I would also add that your ISP should have a resolver for you to use and arguably that resolver is your best bet unless there is some overwhelming and overriding reason to use another. I have serious reservations about using third party "open resolvers" because it is another point of failure which you have no control over. Were my company not running its own resolvers, I would certainly use my upline ISP's resolvers over any "open resolver" network for one really big reason - accountability.

Keep in mind, it is not the DNS resolver service you are using that is most likely being corrupted, it is the client machine you are on that this article is speaks about which is the biggest threat. So, while it is conceivable that DNS software itself can be compromised (it has happened before), it is something the folks who produce that kind of software tend to be very aware of and even more careful to work hard to avoid. The article even goes on to say "The researchers estimate that there are 17 million open-recursive DNS servers on the internet, the vast majority of which give accurate information.".

In the case of the 68,000 or so "problem" open resolvers, these are malicious machines where an attack on your client's DNS configuration could send you.

Now then, what does one do about such things? First, don't be brain dead and click on every link seen in email messages. Next, use some antivirus software on clients [even Mac clients] (you will sleep a bit better, although keep in mind there is a concept of a "0 day virus" where the antivirus folks may not have caught up with an appropriate definition to identify the problem virus for a day or so, going back to point one, don't be brain dead).

You also might want to periodically check to see if the DNS settings on your machine are pointing toward the expected IP addresses for your upstream DNS resolving servers. If not, that is a pretty big clue that something is up.

While the article seemed to focus on Windows clients (which I think is more than a bit unfair), the major points about DNS seem valid (if not phrased a bit oddly - a virus by any other name...).

FWIW, from an OS perspective, mitigating the problem for any given OS could be as simple as comparing a salted hash value kept "elsewhere" (yes, that's it, elsewhere) against the live value to see if it has been corrupted prior to reaching out to a DNS server. Finding a salted hash in memory would be a quite bit more tricky for an attacker, but even that could be defeated if an attacker is committed to the attack - still it would take a lot of time, allowing an antivirus update time to arrive and discover the problem invader. I think that the attacker would have to be pretty lucky (and have to have way too much time on their hands) to successfully accomplish such an attack on a properly protected client. But I digress...

-Commerce

If the IP address is hard-coded on the CD, you had better be sure the bank keeps their server on the same IP address for the next couple of decades then.

Imagine the problems if the bank had to move to a new IP address and someone else inherits that server... and there's a few million CDs out there for that IP.

Ooops.

OK, some of you think I'm nuts, but I'm not...

1) Users, who are smart enough to burn ISO images (most wouldn't know what one is) are smart enough to not fall for a scam of this sort. Also see Custom Encryption.
2) Custom encryption is required, partly because of issue 1. However, is is also required to ensure the browser will only work with specific servers. The argument that custom encryption is always weak is fallacious - you still use strong /standard algorithms, you simply change details and add a further layer or two or three.

mcavic said

The correct solution is to (a) have the browser verify the IP address against the SSL certificate, as swa66 said.

And (b) get the operating system fixed so that the DNS server can't be maliciously changed.

You need to think this through...
People use the browsers/computers they have. Those browsers may be infected with keyloggers, etc. If banks want people to use secure browsers with certain specifications, they will have to supply them.

As an alternative, it might be possible to design some sort of dongle that plugs into a router (or whatever) but I have my doubts.

Kaled.

People use the browsers/computers they have. Those browsers may be infected with keyloggers, etc.

Yes, keyloggers are a big problem. But booting into a special OS in order to access a banking site isn't an acceptable solution. You don't want to fix a technology problem by circumventing the technology.

it might be possible to design some sort of dongle that plugs into a router (or whatever)

I think that's an excellent idea. Make it a USB key, and offer a cheap 8-port USB hub with it for people who use many different banks. The bank could probably use ActiveX or Java to authenticate the key. I bet you could even make Windows natively support it right now. You could take the key to work with you, etc, etc. You'd still want to have a username/password login too.

booting into a special OS in order to access a banking site isn't an acceptable solution.

I agree, it is certainly not ideal. It might be possible to create a virtualized solution. After booting from CD, Windows or whatever could be loaded too. However, this might be very tricky since normal hardware virtualization would not be appropriate. It should be possible to switch by performing a hibernate-like operation but this would mean switching would be pretty slow (maybe 1 minute depending on memory size and disk speed).

There are other methods banks could use like texting a code to you each time you try to log on. That way, you need to have your mobile phone with you to access your account, but that has severe problems when you go abroad. Handheld authenticating devices are being trialled (and used by some banks) but I have my doubts that they will catch on.

A boot cd should fit onto a mini cd/dvd so it could be pocket-sized.

Kaled.

There are other methods banks could use ...

Many German banks send out "TAN lists" to their customers - these are essentially numbered lists of six-digit numbers, usually 100 or so "TAN numbers" on each list.

When you log in to the bank's website (using a normal username/password combination) and request to make a transaction, the site asks you for one specific number from your list - e.g. "TAN number 64". You look down your list, find the appropriate six digit number, enter it, the bank checks it against what's been issued to you, and the transaction is authorized. You cross that TAN off your list because it's been "used up" and will never be requested again.

Yes, I realise this is a rather low-tech approach, but somehow it really appeals to me. I know a burglar could steal the list, but somehow burglars aren't really my biggest worry as far as on-line banking is concerned :-)

Why don't more banks use this approach, I wonder?

Webdoctor, a spoofer site could easily ask for a TAN number and simply accept any syntactically correct answer. Your security mechanism seems to rely on the user crossing used numbers off the list. My bank uses such numbers, but I've never done any crossing off...

Come to think of it, as an alternative to the paper list they also send out TAN numbers by SMS. That is probably more secure, as spoofers are unlikely to know the number of my mobile phone.

a spoofer site could easily ask for a TAN number and simply accept any syntactically correct answer.

Of couse they could ... but what would the spoofer be able to do with the user's login details but only one TAN number?

When the spoofer logs on to the real bank's site there's only a 1% chance they will be asked for *that particular TAN*, the bank chooses which TAN to ask for, not the user.

Or have I missed something?

Your security mechanism seems to rely on the user crossing used numbers off the list. My bank uses such numbers, but I've never done any crossing off...

As long as the bank knows which TANs have been used, and therefore never requests any of them again, I don't think it matters if the user crosses them off their list or not (?)

Fingerprint scanners would render keyloggers ineffective. An image on the site, which needs to be chosen beforehand (possibly a mug shot of yourself). If the image doesn't match the one you picked, stop what you're doing and call your bank (and perhaps your ISP)! I find this very effective. Instead of the user providing information, the site itself has to provide a verification of some sort. This would be very difficult for a spoofer to duplicate.

As always, we're trotting one step behind the hackers, but I'm confident we will contain this problem before it gets out of hand.

Fingerprint scanners would render keyloggers ineffective...

...err, if a trojan has taken control of your PC, what's to stop it installing drivers for your fingerprint scanner, and stealing the fingerprint data?

Put another way, how do you propose to ensure a secure path for the fingerprint data to make its way from your end of your finger to your bank's servers?

Why don't more banks use this approach, I wonder?

My Dutch bank uses this TAN system as well. You can choose whether you want to receive a list of TAN codes by (regular) mail or you can choose to receive a single TAN code by SMS each time you do a transaction.

/ This system had been broken by spoofed e-mails though. ("Please fill out your username, password and TAN codes in the form below" -- I guess there's little you can do against people that are stupid enough to fill out this type of form)

...err, if a trojan has taken control of your PC, what's to stop it installing drivers for your fingerprint scanner, and stealing the fingerprint data?

Of course that's possible, but I was speaking of keyloggers, since it was specifically mentioned in this thread.

Put another way, how do you propose to ensure a secure path for the fingerprint data to make its way from your end of your finger to your bank's servers?

I can't. It's just another way of making it a little harder for the hackers. As I was saying, we will always be one step behind. It's much more reactive, than proactive to deal with these security issues. I don't have all the answers, and I'm pretty sure there will never be a magic bullet to put a stop to hackers and spoofers, but we can do our best to put as many obstacles in their way as possible. The one's I outlined work quite well, but again, they're only obstacles, not death blows.

I never claimed to have the "end all, be all" solution :)

...could be carried out by a simple piece of code implanted via a malicious website or email attachment, the study said.

The code would change a file in the Windows Registry settings, telling the PC to use the malicious server for all DNS information.

I can't see any "loophole in the the Domain Name System ".
Were those "researchers" serious? There are hundreds of ways for a virus to take control of users' pc's.
It looks more like hacker wannabies inventing the wheel.
What will they conclude next? A "loophole" in the HOSTS file?

I'd say this falls under the category on Another Windows Security Bug. A piece of malicious code in an email should not be able to change the Windows Registry and where your local machine resolves DNS.

I firmly believe that MAC OS, Linux, and whatever else is out there has just as many potential security bugs as Windows. If you're a hacker, are you going to spend hours, days, weeks, months on writing a virus that will affect 3%, or 80% of computer users? Seems pretty obvious to me.

Once Firefox grabs more market share (getting up there), the number of exploits will rival those of Internet Explorer.