?

Log in

No account? Create an account

Online banking - John C. Kirk

Mar. 3rd, 2010

09:33 pm - Online banking

Previous Entry Share Next Entry

Comments:

[User Picture]
From:johnckirk
Date:March 4th, 2010 02:12 am (UTC)
(Link)
Following up on my previous comment, it occurs to me that I may not be explaining this very clearly. So, I've set up a demo website to demonstrate the risk. (I apologise in advance if this sounds patronising.)

1. On your PC, modify the HOSTS file to add this line:
88.202.220.227 www.co-operativebank.co.uk
(That's my static IP address at home - please don't report me for running a phishing site!)

2. In your web browser, go to:
http://www.co-operativebank.co.uk/
(You can use your existing bookmark for this.) You should now be looking at the fake copy on my server, although it should look identical to the real site, including the real name in the address bar at the top. However, I haven't bothered to copy all the pages, so if you click "Current accounts" then you'll get a 404 error. (This will also confirm that you're on the fake site.)

(I've tested this from my home PC, and verified that I see the fake site. I haven't tried it from an external PC, so if this doesn't work then I'll need to tweak the firewall.)

3. Click the "Banking login" button (or the "Personal login" button in the drop down menu). This will take you to my fake version of the login page, but it is a secure connection with a genuine SSL certificate, so you'll see the padlock. (Since I'm not completely Evil, I haven't implemented the "OK" button, but there's no point in entering your details anyway.)

4. Close your browser, modify your HOSTS file again, and remove the line you added earlier.

So, here's the big question: would you have noticed anything suspicious about that login page if I hadn't warned you? How about the average user?

In this case, there's not much risk to you, because this demo relies on you mangling your own config file. However, suppose that I was corrupt. I could then go round to the PCs at work, and use my admin powers to modify their HOSTS files. Or, more simply, I could just reconfigure our DNS server, to affect everyone at once. That way, the next time someone used their office PC to do internet banking, I'd be able to steal all their money. I personally wouldn't do that, but what if someone else could guess my password? Or what if someone at our ISP is corrupt, and they modify their DNS records?

(I should point out that I'm not trying to say "my bank's the best" - I'm currently with Lloyds TSB, who I've put in the "bad" category.)

Anyway, hopefully this makes some sense, so you can see why I think the Co-op method is bad (even if you disagree with me).

Edited at 2010-03-04 02:24 am (UTC)
(Reply) (Parent) (Thread)
[User Picture]
From:gaspodog
Date:March 4th, 2010 11:54 am (UTC)
(Link)
The main problem here though is that if you've been infected with a virus which can modify your HOSTS file, then it's already managed to acquire root privileges. At this point, it can pretty much do what it wants - track your web usage, log your keystrokes, scrape the screen each time you log in to internet banking and build up you password over successive logins (getting around the "enter characters 1, 5, and 7 of your password" approach the sensible banks use).

The key user behaviour to reinforce in this instance is the installation of good antivirus software from a reputable supplier. Microsoft's Security Essentials is a pretty decent package which is completely free and very simple to use.

If your DNS has been poisoned further upstream, then there's not a lot you can do - assuming the fake site is a faithful facsimile of the real one. As you've noted, the phishing sites all have security certificates now, so they get the little padlock many users have been trained into associating with security. EV is a step beyond this, but it's surely only a matter of time before this method falls over in some way and we move on to the next. The technological aspects of the fraud are going to evolve in step with the countermeasures - the only constant here is user behaviour, and good practice in this regard remains pretty much the same regardless of the specific technology involved:

- Use strong passwords and don't share them with anybody else.
- Preferably use a different password for each service. At the very least your online banking password should be unique.
- Install antivirus software and keep it up to date (if using Windows).
- Delete unsolicited email - and at the very least never click links in said email.
- Be observant - keep an eye out for suspicious activity on your account, and if you're in any doubt about a transaction, call your bank.
Optionally:
- Don't use IE
- Don't use Windows

On the bank's side, they can help by doing the following:
- Educating their users at every opportunity.
- Never ask for entry of a complete password (NatWest do this, Bank of Scotland don't)
- Use 2-factor authentication for any money transfers out of accounts. (most do this with their 'card reader' devices now)

If banks do all of these things, it will help, but it's safe to assume any security feature they come up with will be broken at some point. It at least discourages more casual / less competent phishing strategies though.

If users learn and keep in mind all the things stated above, then it becomes an awful lot harder to be defrauded. Never assume you won't be though - complacency is the criminal's best friend.
(Reply) (Parent) (Thread)
[User Picture]
From:susannahf
Date:March 4th, 2010 12:08 pm (UTC)
(Link)
That all sounds like very sensible advice

Incidentally - you mention 2-factor authentication. When I use this to verify transactions with the Co-op, they always remind me to do an extra check step. The way their system works is that once you've entered your pin on the card reader, it asks you for a numerical transaction code, and then it provides you with a response to this, which you enter on the website. So the co-op website gives you the transaction code, and you give back the response.
The last 4 digits of the transaction code *always* correspond to the last 4 digits of the recipient's account number. Now, theoretically, I shouldn't have to check this, right? Because I'm using the co-op's site and they are giving me all this data. But what if there was a man-in-the-middle attack that was feeding me data from the co-op but then, when I try to make a transaction, changing the destination of the money? Everything would look OK except that those 4 digits would almost certainly not match. And I would go "eeep", cancel the transaction, and phone them up. And even if the scammers were clever enough to remove that code from the html they served me, all the many times I've used the system have trained me to check this number, because it's highlighted as a really important step each time (including what to do if they don't match).

The power of user edumacation.
(Reply) (Parent) (Thread)
[User Picture]
From:susannahf
Date:March 4th, 2010 12:13 pm (UTC)
(Link)
Re-reading, when I refer to removing "that code", what I mean is the code that goes "oi check that those numbers match THIS IS REALLY REALLY IMPORTANT, if they don't match then don't enter anything and call us on this number NOW!"
(Reply) (Parent) (Thread)
[User Picture]
From:johnckirk
Date:March 4th, 2010 08:02 pm (UTC)
(Link)
That sounds useful - I don't have 2-factor authentication with Lloyds TSB, so if someone intercepted my passwords then they could do as many transactions as they liked.
(Reply) (Parent) (Thread)
[User Picture]
From:johnckirk
Date:March 4th, 2010 07:54 pm (UTC)
(Link)
Yes, that's a fair point about the HOSTS file; if your system has been compromised then you're in big trouble.

Regarding upstream DNS poisoning, I think that this is where certificates are really valuable. Back in 2005, I wrote about code signing certificates, and I said:

"Basically, before you run an application, there are two questions you should ask:

a) Do I trust the person/company who wrote it?

b) Am I sure that they did actually write it (and that nobody has tampered with it since)?

Code signing only addresses the second question, not the first. So, it's just a part of the overall solution, but it is a necessary part."


For websites, there are two similar questions:
1) Is the domain name correct?
2) Does it have an SSL certificate (i.e. is there a padlock)?

I've now got my fake website demo up and running, which involves two pages:

1) The main website:
http://www.co-operativebank.co.uk/
This has the correct domain name, but no certificate.

2) The login page:
https://jck.golgotha.org.uk/Coop/login.html
This has a certificate, but it's the wrong domain name.

I can't get a certificate for the Co-op's domain. I could create one for myself, but it wouldn't be issued by a trusted CA, so this would display a warning message when anyone tried to access the site.

So, the ideal scenario is that you should go to the bank's website (by typing the URL or using a bookmark), and that initial "landing page" should be secured by an SSL certificate. Some banks support that, which is good. Other banks don't, which is bad.

I agree with some of your advice, although we may have to agree to differ on whether Windows is inherently less secure than other OSes :) Regarding anti-virus software, this has the problem of enumerating badness, so it will never provide full protection. In particular, I just wrote a small program to modify the HOSTS file; it has to be run elevated, but my anti-virus software (McAfee VirusScan Enterprise) doesn't complain. This isn't really a virus in the classical sense, since it's not infecting other files. Instead, the program is doing exactly what it's intended to do, and there can be legitimate reasons to modify that file (e.g. during a disaster recovery scenario). Some AV software may use heuristic methods to detect suspicious behaviour, although you then run the risk of false positives. If anyone wants to try it out, I'd be interested to know whether your AV complains.

You can download it from here:
http://www.golgotha.org.uk/livejournal/20100303/Hosts.exe
(17kb, requires .NET framework 2.0).

If you prefer to compile the source yourself, that's here (89 kb):
http://www.golgotha.org.uk/livejournal/20100303/Hosts.zip
(Reply) (Parent) (Thread)