Last Updated: 2007-08-15 09:17:58 UTC
by Swa Frantzen (Version: 1)
Winfried wrote in about a story in Dutch about a bank in the Netherlands. The announcement of the bank in English is here: https://www.abnamro.nl/nl/overabnamro/en_internet_crime.html
This bank has -like most European banks- an online banking application for their customers using strong authentication. A hardware based off-line token that requires a pin code and generates a one time password. The juicy part for attackers is however the ability to transfer money to other accounts (even accounts that are abroad).
Now most such banks out in Europe use strong authentication, signing of transactions etc. still it's not safe apparently. So what can go wrong ?
Man in the Middle
The traditional attack against well protected website is to install something in between the client and the server. It will let pass through the authentication, but might change transactions (before they are signed) or add transactions (if they can be done without signing or if they can be grouped and the group signed as one action).
Where can the user detect this? The one warning about a bad SSL certificate. If the user accepts the certificate, all his chances of detecting it become very slim to nonexistent. But we all know at least a dozen websites that do not have proper SSL certificates and as such teach users to accept certificates.
The attacker might show his hand in the process of applying the signature to a transaction, but most people do not always know the string of digits and operators they press on their hardware token are in fact account numbers and amounts of money to be transfered that they are signing. They just see it as numbers to type and get the result back to the website to move on.
Most banking websites I've used (I'm not a customer of ABN AMRO) do not tell or emphasize the meaning and the need to verify what you are signing. And if they allow you to use a temporary storage of transactions that you can sign in one go, it's unlikely you'll have to sign all accounts and amounts individually, so you're signing something (with a non-repudiable signature!) that you cannot verify as you cannot trust what you see from the man in the middle is also what he gave to the real application.
The bottom line is to make sure:
- Have the right hostname (bookmark it)
- Have the https
- Have the little lock
- Have a valid certificate
If you miss any of them ... stop.
Now that man in the middle attack is hardly news, so what's new out there now?
Apparently this bank had a targeted attack against it March and again today. The Trojan was mailed to the victim with instructions to install the software. Obviously such a Trojan can make all the interaction between the user and the remote website unreliable. If the client machine is unreliable every measure described above is insufficient.
It's worse than the man in the middle attack as all the signs of the man in the middle attacker can be completely hidden from the user.
In theory, the Trojan can completely change what the browser shows the user, with whom the users talks, if the SSL certs are valid, what one sees on the screen while signing transactions, the works.
Now the actual Trojan was not yet this advanced it seems, but it's a small step in addition to take and it's not going to get easier for those defending against this type of attackers.
The ABN AMRO attack
Freely translated from the Dutch article for the benefit of a global audience:
Kaspersky is referenced as the source of how the trojan worked (the method of distribution is unconfirmed).
- The malware tracks which websites are visited and passes it on to a hacked server.
- As a https-site is visited, a second stage is downloaded and activated that logs traffic. These logs are also transmitted to the hacked server.
- If the ABN AMRO-website is visited, a third piece of malware is downloaded and activated that specifically attacks their site.
ABN AMRO uses two factor authentication, but it apparently does not make a difference between the codes to log in and those to sign a transaction.
While this does make it easy for the attackers to do their thing, the Trojan could just as well work against much more robust implementations as well.
The third Trojan allows the user try to to log in, but tells the user the attempt failed, sets up a transaction in the real web application and asks the user to try to login again, confirming the transaction it set up behind the scenes.
Kaspersky also has a clean up page should anybody need it (in Dutch again):
Is this the end of strong authentication?
In my opinion absolutely not, but I hope all our readers will think twice before logging in on their online banking from e.g. a cybercafe while on holiday. The strong authentication alone will not defend you from everything.
Similarly I hope people signing transactions actually learn what they are signing and verify it before typing the numbers.
Banks should teach their users to verify what they sign and perhaps need to abandon systems where you can sign multiple transactions in one go or where you can transfer money without signing the transaction. Logging in once again isn't a non-repudiable signature.
Risk management could be used to determine maximum risks the bank is wiling to take in order to achieve ease of use for the customers, but care has to be taken on who takes the risk when technically non-reputable signatures have been used.
As Winfried put it: "nothing of an infected computer can be trusted".
A note to the US based readers and/or people working for US based banks: plain old passwords are much easier to attack than one time passwords and they can be attacked at any time. OTP (one time passwords) significantly raises the bar for an attacker, that it too can be overcome is no reason whatsoever not to make it harder on the attackers.
Swa Frantzen -- NET2S