Date: Tue, 28 Nov 2006 07:24:56 -0800
From: "Debasis Mohanty" <debasis.mohanty.listmails@...il.com>
To: "'Gadi Evron'" <ge@...uxbox.org>
Cc: full-disclosure@...ts.grok.org.uk
Subject: Re: Defeating Image-Based Virtual Keyboards
	andPhishing Banks (fwd)

-----Original Message-----
From: Gadi Evron [mailto:ge@...uxbox.org] 
Sent: Monday, November 27, 2006 2:35 PM
To: Debasis Mohanty
Cc: full-disclosure@...ts.grok.org.uk
Subject: Re: [Full-disclosure] Defeating Image-Based Virtual Keyboards
andPhishing Banks (fwd)

On Mon, 27 Nov 2006, Debasis Mohanty wrote:
> More than a year Old (3rd August, 2005) -
> 
> Defeating CITI-BANK Virtual Keyboard Protection 
> http://archives.neohapsis.com/archives/fulldisclosure/2005-08/0142.htm
> l
> 
> http://hackingspirits.com/vuln-rnd/Defeat-CitiBank-VK.zip
> 
> http://xforce.iss.net/xforce/xfdb/21727

- I hear buffer overflows were invented quite a few years back, too. :)

- That makes most new bof's irrelevant!

-	Gadi.

Nah !! They have just became so common to hear or read ;)

Bty - The last post was not meant to get into somekind of argument but to
point out a different method to defeat such mechanism.


> 
> 
> Regards,
> -d
> 
> 
> 
> -----Original Message-----
> From: full-disclosure-bounces@...ts.grok.org.uk
> [mailto:full-disclosure-bounces@...ts.grok.org.uk] On Behalf Of Gadi 
> Evron
> Sent: Sunday, November 26, 2006 12:18 PM
> To: full-disclosure@...ts.grok.org.uk
> Subject: [Full-disclosure] Defeating Image-Based Virtual Keyboards 
> andPhishing Banks (fwd)
> 
> Copied from a post by Noam Rathaus on the SecuriTeam Blogs, following 
> up a post by HispaSec. This is about breaking virtual keyboards 
> implementations, and the encryption some of them use (most of them 
> send the data in clear text with the image). HispaSec was a reference by
which we found the banks'
> site as one using a virtual keyboard.
> 
> http://blogs.securiteam.com/index.php/archives/678
> 
> http://hispasec.com/laboratorio/cajamurcia_en.htm
> 
> 	Gadi.
> 
> Quoting:
> Recently, I stumbled upon a post by HispaSec showing off a screen shot 
> trojan (http://hispasec.com/laboratorio/cajamurcia_en.htm) which 
> nicely showed how a trojan horse can, utilizing a key stroke capture 
> and screenshot capture, grab a user's PIN number, fairly easily, and 
> wondered why are they taking this approach when the PIN numbers can be 
> easily retrieved by sniffing the data sent by the user to the banking 
> site, even though they are "encrypted".
> 
> Image based keyboard (or virtual keyboards) were invented to make life 
> harder for banking or phishing trojan horses (specifically key-stroke 
> loggers or key loggers), some even suggested they be used specifically 
> to avoid these trojan horses. The bad guys adapted to this technology 
> and escalated. Now the trojan horses take screenshots of where the 
> mouse pointer is to determine what number they clicked on. Thing is, 
> it is often unnecessary as in most implementations of this technique 
> that we looked into (meaning, not all) it was flawed.
> 
> Instead of sending the remote image and waiting for the key-stroke 
> information to be sent back to the server (the technique which the 
> screenshots for pointer location on-click described above was used) 
> some banks send the PIN number in cleartext, while others encrypt 
> them, one such example is cajamurcia. Even when the encryption is 
> used, banks tend to implement it badly making it easy to recover the 
> PIN number from the encrypted form.
> 
> I investigated a bit more on how cajamurcia handles such PIN strokes 
> (with virtual keyboards) and I noticed something strange, they take 
> the timestamp of their server (cajamurcia) and send it to you - this 
> already posses a security problem - and this timestamp is then used to 
> encrypt the PIN number you entered.
> 
> This would have been a good idea if the timestamp was not sent back to 
> the server, making it hard or semi-hard to guess the timestamp used to 
> encrypt the data, but at the same time making it harder for the server 
> to know what timestamp was provided to the client (unless they store 
> it inside their session information). Anyhow, as it is sent back to 
> the server, we have everything we need to decrypt the data (PIN number).
> 
> PoC:
> 
> A request to the server would look like:
> 
> OPERACION=0002& CAJA=2043& CAMINO=2043& PGDESTI=CORP& BROKER=SI& 
> VRS=001& PAN=2043123456& SELLO=1610061555560000012569& CL=1161006956& 
> PINV3=si& PANA=2043& PANB=123456& PIN=BBCB6E341C56C6B2& IDIOMA=01
> 
> We are only interested in PIN=BBCB6E341C56C6B2 and CL=1161006956, CL 
> being the timestamp and PIN being the encrypted form of the PIN 
> number. If we feed these into the following JS code:
> 
> https://intelvia.cajamurcia.es/2043/01/scripts/MOD.js
> function hexToString (h) {
> var r = "";
> for (var i= (h.substr(0, 2)=="0x")?2:0; i lowerthan h.length; i+=2) { 
> r += String.fromCharCode (parseInt (h.substr (i, 2), 16)); } return r; 
> } calcula = '1161006956'; ciphertext = 
> hexToString('0xBBCB6E341C56C6B2');
> var cleartext = des (calcula.substr(2,8), ciphertext, 0, 1, 
> "00000000"); console.debug(cleartext);
> 
> We will get our original PIN number. This isn't necessarily easier as 
> it requires data capture, which isn't always easy, but screen captures 
> usually require either an OCR, or manual labor, which the above code does
not.
> 
> One needs to remember that Javascript (or any client-side code and
> information) is indeed on the client's side and under the client's
control.
> An attacker can kick it aside, or learn to emulate it and attack it - 
> manipulate it. Client-side encryption where the code and key are 
> visible is pointless. No matter how much obfuscation or cross-frame 
> and cross-file scripting is used, calling for different functions and 
> parameters, nor how many functions you obfuscate your code through, it 
> can be read and maniuplated.
> 
> We made several email and phone attempts over the past couple of 
> months to reach cajamurcia  and report this security issue to them. 
> Gadi Evron even asked a couple of folks in Spain to help with 
> contacting them by phone, even speaking directly to security folks there.
We were unsuccessful.
> 
> The bank is already under attack by the over-kill screenshot trojan
horses.
> We release this information in full disclosure in the hope many online 
> commerce sites using similar techniques or even sending the 
> information in the clear will fix their implementations of the virtual 
> keyboard Click-Me Number-Images Schemes. These are broken by the use 
> of the trojan horses we discussed, but that's a whole other story.
> 
> Noam Rathaus
> 
> _______________________________________________
> Full-Disclosure - We believe in it.
> Charter: http://lists.grok.org.uk/full-disclosure-charter.html
> Hosted and sponsored by Secunia - http://secunia.com/
> 
> _______________________________________________
> Full-Disclosure - We believe in it.
> Charter: http://lists.grok.org.uk/full-disclosure-charter.html
> Hosted and sponsored by Secunia - http://secunia.com/
> 

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

Powered by blists - more mailing lists