[Fwd: Re: Solution for man-in-the-browser]

[smurray1 <smurray1 () nycap rr com>]

Thanks for all the replies.  Solutions that have been proposed to my 
email talk about securing the client-- user training, Anti-malware, 
etc.  From experience, I don't trust either.  I see malware on very 
conscientious, well informed users with working up-to-date malware all 
the time.   There seems to be a theme that, because of 
man-in-the-browser attack, high-risk transactions are quickly becoming 
not suitable for the Internet (at least until there is some kind of 
trusted browser that is resistant to malware, but that is not happening 
anytime soon).  Is that where this is going? 

I understand that that my proposal does not solve the man-in-the-browser 
attack and any compromised client is a basically "game over" situation.  
(I used a poor choice of words in my subject -line).  I am looking for 
an additional control for defense-in-depth that would help defend 
against the attackers who are buying zeus-like malware to create their 
own botnet and setting up a fraud shop. 

Does everyone agree  for an attacker to defeat my proposal they would 
have to:

1)  Get the authentication information from the user (this is already 
happening)
2)  Replace the HMAC java applet/javascript with their own that mimics 
the input window to capture the shared secret  (the shared secret itself 
is never outputted from java applet/javascript)
2) Stop the user's transaction from being submitted to the server (which 
would make the shared secret no longer usable to the attacker)
3) Use the captured shared secret and the same (HMAC) algorithm to 
create a MAC and submit their own fraudulent transaction. 

To even get to a point to write the malware to do this, they would have 
to compromise an account  to see  the transaction page to begin to 
decode what it is doing.  This can be done (very easily if javascript is 
used as opposed to compiled code), but it is some effort from with some 
good technical skills.  This would have to be a well motivated attacker. 
 Does everyone agree, this is not worth the effort?

Thanks!!

Sean T Murray


> 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.
>
>
>
>
>
>
>
> 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.
>
>
>
> Bottom line, don't waste your development $$ on a problem that cannot
>
> be fixed in this manner.
>
>
>
> -kevin
>
> --
>
> Kevin W. Wall   614.215.4788            Application Security Team / 
Qwest IT
>
> "The most likely way for the world to be destroyed, most experts agree,
>
> is by accident. That's where we come in; we're computer professionals.
>
> We cause accidents."        -- Nathaniel Borenstein, co-creator of MIME
>
>
>
> This communication is the property of Qwest and may contain 
confidential or
>
> privileged information. Unauthorized use of this communication is 
strictly
>
> prohibited and may be unlawful.  If you have received this communication
>
> in error, please immediately notify the sender by reply e-mail and 
destroy
>
> all copies of the communication and any attachments.
>
>
>
> _______________________________________________
>
> 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
>
> _______________________________________________
>
_______________________________________________
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
_______________________________________________