Penetration Testing mailing list archives
RE: Bank pen test
From: "Omar A. Herrera" <omar.herrera () oissg org>
Date: Wed, 8 Mar 2006 19:28:14 -0000
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 ------------------------------------------------------------------------------
Current thread:
- RE: Bank pen test Craig Wright (Mar 06)
- Re: Bank pen test Vaidya (Mar 07)
- <Possible follow-ups>
- RE: Bank pen test Craig Wright (Mar 07)
- RE: Bank pen test Jon Gucinski (Mar 07)
- RE: Bank pen test Craig Wright (Mar 08)
- RE: Bank pen test Craig Wright (Mar 08)
- RE: Bank pen test Craig Wright (Mar 08)
- RE: Bank pen test Omar A. Herrera (Mar 09)
- RE: Bank pen test Bergert, David (Mar 09)