[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <e1e1d5f405080516112964eae7@mail.gmail.com>
Date: Fri, 5 Aug 2005 15:11:25 -0800
From: Daniel Bonekeeper <thehazard@...il.com>
To: Debasis Mohanty <debasis@...kingspirits.com>
Cc: bugtraq@...urityfocus.com
Subject: Re: Defeating Citi-Bank Virtual Keyboard Protection
First, seems that this kind of "virtual keybord" is, by design, weak.
The data posted to the webserver is the same as the content on the
IPIN field (there is no such a encoding or another thing to mask what
was typed). A more secure example of a virtual keyboard can be found
at:
https://www2.bancobrasil.com.br/aapf/aai/login.pbk
On this form, the "virtual keyboard" is a java applet that can receive
a variable ammount of digits, and when a POST is requested, the typed
data is encoded by someway... So, a PIN like "123456" is sent as
"EISYWb", as we can see at "senhaConta":
POST /aapf/aai/login.pbk HTTP/1.1
Host: www2.bancobrasil.com.br
Content-Type: application/x-www-form-urlencoded
Content-Length: 169
titular=01&numeroContratoOrigem=431231&dependenciaOrigem=3123123123&senhaConta=EISYWb&botaoOk.x=&numCod=2&valorContr=4&botaoEntra.x=20&botaoEntra.y=8&paginaComErro=false
And after that, if we post the same PIN, we're gonna get something
different like "EIQTUe", which means that neither looking at the HTML
source code, look for field values, hook the keyboard of trap the data
that is being posted will work in that case. It's not a 100% safe
method, but is safer than the Indian CitiBank virtual keyboard.
--
# (perl -e "while (1) { print "\x90"; }") | dd of=/dev/evil
Powered by blists - more mailing lists