[WEB SECURITY] Similarity between Banking Trojans and CSRF

[Glenn.Everhart at chase.com]

This kind of thing can be fought by some positive ack from the customer of something about the transaction - I suggest
the total amount - which needs to be generated in some way that cannot readily be imitated by a Trojan. (Aside: why do we
call it a Trojan still; Odysseus' horse was inhabited by Acheans and the Trojans' sin was gullibility.) 
 
Doing this requires hardware and minimal data entry by customer. Clearly though, trusting a login leaves one completely
open to MITM attacks. There needs to be good auth at the start, but it is needed again at the end of a transaction
with something positive about the transaction included in whatever authenticator is sent back, so the customer
knows what he has agreed to.
 
This can still lead to small-amount thefts if the customer is unable to add up his/her transaction amounts correctly, but
will make it hard.
 
A simple token can be used to do this. I have serious reservations about trying to get away with software in a PC,
since it is also subject to sabotage by MITM Trojans. (Acheans?).
 
Glenn Everhart
 
-----Original Message-----
From: Erwin Geirnaert [mailto:egeirnaert at securityinnovation.be]
Sent: Friday, September 07, 2007 3:25 PM
To: Ryan Barnett; WASC Forum
Subject: RE: [WEB SECURITY] Similarity between Banking Trojans and CSRF



The only solution that I can think of is implemented by Belgian banks as follows:

-          Strong authentication with a one-time password (no protection against CSRF)

-          Signing of transactions before starting the transactions using a challenge/response mechanism like to create the one-time password: will protect against CSRF IF the user reviews every transaction (you can sign a bulk for convenience)

-          I also think that a nonce like the Apache token is a good best practice, at least it will allow to detect fraud on the server-side (if they look at logs J)

 

I strongly believe that we, as a web app sec community, need to work together with the malware vendors.

 

ABN/AMRO got hacked the same way.....

 

Best regards,

 

Erwin

 

From: Ryan Barnett [mailto:rcbarnett at gmail.com] 
Sent: vrijdag 7 september 2007 17:26
To: WASC Forum
Subject: [WEB SECURITY] Similarity between Banking Trojans and CSRF

 

I was reading this article about the keynote presentations at the recent Hack in the box conference - http://news.zdnet.co.uk/security/0,1000000189,39289141,00.htm  <http://news.zdnet.co.uk/security/0,1000000189,39289141,00.htm> .  In it, Mikko Hypponen, chief research officer at security company F-Secure, states the following about Banking Trojans.  I found this interesting from a webappsec point of view -

"However, these methods don't address man-in-the-middle attacks or banking Trojans," he said. "This kind of software silently sits on an infected computer for weeks until a user logs online into his bank to pay some bills. When that happens, the Trojan silently inserts [fake] 'bills' without the user's knowledge [and makes it seem] as though he is paying his bills." 

From the banks' perspective, the transaction looks legitimate but in fact it is not, Hypponen said. 

"Money is then stolen by hackers... despite the fact that the user had taken precautions to log on to a legitimate website, and the connection [was] secured by encryption," he said. 

According to Hypponen, there is currently no security tool to effectively protect against banking Trojan exploits. So, he added, the best form of protection is to stop the malicious code from infecting the PC in the first place. 

While malicious code such as this, that infects user's computers, certainly doesn't follow the whole "cross-site" portion of CSRF, the remainder of the attack vector seems identical - a request was made to a web app that the user did not intend to make.  If you look at the common definitions for CSRF this attack still seems to apply from a web app's perspective.  Such as this portion of the definition - http://www.cgisecurity.com/articles/csrf-faq.shtml#whatis -

Cross Site Request Forgery (also known as  <http://www.cgisecurity.com/articles/csrf-faq.shtml> XSRF,  <http://www.cgisecurity.com/articles/csrf-faq.shtml> CSRF, and  <http://www.cgisecurity.com/articles/csrf-faq.shtml> Cross Site Reference Forgery) works by exploiting the trust that a site has for the user. Site tasks are usually linked to specific urls (Example: http://site/stocks?buy=100 <http://site/stocks?buy=100&stock=ebay> &stock=ebay) allowing specific actions to be performed when requested. If a user is logged into the site and an attacker tricks their browser into making a request to one of these task urls, then the task is performed and logged as the logged in user. 

I am interested to hear feedback on this topic as many of the CSRF mitigations center around preventing the browser-based infection of the HTTP request data and in this case it is sent from a malicious application that was injected through other means (email) and it perhaps working as a browser helper object or MITM proxy. 


-- 
Ryan C. Barnett
ModSecurity Community Manager
Breach Security: Director of Application Security Training
Web Application Security Consortium (WASC) Member
CIS Apache Benchmark Project Lead
SANS Instructor, GCIA, GCFA, GCIH, GSNA, GCUX, GSEC
Author: Preventing Web Attacks with Apache 

  _____  

Note:
This message is for the named person's use only.  It may contain confidential, proprietary or legally privileged information.  No confidentiality or privilege is waived or lost by any mistransmission.  If you receive this message in error, please immediately delete it and all copies of it from your system, destroy any hard copies of it and notify the sender.  You must not, directly or indirectly, use, disclose, distribute, print, or copy any part of this message if you are not the intended recipient. ZION SECURITY and any of its subsidiaries each reserve the right to monitor all e-mail communications through its networks.
Any views expressed in this message are those of the individual sender, except where the message states otherwise and the sender is authorized to state them to be the views of any such entity.
 
Thank You. 

  _____  


Scanned by MailMarshal - Marshal's comprehensive email content security solution. Download a free evaluation of MailMarshal at  <http://192.168.123.154/exchweb/bin/redir.asp?URL=http://www.marshal.com> www.marshal.com. Implemented and supported by ZION SECURITY.

  _____  




-----------------------------------------
This transmission may contain information that is privileged,
confidential, legally privileged, and/or exempt from disclosure
under applicable law.  If you are not the intended recipient, you
are hereby notified that any disclosure, copying, distribution, or
use of the information contained herein (including any reliance
thereon) is STRICTLY PROHIBITED.  Although this transmission and
any attachments are believed to be free of any virus or other
defect that might affect any computer system into which it is
received and opened, it is the responsibility of the recipient to
ensure that it is virus free and no responsibility is accepted by
JPMorgan Chase & Co., its subsidiaries and affiliates, as
applicable, for any loss or damage arising in any way from its use.
 If you received this transmission in error, please immediately
contact the sender and destroy the material in its entirety,
whether in electronic or hard copy format. Thank you.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webappsec.org/pipermail/websecurity_lists.webappsec.org/attachments/20070910/72f73ccc/attachment.html>