[WEB SECURITY] Similarity between Banking Trojans and CSRF

[Ryan Barnett]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webappsec.org/pipermail/websecurity_lists.webappsec.org/attachments/20070907/5411b168/attachment.html>