MITB (Man in the Browser) Protection Layers
MITB attacks currently being used by modern banking trojans like URLZone and Zeus/Zbot. Although most modern-day banks have in place various security measures like multi-factor authentication to prevent online theft, based on my last article, we can see that most of these techniques are not enough to prevent MITB attacks. These techniques are mostly there to make the credentials theft difficult, but not impossible.
Today I am going to describe some other techniques (just some random thoughts) that might be used to defend against common MITB attacks.
Disclaimer: Technique #2 as explained below may already be known in the security industry. It is not my intention to take any credit for inventing this technique if it is already known. Let's just critically analyze these techniques and do a cost and benefit analysis.
Before I start explaining these techniques, Let me ask you a question. What is the main reason these banking trojans exist? Simplest and most appropriate answer is 'they want to steal your money'. This means if we somehow make this money stealing impossible then the basic motivation to access your banking assets will go away.
Techniques explaining here are not there to prevent bad guys from accessing your banking accounts. Rather assume that you are infected with some banking/MITB Trojans, your account, all authenticated tokens are fully comprised (how? see my previous article). Is there something which can still protect your money? Yes there is still room for an added anti MITB layer.
Technique # 1 (Secondary Communication Device)
All the money transfer requests should be re-verified using some secondary communication device like user's cellular phone. User should be notified on his cellular phone about the account number and the beneficiary to whom money is being transferred. Bank will not execute the actual transfer unless user replies with an acknowledgment via SMS back to the banking server. Using this, any change in the beneficiary information or money transfers to unknown accounts would raise an alarm, a no from user would fail the unauthorized transaction. It looks a very good technique and some of the modern banks are already using it.
I can only sense two problems with this technique.
Problem 1. Most vulnerable part of this technique is that most banks also offer configuring these cellular phone via online banking, bad isn't it? Like in case of Bank of America, user will have to go through the 'Safety Pass' based authentication in order to change the primary 'Safety Pass' (mostly user's cell phone) device. In my last article I explained how its possible for modern MITB trojans to snatch this 'Safety Pass' . Once attacker is able to change the user cellular phone with its own device, he shouldn't have any problems making authorized transactions.
Solution:
Banks should never offer their users to configure and change their Safety pass devices via online banking. User can either request it over the phone and/or by visiting the bank facility.
Problem 2. Every such protection comes with a level of inconvenience for the end user. Corporate customers involved in making these transaction in bulk might get annoyed with this secondary check. People who often travel abroad might not have access to their cellular phone all the times unless they have roaming turned on. Their might be other cases too but I leave them to reader's own imagination and/or personal experience.
Technique # 2 ( Random Keyboard)
This second technique doesn't need a secondary communication device for checking the integrity of money transfer requests. The bases of this authentication scheme is a secret keyboard. Once user opens a new banking account, user will receive a paper keyboard through regular mail.
In this keyboard every key will have an alternate key like:
A might be Z
L might be C
I might be K
C might be J
E might be M
B might be G
O might be H
This alternate keyboard layout will be randomly generated for each customer. Just imagine that if user wants to transfer $ 10, 000 to Alice , he'll have to replace the Alice, her account number and amount etc with the alternate keys, like Alice will be translated into ZCKJE. As bank would get the transaction request it will decode all the values back to original using the exact same keyboard and execute the transaction. Now just assume that attacker wants to transfer funds to his money mule Bob, unless attacker knows about the complete random keyboard or alternate keys for Bob, it can never encode it right. Simply entering Bob as the beneficiary will be decoded as GHG by the bank. An invalid account information will obviously fail the entire transaction.
I can see few problems with this approach as well.
Problem 1: Inconvenience for the user. Would an average Joe will be willing to spend some time reading the paper keyboard and entering beneficiary account information using alternate keys. Although most of the banks offer creating payee's profiles to avoid entering the same information again and again. But it's still lots of work for people who solely use online banking for their convenience.
Solution 1:
Banks may introduce a custom device for their customers with a small key pad (alpha numeric) only. This device should resemble with a standard calculator with a small screen. User will have to enter actual text using this keypad and device will encode it with user specific (part of firmware) keyboard. Efficiency can further be improved if banks offer this encoded device in form of a mobile (only) application like for iPhone and/or Blackberry. This will prevent user from carrying a hard device at the time of adding new payee.
Solution 2:
In case of manual encoding another approach might be used to reduce inconvenience by making this job easier for the end user. Instead of asking user to encode all the beneficiary account information, let him just encode the most variable information like payee name. Without the ability to fully encode money mule name, unauthorized transaction can't take place even if the other account information like IBAN or Swift code is correct.
Problem 2: Technique # 2 is open to sample space attacks. There are certain information like Swift code or IBAN which are suppose to be constant for each bank. How many banks are there in America? A guessing attack might reveal some portion of the keyboard layout. Although partial knowledge of user keyboard might not be enough to fill in all the payee information.
Solution 1:
To prevent sample space attacks, SWIFT code and IBAN should not be offered for encoding, this not only would save the user time but will also reduce the chances of sample space attack. Only the most variable information like payee name should be offered for encoding. Additionally if the custom device is an option then banks might go for a better encryption scheme like AES 192 bit. Communication will be encrypted using a user specific private key, known only to device itself and the banking server.
To further enhance the payee name based manual encoding, we might introduce a slightly different keyboard having only 24 alphabet characters. Each character would translate into a variable length random character strings (1 to 3 characters long) with frequent use of duplicate characters in the sub-situation strings.This type of encoding should be enough to bypass all the sample space attacks.
Example 1:
A --- > BC
T ---> CC
I -- > Z
F --> AFG
so Atif will be encoded like BCCCZAFG, easliy bypassing the character frequency and length based name guessing.
Example 2:
A --- > C
T ---> ZYK
I -- > QY
F --> L
Here Atif would be encoded as CZYKQYL.
Problem 3: A social engineering based MITB attack might crack this technique as well. Just assume that one day a user while trying to login to its online account finds that banking web site is asking him (html injection via MITB) to encode money mule name or account number for some so called verification. Fooled by this trick user might end up giving encoded money mule name to the attacker, which can further be used to make the unauthorized transaction. Although most of these identity theft incidents involve money transfer to the multiple money mules (due to amount upper cap) and it might not be easy for attacker to convince user for encoding so many money mules names.
Solution:
Custom device or paper keyboard should have a clear text warning, something like this:
"Banking web site will never ask you to enter any information using the device. Encoding any information using this device can be used for transferring funds from your account to some external account. Are you sure you are intended to transfer funds to this payee." (Y/N)
Although I can still imagine that some user might simply overlook this warning. Sad isn't it.
I am almost done, none of the solution mentioned above seems perfect. A security system can only be as good as its own user. There is no remedy for the human stupidity.
I would like to finish my article with some general advice to all the online banking users.
1. If you are not one of those guys who perform money transfers often. Just ask your bank to disable this feature for you. On the other end banks should not offer enabling it through online banking.
2. If possible put a minimum limit on amount and number of wire transfers within a certain amount of time.
3. Choose banks which provide you better security options especially something involving secondary devices.
4. Keep your static big cash or long term investment into a separate bank account possibly with online banking disabled. Paper checks and statements are not a bad option even these days.
I won't suggest that users should start using some operating system other than MS Windows. I believe other OS's are not inherently secure either. If more users move to another OS, then so would cyber criminals who are using and sponsoring banking Trojans.
