Security of electronic transactions

Online banking is always the most interesting target for hackers. I have very often wondered what is really the easiest way to steal money from online banking. Well, the easiest way is to attack the weakest point of online banking, namely the customer.

How a hacker thinks and what really interests him

Let us assume that the attacker knows the username and password of the customer through which he logs in to the banking system. In many of these core-banking systems usually there is no such thing as strong validation or it is misinterpreted, so the attacker can take over a user account without too much trouble.

Currently, however, most of the authorities controlling banks in the European Union require the use of strong validation. This directly results from the document entitled “Recommendations for online payment security” which is available from the Polish financial supervision commission (KNF). Usually it is such that the client must first  go through the process of validation and if this is successful, the client can only browse through his or her account. However, to carry out any transaction, the customer must provide the next thing known only to him or her, which is a one-time password for validating transactions.

A phishing attack is usually fully automated and all messages are sent by e-mail. Most people are not aware of the risk involved and open all the messages they get, and the number of victims is directly proportional to the number of attempts. In contrast, a malicious code can even be contained in free software. People just download and install it. The software runs normally, and they are not aware of the risks. After that they connect to an online banking system, and suddenly it turns out that the transfers did not go to the accounts they should have gone too. During the attack the NRB number is simply swapped.. Of course these are only two examples, but most banks are unable to deal with them. Obviously, there are mechanisms for detecting phishing and malware attacks, but these systems have one major drawback. The problem here is that they detect known attacks because they have phishing and malware blacklists. However,  you cannot use them to detect new and unknown types of attacks because they do not have any heuristic concept. Therefore, the solutions available on the market allow you only to partially minimize the risk.

 However, each attacker essentially has one goal and that is  to get the biggest return for the investment. The hacker must come up with a way of attacking, which is scalable up to the maximum, because only in this way can he quickly reach his goal. The ideal way is, of course, phishing attacks and malicious software sharing.

In some banking systems which I have come across, there are also masked passwords in use for customer validation. The customer is then asked to enter selected characters from a password. It seems that this is a problem for the hacker, but really the hacker needs just a few more attempts to guess the password.

In what way does the customer validate?

When a customer goes through the validation process, first he must obtain access to the banking system. Usually, the way it looks is  that the customer connects to the bank using SSL / TLS and is typically using HTTPS instead of HTTP, and a digital certificate is generated. If the certificate is signed by one of three certifying bodies, the browser will not display the warning. Then customer enters their username and password to log into the system. However, before that happens, every customer should verify that the certificate is actually signed by the bank.

Phishing as a tool for stealing customer data.

Most banking customers do not understand how  the certificates work. So, theoretically, it is sufficient to send customers a link that looks like the bank’s website. Most customers will not notice any difference, even if it appears as a normal login to the site which is outside the SSL.

Now, suppose that the customer checks whether the certificate is actually used for communications with a bank. The hacker can then simply purchase a trusted certificate and create a site that is a perfect operational copy. Then the electronic banking customer is usually fooled, because the SSL is up and running, and the site looks like a real bank site. If the customer does not check to see who really owns the certificate, it may be that the hacker will steal data.

In some banking systems which I have come across, there are also masked passwords in use for customer validation. The customer is then asked to enter selected characters from a password. It seems that this is a problem for the hacker, but really the hacker needs just a few more attempts to guess the password. And even if he is lazy, obtaining passwords is not a problem for him. The hacker simply asks the customer to enter the entire password. Most people do, of course, what the attacker request, because they recognize that the bank has simply changed something.

The ideal solution for banking systems is the possibility requiring the customer to provide photographs when signing the contract. The solution should be designed in such a way that if you log on to the Internet banking system,  you will see your photo, which shows that it is you that is actually communicating with the electronic banking system. The attacker certainly does not know what image the customer has provided  the bank with. In this way, it can be detected by most phishing attacks because the customer can check whether this is the real picture. If the image does not appear, you can begin to suspect that you are the victim of a phishing attack. If this happens, you should call the bank or connect to the real Internet banking system and immediately change your password.

Malicious software and the customer guarantee

Now, suppose that the customer has contracted the malware. Then it does not help that the customer knows how to operate the certificates because, as far as the customer is concerned,  everything is in order. The certificate is digitally signed by one of the trusted CAs, and the customer has proven that it actually logs in to the appropriate bank. Malicious software that is written today is able to learn a password that is applied when logging onto the bank. Even masked passwords do not help, because the software learns them and discretely analyzes every attempt to enter a password.

Photo or other data that the client is able to provide the bank also does not help. The customer logs on the bank website and the actual data appears. However, the customer’s computer is running malicious software, and he is not aware of this. Very often, some banks also use the on-screen keyboard. Nevertheless, that does not bother the malware discovering the customer password. An interesting fact that  I want to give you is that malware is able to capture and send screen shots, relying on the position of the mouse cursor.

Internet transactions

I have already gone through an attack on customer surety. Now let’s get more of your critical components, such as transactions. Of course, Internet transactions are also defined in the KNF document. Each transaction site should be strongly validated. This means that it must be confirmed by two independent means of communication with the customer. Frequently a one-time code or SMS is used. Sometimes, however, banks use hardware tokens. Let us now consider how malicious software deals with this .

A phishing attack on banking transactions

Suppose that the customer has a list of one-time passwords (OTPs). It is usually prompted for a password from the list to validate transactions. When a password is used, it does not make any sense for the attacker. Therefore, it is much better than static passwords, but does not stop attacking for a long time. In the case of one-time passwords (OTP), it is not in any way associated with the banking transaction. That is why the prime objective of a hacker attack is aimed at gaining a few OTP passwords, through which he can carry out any action. For example, such a situation may arise that an attacker will require the customer to enter 3-5 OTP codes, on the ground that the bank has changed its security mechanism and asks the user to enter several passwords for identity verification. Some people will, of course, do what the attackers expected of them because, as far as they are concerned, the bank simply increases security..
Of course, the OTP token can immediately be used for code generation. Token can have your timer, synchronized with the banking system and during a crucial 60 – 120 seconds. This is definitely a better solution than generating and printing an OTP list, because when the attacker take over the password, he has a limited field of activity. Additionally, in such a case, the attacker cannot carry out many activities, and only one. However, all this only reduces the risks associated with phishing attempts and an attack is still possible.

Malicious software attacks to carry out banking transactions

Again we must assume that the customer’s device has been infected with malware. The customer wants to carry out the transaction and is prompted for password validation. We have to assume that passwords are not affiliated in any way with the details of the transaction. The customer enters the password and authorizes the transaction. This seems to be safe but, in the meantime, the malware changes your bank account number. That what a  ‘Man in the Browser’ attack looks like..
Let us assume that a bank customer enters the details of the transaction and will be asked for a password which is associated with the transaction. Transaction validation is sent to the customer’s computer together with details of the transaction. Even so, a ‘man in the browser’  attack is possible all the time. The attacker knows what the customer wanted to carry out and displays the correct data transactions, while in the browser’s memory, it is carrying out its operations. From the customer’s perspective everything is correct, so he validates the transaction.
And now it’s time for the last point. Suppose that the customer device is used to access the electronic banking system and uses the phone to authorize all transactions, for example by an SMS with a token that is sent for the transaction. This of course works well as long as the attacker does not infect the customer. Suppose that a customer logs onto the electronic banking system, and the system displays a message that the rules have changed and the bank has introduced new security mechanisms, the customer must download a new safety certificate to his mobile phone. Of course, everything looks fine as far as the customer is concerned. Then the customer is asked to enter the phone number and receives a message with a link to the certificate, which is then installed on the customer’s phone. Now the attacker has control of your computer and your mobile phone customer. A bank customer wants to transfer money, gets a confirmation SMS along with a token, but details of the transaction have been changed by malware and everything is order for the customer. Additionally, online banking customers often use mobile applications giving access to electronic banking and allowing the transaction. It is sufficient to threaten the security of online transactions.

Summary

Banks typically use two independent channels of transaction validation in order to reduce the risk of theft of the customer’s money. Even if an attacker manages to take over the customer’s credentials, usually it requires data from the second validation channel  to carry out an electronic transaction.
All generated tokens should not be in any way associated with the transaction data. When that is the case, even if the attacker has taken the token , he cannot carry out any number of operations, but only one single operation. And suddenly a phishing attack becomes unusable for the attacker. The problem is malware. If only one device is used or if there is only one channel transaction validation, then each banking transaction has a very high degree of risk. Transaction Confirmation with an SMS message seems to be a good idea of course, but the same problems exist as in the case of normal computers.
Therefore, banks usually propose their customers a dedicated device for transaction verification. The ideal solution at the moment is for the customer to have a dedicated device that shows the details of transactions. However, an additional Internet connection or power outlet for such solutions is usually necessary . Such solutions allow you to quickly capture ‘man in the browser’ attacks, but there is the problem usability. The customer must enter all approvals twice.
The solution may be a dedicated device with a built-in camera that will be used to scan QR codes displayed on the computer screen. The QR code will contain all the transaction data and will be immediately available to the customer. As a result, after scanning the QR code, the customer will be able to immediately verify the details of the transaction and other information. The encryption key must be shared by the bank and a dedicated device, which will ensure full security of electronic transactions.

Przeczytaj ten artykuł w wersji polskiej: http://www.businessmantoday.org/bezpieczenstwo-t…-elektronicznych/

Zapisz