Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com
Re: [Full-disclosure] Defeating Image-Based Virtual Keyboards andPhishing Banks (fwd)

From: Debasis Mohanty (debasis.mohanty.listmailsgmail.com)
Date: Tue Nov 28 2006 - 01:12:11 CST

More than a year Old (3rd August, 2005) -

Defeating CITI-BANK Virtual Keyboard Protection




-----Original Message-----
From: full-disclosure-bounceslists.grok.org.uk
[mailto:full-disclosure-bounceslists.grok.org.uk] On Behalf Of Gadi Evron
Sent: Sunday, November 26, 2006 12:18 PM
To: full-disclosurelists.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.




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

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


A request to the server would look like:

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:

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");

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

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/