Secure Coding mailing list archives
Re: Solution for man-in-the-browser
From: James Manico <jim () manico net>
Date: Fri, 10 Sep 2010 20:28:30 -0700
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 Manico http://manico.net 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. 2) Uses that as the "key" input for an HMAC that is run over the concatenation of all the values for each field in the form (that would include a time stamp or nonce). 3) Uses the result of the HMAC to fill a hidden field on the form. 4) Submits the form The server receives the form, uses the shared secret as the "key" input for the HMAC and validates the result is the same as the hidden field. If they do not match the transaction is rejected. I understand the there is issues of the HMAC strength due to the limited size of the shared secret, and that there is the ugly problem of distributing the single-use shared secret to the user. The question is will this work? If an attacker steals the credentials, they still could not submit a transaction without knowing the shared secret, which never goes over the wire. If course it is not a perfect solution, as the malware could use a key logger to grab the shared secret when the user inputs it and block the users submittal and then use the stolen shared secret to create a MAC for a transaction of it's own. But that would require custom written malware and/or the attacker waiting for input from the malware. Any input and/or suggestions would be appreciated. Thanks in advance, Sean T Murray _______________________________________________ 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 _______________________________________________
Current thread:
- Solution for man-in-the-browser smurray1 (Sep 10)
- Re: Solution for man-in-the-browser James Manico (Sep 11)
- Re: Solution for man-in-the-browser Wall, Kevin (Sep 11)
- Re: Solution for man-in-the-browser jeremy . long (Sep 13)
- Re: Solution for man-in-the-browser Jeremy Epstein (Sep 13)
- Re: Solution for man-in-the-browser Rorym Forums (Sep 13)
- Re: Solution for man-in-the-browser Wall, Kevin (Sep 11)
- Re: Solution for man-in-the-browser James Manico (Sep 11)