From: Omar A. Herrera (omar.herrera@oissg.org)
Date: Wed Mar 08 2006 - 14:28:14 EST
Hi Craig,
Well since you mentioned it...
> -----Original Message-----
> From: Craig Wright [mailto:cwright@bdosyd.com.au]
>
> 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
> ...
> 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.....
Basically, to establish a secure communication you need: credentials for
authentication, a secure channel (i.e. a robust method to ensure
confidentiality and integrity) and a secure terminal (maybe I should also
say a secure server ;-) ).
Security personnel in most banks know this, but for several reasons
(including some business driven decisions as you point out) they tend to
ignore the security of terminals.
A multipurpose machine, to which more than one individual has potential
access, that is able to run several, complex, pieces of software and has a
lot of interactions (i.e. I/O devices) with the external world is not
precisely what most of us would consider a secure terminal. But that
definition fits perfectly personal computers used as terminals in these
schemes.
You can add as much complexity as you want but leaving critical parts of the
security in the scheme is not going to hold for long. In all these
situations you still end up with a piece of code in charge of encoding or
encrypting your communications resting in an untrusted, potentially
compromised, environment: the client's PC. Simply put, if someone has
compromised that PC and has total control over it, no matter how many tricks
like this we try to employ, the attacker can always get through (if he is
interested and technically capable of doing it). Pretending that most of the
client's computers will be properly secured is unrealistic and unfeasible,
from my personal point of view.
Banks that are serious about security recognize that they should move at
least part of this security (i.e. the capability of authentication and
authorization of at least some transactions) to an external device, and so
they make use tokens and smartcards. If correctly implemented, they should
at least reach a level of security that allows attackers to "see but not
touch" the information. In that sense, information leaks are very difficult
to stop, but you can still prevent unauthorized transactions and queries.
Of course, inappropriate implementation might lead to something similar to
what happened recently with Fedex Kinko. Their mistake was, in my opinion,
to believe that terminals were trusted (along with the communication with
the smartcards, within these terminals). Even if the smartcard was able to
store the amount of money securely and prevent any modifications without the
proper pin, it just turned out that there was an insecure communication
between the smartcard and the terminal (reader) where the pin to change
information was transmitted insecurely.
Impact is something that banks should be more aware of and, I don't think
they are putting the right values in the cost-benefit equation right now.
The Fedex Kinko case (even if it is not precisely an e-banking case) should
at least give us an idea of the potential impact for banks in situations
like the one you point out.
This kind of assessment should be part of Pentest proposals for financial
institutions that use some kind of e-banking applications or have remote
access to critical systems for some of their employees. But to be honest, I
don't think most pentesters include this within the scope of their proposals
right now. I would even dare to say that this is at least as important
(probably more in some cases) as the traditional network perimeter
assessments from the external network and the internal network assessments.
Breaching the external perimeter will leave the attacker somewhere in the
DMZ or the internal network where most of the time there will be still other
layers of protection and sensors to stop/detect it. Compromising a client's
computer to piggyback into his/her account or steal authentication
credentials will allow attackers to get straight to the money. After this,
the only thing that might put into alert the bank would be behavioural
analysis systems that detect changes in user activity patterns (if they
exist at that point, they usually exist for analyzing credit/debit card
usage, but not for activities inside the e-banking network, which is assumed
to be safe) or the user himself, when he/she realizes something is wrong.
Kind regards,
Omar A. Herrera
------------------------------------------------------------------------------
This List Sponsored by: Cenzic
Concerned about Web Application Security?
As attacks through web applications continue to rise, you need to proactively
protect your applications from hackers. Cenzic has the most comprehensive
solutions to meet your application security penetration testing and
vulnerability management needs. You have an option to go with a managed
service (Cenzic ClickToSecure) or an enterprise software (Cenzic Hailstorm).
Download FREE whitepaper on how a managed service can help you:
http://www.cenzic.com/news_events/wpappsec.php
And, now for a limited time we can do a FREE audit for you to confirm your
results from other product. Contact us at request@cenzic.com
------------------------------------------------------------------------------
This archive was generated by hypermail 2.1.7 : Sat Apr 12 2008 - 10:55:39 EDT