A Man-in-the-Browser (MITB) attack is a relatively new type of attack that can cause a lot of headaches to developers. The problem is that it is not very easy to prevent or protect against.
What is MITB?
A MITB attack is one in which a user’s web browser is infected with malware. The typical attack vector would be a trojan, that would install an extension or browser helper object (BHO). I wrote a post on malicious Firefox extensions back in February. In it, I spoke about the risk of users visiting a developer’s website and downloading extensions, instead of using the official repository, where all extensions are supposed to have been screened for malware.
How does MITB work?
In a MITB attack, the malware intercepts all communication between the user’s browser and the destination web server and modifies the messages. Let me lay out a scenario.
- User visits banking website and navigates to account transfer page
- The browser extension (or BHO), that has been registered as a handler for every page load, intercepts every request and response. When it sees the account transfer page (say, http://www.mybank.com/accounts/transfer.jsp), it registers a button event handler
- When the user submits a transaction with the transfer details (source account, destination account, amount), the extension extracts the data from the form fields and replaces the destination account and amount with different values
- The extension then submits the values to the server
- When the response is received asking the user to confirm the transaction, the extension parses it and replaces the original values back in the appropriate fields
- The user submits the confirmation and the extension again replaces the values with the values it used earlier
- The server processes the transaction with the modified values rather then the values the user intended
The user, without knowing it has just authorized a transfer of funds to a different account. The server only sees the values that the extension supplied. It will be very difficult for the user to prove that the wrong amount was transferred to the wrong account because all the server/application logs will have the wrong values consistently. Another problem is that the extension will see and modify the form values before they are encrypted for SSL/TLS transmission, so that will not protect the user at all.
Protecting against MITB
There are few ways to mitigate or prevent the problem, but I am going to discuss a couple of the more common methods; hardened client and out-of-band verification.
In this method, a hardened client is provided to the users. This would be a web browser that has been compiled into one binary does not allow any extensions to be added. The client could also only https connections (if required for banking or similar applications). While this is possible, it may not be practical with a large user base. There is no guarantee that users will always use only this client to access the website.
Another way to provide a hardened client would be to supply a Live distribution of a OS and all the required applications on a Live distribution that runs off read-only media such as CD-ROM or DVD. This would reduce the chances of malware on the OS (and the browser), but again, there are practical issues. Check out my previous post on using a LiveCD/USB for banking online.
Secure Card Reader
People using web browsers to make online purchases can use a secure card reader such as SmartSwipe that will encrypt the card numbers as you swipe and inject the information directly into the SSL/TLS tunnel. The web browser or the malware never even see the payment information. The web site that you are making the purchase from does not even know that such a device is being used. They will see the data as they have always see it.
The card reader usually connects to the computer using a USB cable and comes with associated software.
With out of band verification, a message is sent to the user on a separate channel such as phone. Every time the user initiates a transaction through the web browser, a message, say, an sms or email would be sent to the user. The user would then either respond with a code or click on a link to confirm the transaction. The idea is that it is extremely difficult for someone to compromise both the channels (web browser and phone) to pull of a successful attack. For transactions involving large amounts, a phone call may also be made mandatory.
But there are issues with this method too that might make it impractical. Some users may not have a phone that supports the required services, they may be in a location where they cannot use the phone (may be in another country), etc. Also, if email is used, it needs to be noted that if email is accessed from the computer that was used to originate the transaction, the confirmation may be suspect too. It would not actually be a second channel.
Then there is the scenario where the user initiates one transaction, but the extension submits multiple transactions without the user’s knowledge. This could be overcome with a human test such as a captcha or asking questions that only the user would know.
Organization also cannot solve this problem. They have to make sure that their users are educated on the threats and how to recognize the symptoms of an infection of their computers. Users will also have to take responsibility for security and not leave every thing to their bank or other organizations. Individually, it is very difficult tackle these problems, but together, there is a chance.