Re: [WEB SECURITY] Similarity between Banking Trojans and CSRF

["Shi Lei" <zuccforumtest@xxxxxxxxx>]

------=_Part_4612_19088942.1189326015819
Content-Type: text/plain; charset=WINDOWS-1252
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Interesting topic.

Like jeff has said, the traditional way we prevent CSRF cannot help us in
this trojan situation. We need a new solution.

And the XSS matter, yes, CSRF is usually due to some XSS flaws, especially
when they combine together, deadly enough. But XSS is much more complicated=
.
For my part, it would be better to fouse on the trojan.

PS: Bedirhan, thanks for your notice:)
PS2: forget Cc again....:(


On 9/7/07, Ryan Barnett <rcbarnett@gmail.com> wrote:
>
> I was reading this article about the keynote presentations at the recent
> Hack in the box conference - http://news.zdnet.co.uk/security/0,100000018=
9,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 bankin=
g
> 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 bil=
ls.
> 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=85 despite the fact that the user had ta=
ken
> 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 fir=
st
> 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 ar=
e
> usually linked to specific urls (Example:
> http://site/stocks?buy=3D100&stock=3Debay) allowing specific actions to b=
e
> performed when requested. If a user is logged into the site and an attack=
er
> tricks their browser into making a request to one of these task urls, the=
n
> 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 H=
TTP
> request data and in this case it is sent from a malicious application tha=
t
> was injected through other means (email) and it perhaps working as a brow=
ser
> 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
>

------=_Part_4612_19088942.1189326015819
Content-Type: text/html; charset=WINDOWS-1252
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

<div>Interesting topic.<br>&nbsp;<br>Like jeff has said, the traditional wa=
y we prevent CSRF cannot help us in this trojan situation. We need a new so=
lution.<br>&nbsp;<br>And the XSS matter, yes, CSRF is usually due to some X=
SS flaws, especially when they combine together, deadly enough. But XSS is =
much more complicated. For my part, it would be better to fouse on the troj=
an.=20
<br>&nbsp;<br>PS: Bedirhan, thanks for your notice:)</div>
<div>PS2: forget Cc again....:(<br><br>&nbsp;</div>
<div><span class=3D"gmail_quote">On 9/7/07, <b class=3D"gmail_sendername">R=
yan Barnett</b> &lt;<a href=3D"mailto:rcbarnett@gmail.com";>rcbarnett@gmail.=
com</a>&gt; wrote:</span>
<blockquote class=3D"gmail_quote" style=3D"PADDING-LEFT: 1ex; MARGIN: 0px 0=
px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">
<div>I was reading this article about the keynote presentations at the rece=
nt Hack in the box conference - <a onclick=3D"return top.js.OpenExtLink(win=
dow,event,this)" href=3D"http://news.zdnet.co.uk/security/0,1000000189,3928=
9141,00.htm" target=3D"_blank">
http://news.zdnet.co.uk/security/0,1000000189,39289141,00.htm </a>.&nbsp; I=
n it, Mikko Hypponen, chief research officer at security company F-Secure, =
states the following about Banking Trojans.&nbsp; I found this interesting =
from a webappsec point of view -
</div>
<blockquote dir=3D"ltr" style=3D"MARGIN-RIGHT: 0px">
<div>&quot;However, these methods don&#39;t address man-in-the-middle attac=
ks or banking Trojans,&quot; he said. &quot;This kind of software silently =
sits on an infected computer for weeks until a user logs online into his ba=
nk to pay some bills. When that happens, the Trojan silently inserts [fake]=
 &#39;bills&#39; without the user&#39;s knowledge [and makes it seem] as th=
ough he is paying his bills.&quot;=20
</div>
<p>From the banks&#39; perspective, the transaction looks legitimate but in=
 fact it is not, Hypponen said. </p>
<p>&quot;Money is then stolen by hackers=85 despite the fact that the user =
had taken precautions to log on to a legitimate website, and the connection=
 [was] secured by encryption,&quot; he said. </p>
<p>According to Hypponen, there is currently no security tool to effectivel=
y protect against banking Trojan exploits. So, he added, the best form of p=
rotection is to stop the malicious code from infecting the PC in the first =
place.=20
</p></blockquote>
<div>While malicious code such as this, that infects user&#39;s computers, =
certainly doesn&#39;t follow the whole &quot;cross-site&quot; portion of CS=
RF, the remainder of the attack vector seems identical - a request was made=
 to a web app that the user did not intend to make.&nbsp; If you look at th=
e common definitions for CSRF this attack still seems to apply from a web a=
pp&#39;s perspective.&nbsp; Such as this portion of the definition -=20
<a onclick=3D"return top.js.OpenExtLink(window,event,this)" href=3D"http://=
www.cgisecurity.com/articles/csrf-faq.shtml#whatis" target=3D"_blank">http:=
//www.cgisecurity.com/articles/csrf-faq.shtml#whatis</a>&nbsp;-</div>
<blockquote dir=3D"ltr" style=3D"MARGIN-RIGHT: 0px">
<div>Cross Site Request Forgery (also known as <a onclick=3D"return top.js.=
OpenExtLink(window,event,this)" href=3D"http://www.cgisecurity.com/articles=
/csrf-faq.shtml" target=3D"_blank"><font color=3D"#810081">XSRF</font></a>,=
 <a onclick=3D"return top.js.OpenExtLink(window,event,this)" href=3D"http:/=
/www.cgisecurity.com/articles/csrf-faq.shtml" target=3D"_blank">
<font color=3D"#810081">CSRF</font></a>, and <a onclick=3D"return top.js.Op=
enExtLink(window,event,this)" href=3D"http://www.cgisecurity.com/articles/c=
srf-faq.shtml" target=3D"_blank"><font color=3D"#810081">Cross Site Referen=
ce Forgery
</font></a>) works by exploiting the trust that a site has for the user. Si=
te tasks are usually linked to specific urls (Example: <a onclick=3D"return=
 top.js.OpenExtLink(window,event,this)" href=3D"http://site/stocks?buy=3D10=
0&amp;stock=3Debay" target=3D"_blank">
http://site/stocks?buy=3D100&amp;stock=3Debay</a>) allowing specific action=
s 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 ur=
ls, then the task is performed and logged as the logged in user.=20
</div></blockquote>
<div>I am interested to hear feedback on this topic as many of the CSRF mit=
igations center around preventing the browser-based infection of the HTTP r=
equest data and in this case it is sent from a malicious application that w=
as injected through other means (email) and it perhaps working as a browser=
 helper object or MITM proxy.=20
</div><span class=3D"sg">
<div>&nbsp;<br>-- <br>Ryan C. Barnett<br>ModSecurity Community Manager<br>B=
reach Security: Director of Application Security Training<br>Web Applicatio=
n Security Consortium (WASC) Member<br>CIS Apache Benchmark Project Lead<br=
>
SANS Instructor, GCIA, GCFA, GCIH, GSNA, GCUX, GSEC<br>Author: Preventing W=
eb Attacks with Apache </div></span></blockquote></div><br>

------=_Part_4612_19088942.1189326015819--