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

[<Glenn.Everhart@xxxxxxxxx>]

------_=_NextPart_001_01C7F3DA.974DFA30
Content-Type: text/plain;
	charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

A cell phone can be infected also, but a second token where the user does s=
omething - selection, e=2Eg=2E - to=0D=0Apick display digits according to a=
mount, or otherwise convolve token display with amount - would be able to=
=0D=0Aprovide the desired signing properties regardless of the compromised =
middle pieces=2E If data other than amount=0D=0Awere being messed up, addit=
ional signing might be needed=2E Anything connected to the network directly=
 and=0D=0Auser programmable must however be suspect=2E=0D=0A =0D=0APicking =
digits btw is a similar operation to the way people have picked out words o=
n telephone keypads for=0D=0Aages=2E=0D=0A =0D=0AThere are other ways to ap=
proach this too, such as trying to remotely test the integrity of the user =
system, which in=0D=0Athe limit of many queries can be made very very hard =
to fake - if the query system itself doesn't turn into a worse=0D=0Asecurit=
y hole=2E=0D=0A =0D=0AIt is predictable though that any PC or cell platform=
 that gets popular is likely to have such malware developed to=0D=0Atarget =
it=2E The problem cannot really be avoided=2E=0D=0A =0D=0AGlenn Everhart=0D=
=0A =0D=0A-----Original Message-----=0D=0AFrom: Somers Raf [mailto:btech2bu=
gtraq@telenet=2Ebe]=0D=0ASent: Monday, September 10, 2007 1:30 PM=0D=0ATo: =
websecurity@webappsec=2Eorg=0D=0ASubject: Re: [WEB SECURITY] Similarity bet=
ween Banking Trojans and CSRF=0D=0A=0D=0A=0D=0AIf you got a trojan installe=
d on the users machine, that is capable of altering HTTP/HTTPS traffic, let=
s say which acts as a proxy server, it should very well be capable to alter=
 beneficiary account number and amount transfered in the request send to th=
e server and alter the account number and amount in the responding feedback=
 from the server=2E=0D=0AImagine any token/ auth setup you utilise that get=
s send to the server along with the account of the benificiary and the amou=
nt=2E trojan acting as MITM alters account number and amount and passes the=
 request on to the server, blasting the token or challenge/response securit=
y to oblivion=0D=0AThen it no longer matters what kind of security you put =
on the page=2E Once you have a trojan on the client computer, all security =
becomes nill, no matter how you look at it=2E=0D=0AThe only security possib=
le, would be for the end user to interact with the server without utilising=
 his client machine, but by using a secund medium such as a phone or mobile=
=2E=0D=0A=0D=0A =0D=0AR=2ESomers=0D=0A =0D=0A=0D=0A----- Original Message -=
---- =0D=0AFrom: application=2Esecure  <mailto:application=2Esecure@gmail=
=2Ecom> application=2Esecure =0D=0ATo: rcbarnett@gmail=2Ecom ; websecurity@=
webappsec=2Eorg =0D=0ASent: Monday, September 10, 2007 4:57 PM=0D=0ASubject=
: RE: [WEB SECURITY] Similarity between Banking Trojans and CSRF=0D=0A=0D=
=0AI'm working on this topic(trojan) for a few month ago=2E=0D=0AAll my ref=
lections are done with an application security perspective and without user=
 awareness=2E=0D=0A=0D=0AI think the big difference between CSRF and trojan=
 attacks is that the trojans have access to the content of the http(s) traf=
fic=2E =0D=0AHe can interpret the code and modify it=2E=0D=0ACSRF only expl=
oits the targeted functionality request=85 =0D=0ATrojans create the request=
; handle and interpret the response; show what he want to the user and crea=
te a new request based on the input of the user and the interpreted respons=
e=2E =0D=0A=0D=0AThe only way to create such kind of attack without a troja=
n is maybe to merge XSS and CSRF=2E=0D=0AThe XSS attacks can help you to pu=
t in place a kind of application controller which manages the application f=
low in place of the user=2E =0D=0A=0D=0AAbout a protection against trojan a=
ttacks (or an XSS+CSRF application controller):=0D=0AOf course, injecting a=
 token in the request parameters (even with a dynamic name) can not help yo=
u because the attacker scans the content of the response and can =0D=0Aretr=
ieve the value of this token=2E=0D=0A=0D=0ACurrently, the only good protect=
ion (I think) is to use 2 factors authentication and 2 factors signature fo=
r each transactions with a difference between signature and authentication=
=2E =0D=0A=0D=0AThe logon should be a challenge response approach=2E=0D=0AA=
ll signatures must be WYSIWYS : what you see is what you sign=2E=0D=0AFor e=
xample, in case of a transfer, the user has to sign the target account numb=
er and the amount of the transfer=2E =0D=0A=3D> this is very important to m=
ake the difference between authentication and signature! (if not, a logon f=
ailure can be used to ask to the user to sign the hidden transaction)=0D=0A=
=0D=0AThis is also very important that all your signatures in your applicat=
ion are WYSIWYS=85 Why? =0D=0ABecause if one of them is not WYSIWYS (signin=
g meaningless data), the trojan can use this functionality to inject other =
signatures data from other functionalities of your application and the user=
 will sign it because it's meaningless=2E =0D=0AThe hidden functionality wi=
ll be executed in place of the one asked by the user=2E=0D=0A=0D=0AA little=
 bit about the captcha solution: =0D=0Athink about the fact that MITM are n=
ot always robots=85 sometimes it can be humans organization which intercept=
s hacked users and do evil=2E =0D=0AIf it's a robot, the captcha can be bro=
ken by injecting OCR library in the trojan=85 I'm agree that it raises the =
bar but it's not THE solution)=0D=0A=0D=0A=0D=0AI hope this topic will cont=
inue because it's very interesting to think about solutions and share idea =
of all security guys ;) =0D=0A=0D=0A=0D=0A=0D=0A=0D=0A---------------------=
--------------------=0D=0AThis transmission may contain information that is=
 privileged,=0Aconfidential, legally privileged, and/or exempt from disclos=
ure=0Aunder applicable law=2E  If you are not the intended recipient, you=
=0Aare hereby notified that any disclosure, copying, distribution, or=0Ause=
 of the information contained herein (including any reliance=0Athereon) is =
STRICTLY PROHIBITED=2E  Although this transmission and=0Aany attachments ar=
e believed to be free of any virus or other=0Adefect that might affect any =
computer system into which it is=0Areceived and opened, it is the responsib=
ility of the recipient to=0Aensure that it is virus free and no responsibil=
ity is accepted by=0AJPMorgan Chase & Co=2E, its subsidiaries and affiliate=
s, as=0Aapplicable, for any loss or damage arising in any way from its use=
=2E=0A If you received this transmission in error, please immediately=0Acon=
tact the sender and destroy the material in its entirety,=0Awhether in elec=
tronic or hard copy format=2E Thank you=2E
------_=_NextPart_001_01C7F3DA.974DFA30
Content-Type: text/html;
	charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4=2E0 Transitional//EN">=0D=0A<HTML=
><HEAD>=0D=0A<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; charse=
t=3DWindows-1252">=0D=0A=0D=0A=0D=0A<META content=3D"MSHTML 6=2E00=2E2900=
=2E3157" name=3DGENERATOR>=0D=0A<STYLE></STYLE>=0D=0A</HEAD>=0D=0A<BODY bgC=
olor=3D#ffffff>=0D=0A<DIV><SPAN class=3D773372718-10092007><FONT face=3DAri=
al color=3D#0000ff size=3D2>A cell =0D=0Aphone can be infected also, but a =
second token where the user does something - =0D=0Aselection, e=2Eg=2E - to=
</FONT></SPAN></DIV>=0D=0A<DIV><SPAN class=3D773372718-10092007><FONT face=
=3DArial color=3D#0000ff size=3D2>pick =0D=0Adisplay digits according to am=
ount, or otherwise convolve token display with =0D=0Aamount - would be able=
 to</FONT></SPAN></DIV>=0D=0A<DIV><SPAN class=3D773372718-10092007><FONT fa=
ce=3DArial color=3D#0000ff =0D=0Asize=3D2>provide the desired signing prope=
rties regardless of the compromised =0D=0Amiddle pieces=2E If data other th=
an amount</FONT></SPAN></DIV>=0D=0A<DIV><SPAN class=3D773372718-10092007><F=
ONT face=3DArial color=3D#0000ff size=3D2>were =0D=0Abeing messed up, addit=
ional signing might be needed=2E Anything connected to the =0D=0Anetwork di=
rectly and</FONT></SPAN></DIV>=0D=0A<DIV><SPAN class=3D773372718-10092007><=
FONT face=3DArial color=3D#0000ff size=3D2>user =0D=0Aprogrammable must how=
ever be suspect=2E</FONT></SPAN></DIV>=0D=0A<DIV><SPAN class=3D773372718-10=
092007><FONT face=3DArial color=3D#0000ff =0D=0Asize=3D2></FONT></SPAN>&nbs=
p;</DIV>=0D=0A<DIV><SPAN class=3D773372718-10092007><FONT face=3DArial colo=
r=3D#0000ff =0D=0Asize=3D2>Picking digits btw is a similar operation to the=
 way people have picked =0D=0Aout words on telephone keypads for</FONT></SP=
AN></DIV>=0D=0A<DIV><SPAN class=3D773372718-10092007><FONT face=3DArial col=
or=3D#0000ff =0D=0Asize=3D2>ages=2E</FONT></SPAN></DIV>=0D=0A<DIV><SPAN cla=
ss=3D773372718-10092007><FONT face=3DArial color=3D#0000ff =0D=0Asize=3D2><=
/FONT></SPAN>&nbsp;</DIV>=0D=0A<DIV><SPAN class=3D773372718-10092007><FONT =
face=3DArial color=3D#0000ff size=3D2>There =0D=0Aare other ways to approac=
h this too, such as trying to remotely test the =0D=0Aintegrity of the user=
 system, which in</FONT></SPAN></DIV>=0D=0A<DIV><SPAN class=3D773372718-100=
92007><FONT face=3DArial color=3D#0000ff size=3D2>the =0D=0Alimit of many q=
ueries can be made very very hard to fake - if the query system =0D=0Aitsel=
f doesn't turn into a worse</FONT></SPAN></DIV>=0D=0A<DIV><SPAN class=3D773=
372718-10092007><FONT face=3DArial color=3D#0000ff =0D=0Asize=3D2>security =
hole=2E</FONT></SPAN></DIV>=0D=0A<DIV><SPAN class=3D773372718-10092007><FON=
T face=3DArial color=3D#0000ff =0D=0Asize=3D2></FONT></SPAN>&nbsp;</DIV>=0D=
=0A<DIV><SPAN class=3D773372718-10092007><FONT face=3DArial color=3D#0000ff=
 size=3D2>It is =0D=0Apredictable though that any PC or cell platform that =
gets popular is likely to =0D=0Ahave such malware developed to</FONT></SPAN=
></DIV>=0D=0A<DIV><SPAN class=3D773372718-10092007><FONT face=3DArial color=
=3D#0000ff size=3D2>target =0D=0Ait=2E The problem cannot really be avoided=
=2E</FONT></SPAN></DIV>=0D=0A<DIV><SPAN class=3D773372718-10092007><FONT fa=
ce=3DArial color=3D#0000ff =0D=0Asize=3D2></FONT></SPAN>&nbsp;</DIV>=0D=0A<=
DIV><SPAN class=3D773372718-10092007><FONT face=3DArial color=3D#0000ff siz=
e=3D2>Glenn =0D=0AEverhart</FONT></SPAN></DIV>=0D=0A<DIV><SPAN class=3D7733=
72718-10092007></SPAN>&nbsp;</DIV>=0D=0A<DIV class=3DOutlookMessageHeader d=
ir=3Dltr align=3Dleft><FONT face=3DTahoma =0D=0Asize=3D2>-----Original Mess=
age-----<BR><B>From:</B> Somers Raf =0D=0A[mailto:btech2bugtraq@telenet=2Eb=
e]<BR><B>Sent:</B> Monday, September 10, 2007 =0D=0A1:30 PM<BR><B>To:</B> w=
ebsecurity@webappsec=2Eorg<BR><B>Subject:</B> Re: [WEB =0D=0ASECURITY] Simi=
larity between Banking Trojans and CSRF<BR><BR></FONT></DIV>=0D=0A<DIV><FON=
T face=3DArial size=3D2>If you got a trojan installed on the users machine,=
 =0D=0Athat is capable of altering HTTP/HTTPS traffic, lets say which acts =
as a proxy =0D=0Aserver, it should very well be capable to alter beneficiar=
y account number and =0D=0Aamount transfered in the request send to the ser=
ver and alter the account number =0D=0Aand amount in the responding feedbac=
k from the server=2E</FONT></DIV>=0D=0A<DIV><FONT face=3DArial size=3D2>Ima=
gine any token/ auth setup you utilise that gets =0D=0Asend to the server a=
long with the account of the benificiary and the amount=2E =0D=0Atrojan act=
ing as MITM alters account number and amount and passes the request on =0D=
=0Ato the server,&nbsp;blasting the token or challenge/response security to=
 =0D=0Aoblivion</FONT></DIV>=0D=0A<DIV><FONT face=3DArial size=3D2>Then it =
no longer matters what kind of security you =0D=0Aput on the page=2E Once y=
ou have a trojan on the client computer, all security =0D=0Abecomes nill, n=
o matter how you look at it=2E</FONT></DIV>=0D=0A<DIV><FONT face=3DArial si=
ze=3D2>The only security possible, would be for the end =0D=0Auser to inter=
act with the server without utilising his client machine, but by =0D=0Ausin=
g a secund medium such as a phone or mobile=2E<BR></FONT></DIV>=0D=0A<DIV><=
FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>=0D=0A<DIV><FONT face=3DArial=
 size=3D2>R=2ESomers</FONT></DIV>=0D=0A<DIV><FONT face=3DArial size=3D2></F=
ONT>&nbsp;</DIV>=0D=0A<BLOCKQUOTE =0D=0Astyle=3D"PADDING-RIGHT: 0px; PADDIN=
G-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT=
: 0px">=0D=0A  <DIV style=3D"FONT: 10pt arial">----- Original Message -----=
 </DIV>=0D=0A  <DIV =0D=0A  style=3D"BACKGROUND: #e4e4e4; FONT: 10pt arial;=
 font-color: black"><B>From:</B> =0D=0A  <A title=3Dapplication=2Esecure@gm=
ail=2Ecom =0D=0A  href=3D"mailto:application=2Esecure@gmail=2Ecom";>applicat=
ion=2Esecure =0D=0A  application=2Esecure</A> </DIV>=0D=0A  <DIV style=3D"F=
ONT: 10pt arial"><B>To:</B> <A title=3Drcbarnett@gmail=2Ecom =0D=0A  href=
=3D"mailto:rcbarnett@gmail=2Ecom";>rcbarnett@gmail=2Ecom</A> ; <A =0D=0A  ti=
tle=3Dwebsecurity@webappsec=2Eorg =0D=0A  href=3D"mailto:websecurity@webapp=
sec=2Eorg">websecurity@webappsec=2Eorg</A> </DIV>=0D=0A  <DIV style=3D"FONT=
: 10pt arial"><B>Sent:</B> Monday, September 10, 2007 4:57 =0D=0A  PM</DIV>=
=0D=0A  <DIV style=3D"FONT: 10pt arial"><B>Subject:</B> RE: [WEB SECURITY] =
Similarity =0D=0A  between Banking Trojans and CSRF</DIV>=0D=0A  <DIV><BR><=
/DIV>I'm working on this topic(trojan) for a few month ago=2E<BR>All =0D=0A=
  my reflections are done with an application security perspective and with=
out =0D=0A  user awareness=2E<BR><BR>I think the big difference between CSR=
F and trojan =0D=0A  attacks is that the trojans have access to the content=
 of the http(s) traffic=2E =0D=0A  <BR>He can interpret the code and modify=
 it=2E<BR>CSRF only exploits the =0D=0A  targeted functionality request=85 =
<BR>Trojans create the request; handle and =0D=0A  interpret the response; =
show what he want to the user and create a new request =0D=0A  based on the=
 input of the user and the interpreted response=2E <BR><BR>The only =0D=0A =
 way to create such kind of attack without a trojan is maybe to merge XSS a=
nd =0D=0A  CSRF=2E<BR>The XSS attacks can help you to put in place a kind o=
f application =0D=0A  controller which manages the application flow in plac=
e of the user=2E =0D=0A  <BR><BR>About a protection against trojan attacks =
(or an XSS+CSRF application =0D=0A  controller):<BR>Of course, injecting a =
token in the request parameters (even =0D=0A  with a dynamic name) can not =
help you because the attacker scans the content =0D=0A  of the response and=
 can <BR>retrieve the value of this =0D=0A  token=2E<BR><BR>Currently, the =
only good protection (I think) is to use 2 =0D=0A  factors authentication a=
nd 2 factors signature for each transactions with a =0D=0A  difference betw=
een signature and authentication=2E <BR><BR>The logon should be a =0D=0A  c=
hallenge response approach=2E<BR>All signatures must be WYSIWYS : what you =
see =0D=0A  is what you sign=2E<BR>For example, in case of a transfer, the =
user has to sign =0D=0A  the target account number and the amount of the tr=
ansfer=2E <BR>=3D&gt; this is =0D=0A  very important to make the difference=
 between authentication and signature! =0D=0A  (if not, a logon failure can=
 be used to ask to the user to sign the hidden =0D=0A  transaction)<BR><BR>=
This is also very important that all your signatures in =0D=0A  your applic=
ation are WYSIWYS=85 Why? <BR>Because if one of them is not WYSIWYS =0D=0A =
 (signing meaningless data), the trojan can use this functionality to injec=
t =0D=0A  other signatures data from other functionalities of your applicat=
ion and the =0D=0A  user will sign it because it's meaningless=2E <BR>The h=
idden functionality will =0D=0A  be executed in place of the one asked by t=
he user=2E<BR><BR>A little bit about =0D=0A  the captcha solution: <BR>thin=
k about the fact that MITM are not always =0D=0A  robots=85 sometimes it ca=
n be humans organization which intercepts hacked users =0D=0A  and do evil=
=2E <BR>If it's a robot, the captcha can be broken by injecting OCR =0D=0A =
 library in the trojan=85 I'm agree that it raises the bar but it's not THE=
 =0D=0A  solution)<BR><BR><BR>I hope this topic will continue because it's =
very =0D=0A  interesting to think about solutions and share idea of all sec=
urity guys ;) =0D=0A</BLOCKQUOTE></BODY></HTML>=0D=0A=0D=0A<P><hr size=3D1>=
</P>=0D=0A<P>=0D=0AThis transmission may contain information that is privil=
eged, confidential, legally privileged, and/or exempt from disclosure under=
 applicable law=2E  If you are not the intended recipient, you are hereby n=
otified that any disclosure, copying, distribution, or use of the informati=
on contained herein (including any reliance thereon) is STRICTLY PROHIBITED=
=2E  Although this transmission and any attachments are believed to be free=
 of any virus or other defect that might affect any computer system into wh=
ich 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=2E, its subsidiaries and affiliates, as applicable, for any los=
s or damage arising in any way from its use=2E  If you received this transm=
ission in error, please immediately contact the sender and destroy the mate=
rial in its entirety, whether in electronic or hard copy format=2E Thank yo=
u=2E=0D=0A</P>
------_=_NextPart_001_01C7F3DA.974DFA30--