Message-ID: <Pine.LNX.4.21.0611271634240.8024-100000@linuxbox.org>
Date: Mon, 27 Nov 2006 16:34:58 -0600 (CST)
From: Gadi Evron <ge@...uxbox.org>
To: Debasis Mohanty <debasis.mohanty.listmails@...il.com>
Cc: full-disclosure@...ts.grok.org.uk
Subject: Re: 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.html
> 
> 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.

> 
> 
> 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