Re: Solution for man-in-the-browser

[Rorym Forums <rorym.forums () gmail com>]

On 11 Sep 2010, at 16:58, "Wall, Kevin" <Kevin.Wall () qwest com> wrote:

> On Sep 10, 2010, at 5:34 PM, smurray1 <smurray1 () nycap rr com> wrote:
> > Hello,
> >
> > I have been discussing an issue with an organization that is having
> > an issue with malware on it's customer's clients that is intercepting
> > user credentials and using them to create fraudulent transactions.
> > (man-in-the-browser type attacks similar to what Zeus and other trojans
> > are capable of).  I told them that they should be using a shared secret
> > between the user and the system to use as an input to HMAC to create
> > a MAC for the form for the critical transaction.
> > I see it working like this.  The form that is used for the critical
> > transaction would have either a java object or javascript that, after
> > the user fills the field and the presses the "submit" button:
> > 1) Accepts  a single use shared secret from the user.
>
> <...deleted...>
>
> Jim Manico responded:
> > I do not think this will work. Once your browser is trojaned, it's
> > game over. The Trojan has the capability to just sit in your browser
> > and wait for the user to log in. (Trojans do not need to steal
> > credentials to cause harm). Once the user has logged on, the Trojan
> > can simulate any user activity such as requesting and submitting
> > forms, circumventing CSRF tokens and other web app defenses.
>
> Jim is absolutely correct. You are better off spending time removing
> all the malware and securing your machines properly, trying to
> educate your users, etc. You may also want to add AV scanning
> during the web browsing sessions if you don't already support that.
>
> Besides, once your browser is trojaned, there is no shared "secret", or more
> accurately, you would also be "sharing" your secret with the malware
> which obviously would not do you any good. Once the browser endpoint
> is compromised, NOTHING sent from it can be trusted any longer. For
> instance, since TLS provides only point-to-point encryption, malware
> running in the browser can read plaintext and insert data at will.
> _______________________________________________

Unfortunately I think that cleaning / controlling pc's isn't possible for a lot of organizations (retail banks etc) 
where they have limited or no control over the client environment. 

I'd agree with Kevin and Jim that once the browser is trojaned you can't trust anything coming from it.

One option to consider would be out of band validation for transactions .  Using out of band confirmation of 
transactions can help with confirming that the transaction is valid, via a channel that may not be under the control of 
the attacker.  For example sending a note of the recipient and transaction amount to a registered mobile phone number 
for the account and having the user respond over that channel, with a validation token.

Obviously there are a lot of details to consider (eg what transactions require oob auth, ensuring that it is difficult 
for the attacker to get access to the mobile phone number of a specific account etc)

Cheers

Rory
_______________________________________________
Secure Coding mailing list (SC-L) SC-L () securecoding org
List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
List charter available at - http://www.securecoding.org/list/charter.php
SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com)
as a free, non-commercial service to the software security community.
Follow KRvW Associates on Twitter at: http://twitter.com/KRvW_Associates
_______________________________________________