MITB (Man in the Browser) Protection Layers

In my last post, I talked about some of the 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."

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.

Atif Mushtaq @ FireEye Malware Intelligence Lab

Detailed Question/Comments : research SHIFT-2 fireeye DOT COM

Comments

[SippieCup]

technique 2 is absolutely worthless as it is a simple replacement and the hacker can see everything that the user is doing and inputting. if you have the input and output, all you need is a little time before you know what it is.

how you can break the virtual keyboard encryption:

1) install keylogger,
2) wait for person to go bank website (this will still be able to be keylogged / post'd)
3) look for long strings of jibberish
4) look for a string the person types which matches in syntax NOT related to length. in your example, A -> BC that is probably the worst way of making an encryption stronger, "lets just increase the key size!"

this encryption is broken, I should not have to go into why. it is a similar situation to DES encryption, and the reason why DES is not used 100% of the time, but only after things like RSA encryption is used to send the keys for DES. only difference is that rather than being the straight key, you are sent all the information (included the decrypted output) after submitting the encrypted text.
example:
if you send something to lex, his name is encrypted to CCHEGWS, however on the following page do you want to see "you are going to send CCHEGWS $YW*@NDH, is this okay?"

no, you will want plaintext. Thus, simple regex will kill the encryption.

Furthermore, you can say that numbers would be much harder to decrypt, but even this can be easily done. the numbers inputted to the site might be encrypted. but once you send the money and look at your bank account, do you want that encrypted? (i.e. you have $d@34 in your account, not you have $5827 in your account)

of course you don't, it will be impossible to track your finances. and even if you do, someone else definitely will not, blame the bank website on why they went bankrupt, and sue the bank to make millions. So the bank wont do that either.

so, how do you decrypt numbers? simple, you compare the string entered and its time to the recent transactions and their time. this will make numbers the easiest thing to do. you can even do this for the regular wars and not even need to brute force anything.

as for SMS verification, once a hacker is in the browser, he/she can contact support, and tell them you got a new cell phone, change the number to some google voice number (easily and anonymously made), and use that to verify. Thus making this an equally moot point. As someone in security, you should know phone verification is something that is very simple to get through.

if they don't allow google voice numbers. you can implement a few techniques using craigslist to do it, or you can just buy a prepaid phone anonymously and have it ready.

--------

The only way to get out of a MITB attack is to get out of the browser. Banks need their own applications/encryptions which do not rely on external things. anyone executing a man in the browser attack can look exactly like the user, and can see everything the user can. however, this will still be plagued by regular trojans, so even this will not be enough and is an inconvience to the user.

IMO, the best way to do it would be for a VPN to a secure bank server and doing all the banking server side with the bank heavily logging the connection. and by getting a new username/pass every time you want a new session. this can be done by a text message because once you login, you can have the bank server stop that user/pass from ever logging in again. and they can have it killed after 20 minutes if there is no login.

that means that you always have a new user/pass when logging in. the only time the attacker would be able to login is in between the time the text is sent, and you login. heavily logging login attempts will make the bank aware that someone would be trying to get into their account, and that they have some sort of trojan installed. The bank would be able to inform the user of this, and the user can have their computer reformatted/cleaned.

Another way, and possibly the best, of the banks protecting themselves would be to release their own linux system on a thumb drive. the only way people can login to the account is by booting off this drive to a very simple linux system (which is quick to boot and has networking), and have ti be the only way to connect to your bank. make the drive read-only and there is no way that an attacker can get in to your account without using network-based attacks (which are much MUCH rarer).

[Johan]

Well, I do keep my banking application on its own virtual machine that I use for nothing else (I only have it turned on for the time I'm using the banking application). I'm sure this is very good practice but not everybody is a sysadmin...

[Atif Mushtaq]

Johan
------
End of the day there will be some application running on the vulnerable system making all these transactions. You are assuming that this application would be more secure than browser. I don't think so! It's not very difficult in windows to change values in the memory of any external process. Attacker can hook into windows message queue and wait for the user to do some transactions, and right before these values are going to be encrypted, change the legitimate account information with one of his money mules accounts. Similarly it's not difficult to launch this application in hidden mode and problematically perform the complete transaction.

[Atif Mushtaq]

Daniel
------
Paper based codes are just like 'Safety Pass' based random code. We already know how attacker might hijack such codes with simple social engineering. Apart from that, it can't protect user against transaction manipulation MITB.

[Atif Mushtaq]

Thanks guys for these suggestions. But I find slight problems with each of the above techniques..Let me explain one by one.

Ali
----
The only problem I found is that user might also end up handing this secret question to the attacker.

1. User gets a fake SMS from the attacker, pretending to be bank and asking about this secret question. Just like user fooled into giving these secret questions to the attacker while MITB attack. He may hand it over again.

2. User might select a secret question which is already compromised or already known to the attacker.

But yes this technique would further improve things a bit but on the cost of more inconvenience to the user. If user would have to enter it again and again. He might get used to it so much that he would simply learn to enter it always.

[Johan]

Am I more secure using an application that establishes its own VPN tunnel with the bank server, instead of using a web browser? I have always felt more secure, because there is no browser involved...

[Daniel Lohin]

I think an easier method is what some European banks do. Send a One time key paper to the user. This paper just contains random keys like xcdse23. A user starts at the top left and each time one of these keys is used, they cross it out and move on to the next one. This has a few benfits, it is pretty cheap. I think it is easier then having the user do a Ceasar Cipher. I know that this One Time key approach is using the definition a little off, because you would need enough characters to encrypt all the data.

[Ali Islam]

Atif,

Good article, you have treated the topic very well. I would like to propose another solution to technique_1.

Solution --> Instead of just asking for plain acknowledgment via SMS, the bank should ask for an answer to a "secret question". With that done, even if the attacker successfully changes the Safety Pass (using MITB) to his own mobile, he cannot answer that secret question and hence can't do the illegal transaction.

It may not be the perfect solution but so far I don't see any problem with it.

cheers,
Ali