RE: Bank pen test

From: Craig Wright (cwright@bdosyd.com.au)
Date: Wed Mar 08 2006 - 04:35:51 EST


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.



This archive was generated by hypermail 2.1.7 : Sat Apr 12 2008 - 10:55:38 EDT