How can you prevent Man in the Browser attacks?
Asked Answered
S

5

7

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.

Schoen answered 11/5, 2009 at 1:38 Comment(1)
The physical keygen authenticates that you possess the keygen. It doesn't prove that you're you (instead of someone else who's stolen your keygen from you), nor that you know what your browser is doing.Matthaeus
G
1

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.

Grubbs answered 11/5, 2009 at 2:48 Comment(0)
B
2

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.

Blackman answered 11/5, 2009 at 1:47 Comment(0)
M
1

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.

Matthaeus answered 11/5, 2009 at 1:47 Comment(0)
P
1

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. :)

Proceed answered 11/5, 2009 at 1:49 Comment(0)
G
1

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.

Grubbs answered 11/5, 2009 at 2:48 Comment(0)
H
1

This is my point of view for the man in the browser. The man in the browser is as if:

  1. The victim stands up, leaves his computer, and move his back to his computer, so he can not touch the keyboard, move the mouse or even see the screen.
  2. A hacker sits behind victim computer.
  3. If victim wants to work with his computer he must ask the hacker to do it for him. If he wants to see any result, he must ask the hacker to read the data on the monitor.
  4. The hacker does his best to convince the user that he is doing what he asks for and repeats what he seas. But try to make the benefit of this situation with no mercy !

Man In The Browser

As a simple case:

  1. Victim may ask hacker to fill a transaction form data as transfer 500USD to mom.
  2. The hacker instead can type transfer 10000USD to Jack. ( Tamper form data before send)
  3. The system may display, I have transferred 10000USD to Jack but the hacker says that the 500USD has transferred to Jack. ( Tamper result HTML)
  4. The victim asks to see his account balance, to make sure that the transfer is done.
  5. The hacker can say that the the account balance in correct ( This can be done for example, by removing the last line of balance table and changing the balance amount in HTML)

As for email:

  1. You are waiting for an email, and ask hacker do I have a confirm email from bank.
  2. As you can not see the monitor, he say yes you have. (Technically he can generate a fake email easily). (even if you sit on another clean computer, a fake email can be sent to you again)

The image generation can not prevent attack.

  1. You ask the hacker, my bank should shows me an image which must display the transfer information, could you see it, what does it says.
  2. The hacker reply: Yes I can see it, it says "You are transferring 500USD to mom" (The image can easily created by the JavaScript or hacker can point the image url to a server, which generates a dynamic image with appropriate data to cheat user)

The very dangerous situation may happens as the man in the browser change the flow of the site. In this case even an OTP or kegen system can not prevent the attack. For example:

  1. You ask hacker that you want to see your balance
  2. The hacker goes to transfer account page, and fill a transfer account form to transfer 10000USD to jack ( but you don't know what is he doing at all, you are just waiting) he come to a page that asks him for a key. This is the key you which you must give him.
  3. Now, the hacker says : Well, the bank ask me if you want to see your balance you must enter a key.
  4. You think, well a key for balance seems strange, but any way lets give that key, I trust this guy !!
  5. The hacker switch back to transfer form and use the key to do the transfer.

So as you can see there is no server side solution for a Man in the browser you can:

  1. Use a out of the band solution to inform critical information to user. ( This is as if you take a mobile in your hand and although your back is still to your computer but sensitive information are sent to your TRUSTED device and you can see critical information)
  2. Use a hardened browser to make sure that no one can change its behavior. ( Sit back to your computer :) )

Good samples of what can be done by MITB can be found at: http://www.tidos-group.com/blog/2010/12/09/man-in-the-browser-the-power-of-javascript-at-the-example-of-carberp/

Halfdan answered 2/8, 2015 at 5:16 Comment(0)

© 2022 - 2024 — McMap. All rights reserved.