Re: [SC-L] Solution for man-in-the-browser
On 11 Sep 2010, at 16:58, "Wall, Kevin" wrote: > On Sep 10, 2010, at 5:34 PM, smurray1 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 ___
Re: [SC-L] Solution for man-in-the-browser
Just to echo the other comments - there's already malware out there that handles per-transaction authorization codes and substitutes in its fraudulent transaction for the real one. (If you look at some of the banking thefts against small & medium businesses, that's what's happening.) So this scheme wouldn't even address existing threats, much less new ones. Having said that, if the organization being defended is obscure enough and/or the potential transaction value is low enough, there may be little enough value to an attacker that even an easily bypassed mechanism such as that proposed might have a deterrent effect. Just as a lock on the front door is no protection against even a moderately sophisticated thief (who knows how to lock-bump, for example) doesn't mean that there's no value in keeping the door locked. It's just adding a measure of obscurity. The question is whether the additional obscurity increases the work factor for a potential attacker enough to compensate for the additional effort to the user. Since in this case it looks like the user would have to enter a one-time transaction code, the answer is almost certainly "no". --Jeremy ___ 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 ___
Re: [SC-L] Solution for man-in-the-browser
Completely agree with Jim and Kevin. Once the client host is compromised you can't trust the client. On the server the best you can do is monitor for unusual page flows, click rates that are too high (or time to complete a form is too high), monitor for transactions outside of the norm for the client, different user agent/IP geography from last transaction, etc. Basic fraud monitoring. Your detection ability against Zues like malware is dependent upon the skill of the malware owner/author. Some are clumsy, some you will never see until it is too late (if ever). --Jeremy On Sep 11, 2010 11:58am, "Wall, Kevin" wrote: On Sep 10, 2010, at 5:34 PM, smurray1 smurr...@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 ___
Re: [SC-L] Solution for man-in-the-browser
On Sep 10, 2010, at 5:34 PM, smurray1 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. Bottom line, don't waste your development $$ on a problem that cannot be fixed in this manner. -kevin -- Kevin W. Wall 614.215.4788Application 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 ___
Re: [SC-L] Solution for man-in-the-browser
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 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 ___
[SC-L] Solution for man-in-the-browser
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 ___
