Hello,
Further to procrastinating...
I gave Westpac as an example from a bank in the last post. Now they have
changed to a "virtual keypad" (see
https://businessonline.westpac.com.au/esis/Login/SrvPage) to "improve security"
and stop trojans from being able to capture data. Unfortunately there is no
gain other than perception and FUD.
Looking at the page source - no hacking, not even the simple stuff, the java
(ie java script) is not complied. There is a VERY simple form submission. The
keys are mapped -
Table 1 contains numbers ordered from 1 to zero
Table 2 contains letters ordered from A to M
Table 3 contains letters ordered from N to Z
Writing a ***SMALL*** script/trojan to capture the form submission is simple.
So you mix it up, they give the mappings.
Eg
"<TD><input type="button" name="M" tabindex="27" alt="M" onclick="act(34,
this);" class="key" value=" M "></TD>"
I come back and it is "randomised":
"<TD><input type="button" name="M" tabindex="27" alt="M" onclick="act(18,
this);" class="key" value=" M "></TD>"
But it is Stored on the PC. So I send a code - big deal - they map it. I just
need to store the mapping (ie the page source extract) and the form.
They should at LEAST compile the Java into a class file and try to make it a
little more difficult to make a trojan designed to capture the key mappings.
Just displaying the information IN THE CLEAR does not even require any skills
to create a compromise.
(At least Citibank compiles the Java). You include the following in the code:
<SCRIPT LANGUAGE='JAVASCRIPT'>
<!--
function assignEntry()
{
var uP = document.form.pwd.value;
document.form.password.value = "w" + uP;
document.cookie = "checker=cookiesEnabled; path=/; domain=.westpac.com.au";
}
//-->
</SCRIPT>
and
<!--
function prepareSubmit() {
a=document.form.password.value;
b=document.form.halgm.value;
b=b.replace(/\n|\r|\r\n|\n\r/g,"");
document.form.password.value=a+"*"+b;
}
and
<SCRIPT language="JavaScript">
<!--
var malgm="6FWDGTZMISY179R5BCOLQVXNH8P3KEU024JA";
//-->
</SCRIPT>
<input type="hidden" name="halgm"
value="hAlW//lNKdxt9XigOOszWi+H77/0s2p8nglqSJRT2/8Oxb2pc7wDnxZ8N9uGeIB81CZjy3hweaJP
+yXbrnfneSk5Oq6DbAv/fpSDxlMvWlxZ8Y3p+07oSw=="/>
<!--END PWD_AREA-->
Etc
This means you display the mapping and thus the randomisation is useless. The
hash can be stored if you wish, but as the keys can be mapped and the table
captured there is no reason to even bother with this.
So, do [large] banks really care. Well some of the people do, but unfortunately
they are not the ones making the decisions.
This also relates back to the everyone should be securing their systems, well
yes, but should be and are doing so are not the same.
This is a vulnerability. The issue is fixing it will cost money and thus it is
there. The level of risk is not high for the bank and if you do not use public
terminals and have good pracvtices at work and home etc it should be a minimal
risk for the consumer. Many people do use banking in kiosks so.....
Regards,
Craig
Liability limited by a scheme approved under Professional Standards Legislation
in respect of matters arising within those States and Territories of Australia
where such legislation exists.
DISCLAIMER
The information contained in this email and any attachments is confidential. If
you are not the intended recipient, you must not use or disclose the
information. If you have received this email in error, please inform us
promptly by reply email or by telephoning +61 2 9286 5555. Please delete the
email and destroy any printed copy.
Any views expressed in this message are those of the individual sender. You may
not rely on this message as advice unless it has been electronically signed by
a Partner of BDO or it is subsequently confirmed by letter or fax signed by a
Partner of BDO.
BDO accepts no liability for any damage caused by this email or its attachments
due to viruses, interference, interception, corruption or unauthorised access.
