E-banking is an interesting target for attackers. The easiest way of stealing money in e-banking is to attack its weakest point – the client.
This article describes, in brief, how to attack client authentication and transaction authorization – the two fundamental security layers in e-banking. It also presents countermeasures and discusses their effectiveness. Finally, it discusses how the risk of stealing client’s money can be reduced.
Let’s assume, that the attacker knows the client’s username and password for their e-banking system. If there was no additional secret used to perform a transaction, the attacker could take a full control of the client’s account. To minimize the risk of stealing the client’s money, two security layers are used. Firstly, the client has to authenticate. If it is done successfully, the client can only view the account. When the client wants to perform a transaction, he needs to deliver another secret to authorize the transaction – the authorization password.
The attacker wants to get high returns on their investment. He needs something scalable to reach this goal. Phishing and malware seem to be a good choice for both client authentications and transaction authorizations.
Phishing can be automated when sent via email. Some people aren’t aware of the risk and the number of victims is proportional to the number of attempts.
Malicious code can be included in an interesting game available for free. People download and install the game together with malware. The game looks fine and people aren’t aware of the risk. They connect later to their e-banking system and this is what the attacker is waiting for.
These are only examples, but they show how a typical e-banking client, that is unaware of the risk, can be attacked.
One may say that there are malware and phishing detection mechanisms that will stop the attackers. The problem is that they detect known attacks (blacklists for phishing and signatures for malware) and try to detect unknown attacks (heuristic approach). That’s why there is no guarantee to detect the attacks. The risk of becoming a victim is reduced, however.
3. Client authentication
When the client wants to get access to the e-banking system, he needs to first authenticate. He connects to a bank via SSL/TLS (HTTPS used instead of HTTP) and gets a digital certificate. The browser doesn’t display a warning, when the certificate is digitally signed by one of the trusted Certificate Authorities (CAs). The client typically enters his username and password to log in to e-banking system. Before it happens, the client should check whether the certificate belongs to the bank he wants to communicate with.
Let’s analyze how phishing and malware can be used to steal the client’s credentials.
Not everyone understands how certificates work. Then, it might be enough to send the clients a link to a domain not protected by SSL/TLS that looks similar to the legitimate one. Some clients will not notice the difference. If they click the link, the attacker will be able to collect their credentials.
Let’s assume that the client always checks whether SSL/TLS is used when communicating with the bank. The attacker might have received a digital certificate signed by one of the trusted CAs for the domain, that looks similar to the legitimate one. Then the client can see that SSL/TLS is used when he connects to the bank and the browser doesn’t display a warning. When the client doesn’t check who the owner of the certificate is, he might reveal the credentials to the attacker.
Masked password are sometimes used when the client is authenticating. The client is asked to enter selected characters of the password. Thus, the attacker needs more attempts to get the entire password, but it doesn’t have to be a problem for him. The attacker can ask the clients to enter the entire password. Some people will probably do what the attacker wants – from their point of view something must have changed recently.
The bank might also share a picture with the client. When the client gets authenticated, he can see this picture. Then the client knows that he is communicating with a bank – the attacker doesn’t know the picture. This way, successful phishing attempts can be detected as long as the client always verifies that the picture appears, when he becomes authenticated. When the picture doesn’t appear, the client knows that something is wrong. He should then connect to the legitimate e-banking system immediately and change the password.
It’s assumed in this section that the client’s machine got infected.
It doesn’t help when the client knows how certificates work. Everything is fine from the client’s point of view – the bank’s certificate is digitally signed by one of the trusted CAs and the client checks that it belongs to the bank he wants to communicate with. But the malware is able to learn the password when it is being entered on the website.
Shared pictures between the bank and the client also doesn’t help. The client logs in and the picture appears. The client isn’t aware that the malware learned the password when he was authenticating.
Masked passwords also aren’t a problem for malware – it can silently analyze subsequent log-in attempts to learn the entire password.
The on-screen keyboard is sometimes used to prevent keystroke logging. But it doesn’t prevent the malware form learning the client’s password – the malware is able to capture screenshots with mouse positions.
4. Transaction authorization
Let’s analyze how phishing and malware can be used to steal the authorization passwords.
Let’s assume that the client has a list of printed one-time passwords (OTPs). He is asked to enter the password from the list to authorize the transaction. When the password has already been used, it is useless for the attacker. That’s why it is better than a static password, but doesn’t stop the attacker. The OTPs are not related with the transaction details. That’s why the attacker can use phishing techniques to get several OTPs and perform arbitrary transactions. When phishing is used, the client might be informed that the bank introduced new security mechanism and the client is required to prove his identity – he is asked to enter, for example, three OTPs. Some people will probably do what the attacker wants – from their point of view the bank improves security.
A token can also be used to generate the OTPs. It could have a clock synchronized with the authorization server and share a secret with the server. The token is used to create authorization passwords valid for a certain time, for example, 60 seconds. This is better than the list of one-time passwords because when the attacker gets this password, he can use it only within a short period of time. In addition, the attacker can’t perform multiple transactions if there is only one transaction allowed in this time range. But the problem is still the OTP not related with transaction details – phishing is possible.
It’s assumed in this section that the client’s machine got infected.
The client wants to perform a transaction. He enters transaction details and is asked to provide the authorization password. Let’s assume that the password is not related with transaction details (for example, the OTP is generated by a token). The client enters the password and authorizes the transaction. But before it is sent to the bank, the attacker changes the data; for example, the destination account. This is the man-in-the-browser attack (MITB).
Let’s assume, that the client enters the transaction details and is asked to provide the authorization password that is related with the transaction. The authorization password is sent by the bank to the client’s machine, together with the transaction details. When this is a case, the MITB attack can still be used to change the destination account. The attacker knows what transaction the client wants to perform and displays the transaction details expected by the client instead of the ones received from the bank. From the client’s point of view everything is fine – he authorizes the transaction.
Let’s discuss this case; when the client’s machine is used to access an e-banking system and a mobile device is used for transaction verification (An SMS is sent to the client’s mobile with the transaction details and the authorization password). Now the client can verify the transaction even if his machine is compromised. It works fine as long as the attacker doesn’t infect the client’s phone. Let’s assume, that the client logs in to the bank account. Then the malware can display the massage that the bank introduced new security mechanisms – the client has to download the certificate to his mobile phone. Everything looks fine for the client. He is asked to enter the phone number. The client gets the SMS message with a link to a certificate (this is in fact malware). It is downloaded and installed by the client. Now the client’s computer and mobile are controlled by the attacker. The client wants to transfer money. He enters the transaction details and the MITB attack changes the destination account. The authorization password is sent to the client’s mobile with the transaction details. The SMS brings the destination account of the attacker, but the attacker can change it, because he controls the mobile and knows what transaction the client wants to authorize.. From the point of view of the client, everything is fine. The client again authorizes the transaction.
The client can also use modern mobile apps to get an access to e-banking and perform transaction verification. Then it is enough to compromise the mobile.
Two security layers are introduced to reduce the risk of stealing client’s money – client authentication and transaction authorization. When the attacker gets the client’s credentials, he needs another secret to steal the client’s money – the authorization password.
Authorization passwords should be related with transaction details. When this is the case, the attacker can’t perform an arbitrary transaction if he gets the authorization password. Then phishing is useless for the attacker. The problem is still malware, when the client’s machine used for transaction verification, is still compromised. At the first glance, modern smartphones seem to be a good choice for transaction verification – they are ubiquitous and no extra device is needed for this purpose. But they are multifunctional devices and have the same security problems as personal computers. That’s why it’s proposed to use a dedicated device for transaction verification.
A dedicated device could share a secret with the bank and require the client to enter the transaction details. Then it generates the authorization password. This is the only action the dedicated device does – network connectivity, for example is not needed. Thus, the security is improved as a consequence of complexity reduction. Finally, the client enters the password on the website to authorize the transaction. It allows the bank to detect MITB attacks provided that the dedicated device is not compromised. There is a usability problem, however. The client has to enter the transaction details twice (the website and the dedicated device).
The solution might be a dedicated device with a built-in camera that is used to take a picture of the Quick Response (QR) code displayed by the bank. The code includes encrypted transaction details sent by the client and the authorization password related with this transaction. The encryption key is shared by the bank and the dedicated device. That’s why the client can verify the transaction details without entering them on the dedicated device. Moreover, he can extract the authorization password that is entered on the website to authorize the transaction.