How can you prevent Man in the Browser attacks?

Question

Been reading up on MitB attacks and some things worry me about this.

From WIKI:

The use of strong authentication tools simply creates an increased level of misplaced confidence on the part of both customer and bank that the transaction is secure.

One of the most effective methods in combating a MitB attack is through an Out-of-Band (OOB) Transaction verification process. This overcomes the MitB Trojan by verifying the transaction details, as received by the host (bank), to the user (customer) over a channel other than the browser

So if I get this straight, that the only real safe method is a non browser confirmation method. (like a phone call or some other external tool)

Would an email count as a OOB Transaction? Or could the MitB send a fake email?

Is there a way to prevent MitB with only code?

EDIT: I'm asking this because our local banking system are employing a physical keygen system for which you have to push to get a number and then enter that number into a field in the transaction form.

I have no idea if that is considered safe, since it looks like a MitB attack is just making it look like everything you did is safe and correct but what actually happened is that the form data was changed on submit and is now transferring to some other bank account. So it would have access to this keygen number.

Answer 1

Would an email count as a OOB Transaction?

Given the prevalence of Web mail services like GMail, I would say No. Even if the target of such an attack isn't using Web mail, an attacker that has control of the target's browser could fire off a fake email, just as you suggest.

Answer 2

In the article which is the subject of (and referenced by) that Wikipedia article, step 1 in the "Method of Attack" is stated as:

1. The trojan infects the computer's software, either OS or Application.

The answer to your question is therefore "no": once the O/S is infected then the malware can (theoretically at least) be intercepting your email too.

As an aside, some client platforms (e.g. even mobile phones, not to mention dedicated point of sale terminals) are less susceptible to infection than others.

Answer 3

I suppose you could use critical pieces of the transaction information as part of a secondary or tertiary transaction verification step. That is, if I thought I told the bank account #12345 and it heard #54321 because the data was adulterated by that type of attack, the secondary verification would fail the encryption check. It would also be possible for the bank to echo back something that was more difficult to alter, like an image containing the relevant information.

The thing about these types of discussions is that it can always get more complicated. Email is not valid out of band step because, I have to imagine I have a rootkit ... if I stop that, I have to imagine that my OS is actually a guest OS running in an evil virtual machine ... if I stop that, I guess I have to imagine it's the matrix and I can't trust anything all to protect my visa card with $200 of available credit. :)

Answer 4

Generally speaking if your machine is infected then you are vulnerable no matter what.

A physical token or "out of band" token is designed to solve the "identity" problem and gives the bank higher confidence that the person logging in is the person they say they are. These sort of mechanism normally involve using a "one time code" technique so that even if someone is recording the conversation with the bank, the token can't be reused. However if the malware is intercepting in real-time then they can maliciously control the account after you have successfully logged in, but often banks require a new 'code' each time you try and do something like transfer money out of the account. So the malware would have to wait for you to do this legitimately and then modify the request. However most malware are not real-time and send data to a 3rd party for collection and later use. Using these "one time token" techniques would successfully defend against this post processing of the login data, because the recorded data can't be used later to login in.

To answer your question, there is no way to defend against this only in code. Anything you do could be specifically worked around in a piece of malware.