Defeating Virtual Keyboards and Phishing Banks

An anonymous reader writes "Noam Rathaus writes on the SecuriTeam Blogs how most Image Click-Me virtual keyboards schemes used by banks to fight phishing trojan horses can be easily broken, even (and especially) when encryption is used. He then discusses how screenshots of the pointer location are over-kill, and describes how to kick these security measures out of the way." From the article: "Instead of sending the remote image and waiting for the key-stroke information to be sent back to the server (the technique which the screenshots for pointer location on-click described above was used) some banks send the PIN number in cleartext, while others encrypt them, one such example is cajamurcia. Even when the encryption is used, banks tend to implement it badly making it easy to recover the PIN number from the encrypted form. I investigated a bit more on how cajamurcia handles such PIN strokes (with virtual keyboards) and I noticed something strange, they take the timestamp of their server (cajamurcia) and send it to you - this already posses a security problem - and this timestamp is then used to encrypt the PIN number you entered"

Comments

dumb

[Lehk228]

the whole idea is dum, you are trying to make a compromised host somehow "Safe" by obscuring what is going on. if they wanted to be really safe they would use a trusted device and allow the computer to simply be one more untrust part of the cloud between that device and the bank. a USB "smart card" could do the trick just fine. for added security have a pin pad on the smart card itself.

Re:dumb

[arivanov]

Ahem. Exactly.

Client side x509 certificates (if possible on smartcards or tokens) will solve 99% of phising problems once and for all. For most "secure" sites, the clients authenticate the server (which can often be circumvented by using DNS tricks). At the same time there is no SSL level client authentication. As a result stolen credentials can be reused on another system. A smartcard holding the x509 cert prevents this outright.

Unfortunately instead of using what is right there in front of them in the actual protocol spec the banks go into all kinds of technological roccocco. Not surprising actually. I tried to explain the concept of client side certificate to one of my collegues who had in the past implemented the internet banking system (and its security) for one well known UK bank and is now to implement another one. No matter how hard I tried, he could not grasp the concept.

Re:dumb

[mochan_s]

Phone trojans are extremely rare

Doesn't mean they always will be.

Re:dumb

[swillden]

I've been in the business of designing, implementing and selling smart card-based security solutions for nearly a decade now, and I've talked to lots of banks about these issues. Most of them understand perfectly well that smart cards with client-side digital certificates are an excellent (though not perfect, see below) solution from a security standpoint. The reasons they aren't gung ho about deploying such a solution are (1) cost and (2) consumer acceptance.

Smart cards themselves aren't expensive, and neither are smart card readers. The cost of retooling the card issuance process to support smart cards, however, is non-trivial, and the cost of deploying card readers to consumers and supporting them through the installation and usage process is very large. The biggest problem, though, is cardholder training. How do you teach millions of people how to use the thing, even if it's already set up on their machine? Simple problems like how to insert the card into the reader are surprisingly hard to address on a large scale.

The UK, and a few other countries, are much more prepared for this than the US thanks to the Chip & PIN initiative that their banks have spent tens of millions on. At least UK citizens know to put the card in chip-end first, with the chip up.

In any case, though, it's the cost and difficulty of getting consumers to deploy additional hardware on their computers that holds banks back from doing it, not lack of understanding. All of their weird security solutions are attempts to perform semi-secure transactions on the PC hardware that the cardholders already have, with no new software or hardware to install or maintain. Note that the costs and difficulties I'm talking about aren't theoretical. Various banks in different parts of the world have run pilots using these technologies, and they've invariably fallen flat. IMO that's because the pilots were poorly run, but having seen the failures, banks are very leery of trying anything else.

The new buzzword that's sweeping the financial industry these days is Near-Field Communications (NFC). NFC is basically a contactless smart card chip embedded in your cellphone. The chip can securely store and use keys, and the interface with the phone provides it with a display, keypad and Internet connection so the chip can phone home to the issuing bank as needed (for velocity checking, balance checking, etc.). Assuming the phone can be protected from viruses, trojans, etc., and can be considered a relatively secure device, this has all sorts of advantages. It can be used in a retail environment with a contactless smart card reader, using the phone's display and keypad to give the user a chance to verify the transaction details (the amount, mainly) on a device the user trusts. For on-line usage, you can connect the phone to the PC via USB, or via a contactless smart card reader for secure and easy transaction, but it's more likely that you'd use the phone's data link for the financial transaction. Imagine going to amazon, picking out your goods, hitting the "buy now" button and then waiting a few seconds for a message to arrive to your phone, requesting payment authorization. You'd review the transaction details on your phone screen, authorize payment with the keypad, and the smart card chip would then create a cryptographically-secure payment authorization message and deliver it to either the bank or the merchant (depending on how the system was structured).

What's actually going to happen? After failing repeatedly over the years in my prognostications, I won't even guess. I will say, though, that banks are big fans of "good enough", and that their definition of "good enough" doesn't require that fraud be impossible, only that it be sufficiently limited that it's affordable.

Yeah, and?

[iamdrscience]

So the article is saying that people with trojans on their computers are fucked? Is anyone surprised by this? The point of virtual keyboards is not to defend against trojans, it's to defend against keyloggers. They may defend against trojans that try to steal your account information with a keylogger, but I think it's safe to say that no matter what security technology your bank is using, if you've got a trojan on your computer you're going to be fucked.

just go to the bank....oh wait

[ILuvRamen]

I'd say just go visit the bank in person, it's probably right down the street, but of course it's not open. I don't care what type of bank it is, it's not open right now. Why? Because you're home and not at work, probably cuz it's a weekend. If banks really wanted to improve security, they'd actually be open at usefull times so you wouldn't have to rely on web services. But I guess that's all you can expect from a business where the less customers stop in, the more money they save (in staffing etc). I have another great idea too. On the applications for web banking services, they could have an area where it says "I hereby swear that I am not a complete dumbass when it comes to passwords. It is not a. my last name, b. something I tell everyone, or c. on a sticky note on my monitor." That would get rid of at least half of the major security problems.

Is it just me? Am I missing something?

[zappepcs]

If your pc is infected with a trojan, or other malicious software, its feasible to capture the screen with each keystroke while connecting to a bank website and forward that data to a server somewhere at a later time... key logging doesn't have to be only key logging, it could be logging keystrokes and relevant screen data at the same time.

The ONLY way to outsmart software that wants your data is to not load that software on your machine. I find that I feel much safer booting a life CD (DSL or Puppy or pick your flavor) and running to the banking website with a freshly installed OS... no chances for virii or malware etc.

That is certainly easier than actually going to the bank... and I know that its safe.

It at least makes me feel a bit safer.

Re:Virtual Keyboards are pointless

[iamdrscience]

Virtual keyboards are designed to protect against keyloggers, not phishers, and they do a pretty good job. No one technology protects all fronts of attack -- saying virtual keyboards are useless because users can still be phished is like saying that encrypting data between you and a bank is useless because it doesn't protect you from somebody looking over your shoulder.

Re:Virtual Keyboards are pointless

[Anonymous Coward]

The danger in this situation is not a man-between-client-and-server, it's a compromised client (a true man-in-the-middle). A trojaned client (software, hardware keylogger, graphical logger) is just that. There are two techniques for dealing with it:
1) classic cryptography: The human user uses Ke(M) = C, such that the trojan never sees M. That mapping would have to take place before M even reached the (untrusted!) keyboard or mouse. Usable or cryptographically secure, but not both.
2) obscurity: As someone mentioned tangentially earlier, randomly generating a computationally obscure keypad (thus a random mapping of the mouse clicks to the machine representation) would at least force the trojan (or remote recipient of its output) to perform image recognition either automatically or manually in order to recover the mapping. And that's before you prudently pubcrypted the PIN for transmission, of course. Enter the captchas,; it becomes exactly the same problem at that point. Note that biometrics and even one-time-pads would (obviously!) be defeated by a compromised client's reading the cleartext.

This application absolutely screams "public key encryption" and it's baffling that they don't use it. The whole point is that even if the attacker knows the encryption key, the system remains cryptographically secure. Gah. It's just a matter choosing to implement that instead of CLEARTEXT! Validating the PIN on the (untrusted!) client is a bad idea; it must be done on the server, or there is no secret kept by the server. Fortunately, there's a nice technological solution to this problem.

A true man-in-the-middle is an absolute bear. It is, quite literally, physical access: the ability to examine the machine's state locally, before encryption. That's not a technological problem; it's a social problem. Someone looking over your shoulder? Physical access; a social problem.

The use of cleartext just flabbergasts me. Even an incredibly unsophisticated attack can still reveal cleartext! That makes it a bigger hole to plug, and to boot it is a much easier one to plug.

Have a split PIN system

[caluml]

Have a split PIN system - half in your head, and a random second half texted to your phone, which is valid for 5 minutes after it is texted. Voila. And the bonus? Everyone owns one of these "what you have" devices (in the UK at least).