[WEB SECURITY] Similarity between Banking Trojans and CSRF

[Erwin Geirnaert]

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 .  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 XSRF
<http://www.cgisecurity.com/articles/csrf-faq.shtml> , CSRF
<http://www.cgisecurity.com/articles/csrf-faq.shtml> , and Cross Site
Reference Forgery <http://www.cgisecurity.com/articles/csrf-faq.shtml> )
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&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. THIS COMPANY NAME 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. 

--------------------------------------------------------------------------------
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webappsec.org/pipermail/websecurity_lists.webappsec.org/attachments/20070907/bb425a72/attachment.html>