June 25, 2006

FC++3 - Concepts against Man-in-the-Browser Attacks

This emerging threat has sent a wave of fear through the banks. Different strategies have been formulated and discussed in depth, and just this month the first roll-outs have been seen in Germany and Austria. This information cries out for release as there are probably 10,000 other banks out there that would have to go through and do the work again.

Philipp Gühring has collected the current best understanding together in a position paper entitled "Concepts against Man-in-the-Browser Attacks."

Abstract. A new threat is emerging that attacks browsers by means of trojan horses. The new breed of new trojan horses can modify the transactions on-the-fly, as they are formed in in browsers, and still display the user's intended transaction to her. Structurally they are a man-in-the-middle attack between the the user and the security mechanisms of the browser. Distinct from Phishing attacks which rely upon similar but fraudulent websites, these new attacks cannot be detected by the user at all, as they are use real services, the user is correctly logged-in as normal, and there is no difference to be seen.

The WYSIWYG concept of the browser is successfully broken. No advanced authentication method (PIN, TAN, iTAN, Client certificates, Secure-ID, SmartCards, Class3 Readers, OTP, ...) can defend against these attacks, because the attacks are working on the transaction level, not on the authentication level. PKI and other security measures are simply bypassed, and are therefore rendered obsolete.

If you are not aware of these emerging threats, you need to be. You can either get it from sellers of private information or you can get it from open source information sharing circles like FC++ !

Posted by iang at June 25, 2006 12:43 PM | TrackBack
Comments

[Copied from anti-fraud]

| 2.1 Current situation
|
| Currently this technology seems to be only in the hands of financial
| fraudsters. It is currently high-tech, and high-priced, with very
| limited distribution. The time-to-market for active attacks is
| estimated to be 3 days.
|
| Only targets of significant financial value have a worrying risk of
| being attacked with this technology in the near-term.

I think you got that backwards. Currently, this technology is only required to attack customers of some financial institutions. For the majority of web applications, it is sufficient to eavesdrop on HTTPS connections and recover the protected storage area, and you can issue arbitrary transactions.

| 3.1.4 Class 4 SmartCard reader
|
| A theoretical solution for a secure client would be the Class 4
| SmartCard reader. Although not available, the device characteristics
| and security profile are relatively well understood, and appropriate.

FINREAD does exist, but failed to penetrate the market. There are also relatively cheap gadgets which use symmetric cryptography and require that the user transfers a couple of bits manually to and from the device (which means that there is zero setup cost on the customer side).

Posted by: Florian Weimer at June 26, 2006 07:12 AM

[Copied from anti-fraud]

Section 1.2.1:

A "plugin" is not the same as a Browser Helper Object. A plugin is something like Flash or Java, which can take over a square shape in your web page and display its own content.
http://en.wikipedia.org/wiki/Plugin

What you are talking about are "addons" or "extensions".

3.1.1 is a dead loss. Even if you could create it:

a) Users would never use it
b) Fraudsters would just intercept and change the HTML at the network layer, or replace the binary entirely.

3.1.3: how does this help? Running your OS inside another OS does not, in itself, provide any protection from you getting a trojan installed inside the guest OS.

And an idea you've missed out (as far as I can see), which some banks are already using - a challenge/response system where the browser prints up a challenge number, you type it into the keypad on a smartcard reader with your bank card inserted, it does some crypto and offers a response, and you put that back into a text box on the computer. In other words, you move the trusted platform off the PC. Bad usability, but reasonable security.

"Once an attacker has root access on your computer, it's not your computer any more."

Posted by: Gerv at June 26, 2006 07:15 AM

Re Virtual machines (3.1.3) -- while it is true that no guest VM can be more safe than the host, the typical way to use them is not as a secure isolated system, but as a known-to-be-unsecure one from which the host system is isolated. Example: you copy a pristine VM, surf to the unsafe website, and once you are done with whatever it is you wanted to do, discard the now tainted copy.

Posted by: Felix at June 26, 2006 08:21 AM

Hi Philipp,

I will probably have other comments to make, but here are a couple about your mention of PassFaces -- the description in Section 4.3.3 misses a few worthwhile points:

- It is hard to fool a user into revealing their secret just by asking for it (e.g. "please enter your password"), because the PassFaces prompt is an array of nine faces, exactly one of which must be the correct face.

- It is defeated by a man-in-the-middle attack (the attacker can obtain each array of nine faces by attempting a login at the real site).

- Although it seems significantly better than typical passwords in terms of memorability/strength trade-off for a single site, it may be an excessive burden for users to have secrets made of PassFaces at many different sites.

Hope these are helpful,

Posted by: -- ?!ng at June 26, 2006 04:05 PM

Philipp Gühring wrote:

>> 2.1 Current situation
>>
>> Currently this technology seems to be only in the hands of financial
>> fraudsters. It is currently high-tech, and high-priced, with very
>> limited distribution. The time-to-market for active attacks is
>> estimated to be 3 days.


Like Florian, i am skeptical of this claim. I have seen screenshots of downloadable tools that will generate custom Trojans for you -- you choose the options you want, and they will produce a ready-made Trojan. Hardly any expertise is required.

Posted by: -- ?!ng at June 26, 2006 04:07 PM

more complications in developing a secure browser:

http://www.theinquirer.net/default.aspx?article=32756

has a good story about firefox scripting engine, and mozilla seamonkey and so forth ...

Posted by: Matthias at July 1, 2006 06:29 AM

Under 3.1.2 Unwritable Distribution, the author seems to have missed out mentioning write-protected USB pen drives on which the browser is installed and from where it runs. So the user wouldn't need to restart from a bootable CD...

Hmmm, of course the reg keys, app data and user settings would be on the hard drive and could be tampered with.. Option could be to use this as an alternate browser for critical sites, while doing daily browsing from one installed on the hard drive as usual.

Posted by: Anonymous Coward at September 13, 2007 01:53 AM

>>A "plugin" is not the same as a Browser Helper Object. A plugin is something like Flash or Java, which can take over a square shape in your web page and display its own content.
http://en.wikipedia.org/wiki/Plugin
-----------

Any solution that relies on browser content pane (rectangle) will not work. Man in the middle can manipulate this. This approach might work against man in the browser. KeyID (http://www.KeyID.com) has recently lauched a product that works by integrating authentication and communication channel. The solution relies on a browser plug-in where you type in the username, password, OTP etc. The authentication information is not typed in the browser content pane. The authentication information in then mixed with the channel information and submitted on a standard https connection. It uses same form fields and does not require any significant changes on the server end.

The same product also works with Smartcards using the same concepts.

Posted by: Sunil at January 14, 2008 02:32 PM
Post a comment









Remember personal info?






Hit preview to see your comment as it would be displayed.