|Hooked by phishing: SC Magazine : Blog : Home|
First Published: SC Magazine
A pressing concern for many of my financial clients at the moment relates to how they should be responding to phishing attacks. While many of the largest retail banks have already identified a number of phishing scams targeted at their own customer base, some of the smaller or more specialist financial companies who have not yet been targeted (but fear they will be eventually) are trying to understand the threat and identify steps they can take to protect their own clientele.
Although there have been numerous articles and briefings about the threat - describing in infinite detail how fundamental flaws in which emails can be spoofed or forged should be blamed, and how ossification flaws in client web browsers make for a threat combination that is very difficult to protect against – very little advice has propagated its way to the development personnel and technical architects responsible for designing and deploying their organisations Internet visible applications.
Phishing attacks exploit weaknesses in the standard email protocols that allow attackers to send forth emails impersonating a financial organisation (using the same techniques as Spammers and, in many cases, even utilising the same shared lists of email addresses) while also abusing the recipients trust in the organisation - causing them to supply confidential information to the attacker through a corrupted or fake instance of the web site.
As with any electronic threat, there are multiple vectors for possible attack. While phishing attacks rely heavily upon social engineering aspects of forged emails to be statistically successful, there are still a number of things that I can advise my clients to undertake to protect themselves. This advice extends beyond relying on third-parties to correct the standards, educate their technology-challenged clientele, or even police against each new phishing scam. Instead, they should spend some time focusing on the things which they themselves can do to their applications and systems.
In the first instance, my clients need to ensure that they have deployed the standard assortment of security mechanisms which are designed to protect their customers from attacks based around information leakage and threats associated with the use of untrusted or shared computers (such as those found in Internet Café’s) – and actually have them verified as implemented correctly. This includes multi-tier login processes capable of thwarting automated attacks and common key-logging attack methods, as well as investing in robust input validation processes.
While not necessarily technically challenging from an application development perspective, these standard protection mechanisms represent the front-line in application security. It is unfortunate that so many organisations fail to implement these standard security features successfully.
Consider the benefits of a well thought-out and implemented two-tier login process. In the first instance, the client is prompted for at least two personal pieces of information (e.g. their Surname and their Account Number). In order to combat automated brute force agents, after successfully supplying this information, the client is then asked to supply at least two further pieces of information (e.g. a supplied Password and a shared secret word) on another page. For combating key-logging devices, at least one of these personal identifiers should be supplied via the mouse – such as using drop-down boxes to select the letters that comprise their shared secret. To combat network sniffing attacks, only parts of the shared secret should be required (e.g. the 2nd, 4th and 9th letters of the secret word) – and these sequences should be randomly selected each time.
However, to aid in the defence against common phishing attacks that fake the organisations web front-end and mimic functionality to capture all this personal information, an additional security mechanism is required. I’ve found that the simplest procedure is to get the client to upload a picture that is unique (or choose one that means something to them) when they first create their Internet login account. The client is then informed that the picture has become a shared secret, and that this graphic will always be presented to them when they reach the second level of their login process (as a watermark for instance). Therefore the absence of their picture means that the web application is being impersonated. I recommend the use of a graphic as opposed to a pass phrase as this prevents confusion with passwords and “personalises” the experience for the client.
I find it interesting that, after several years carefully explaining the security risks associated with cross-site scripting and code injection attacks, phishing attacks prove victorious in driving that point home. Luckily, with very little effort, many organisations can discover and remove the validation security flaws that allow these kinds of attack.
Failures with web application URLs that allow scriptable components or third-party URL information to be incorporated in them often result in confusion for the organisations clientele and represent an easily exploitable attack vector for the phisher. For example, consider a web application that has a component that redirects their clientele to an affiliate site which can be abused in the following way: http://www.trustedbank.com/affiliate.html?url=http://fake.attacker.com – of course the “fake.attacker.com” could be obfuscated using all kinds of methods. Proper - robust and intelligent - input validation processes are required.
There is no shortcut to this process. When asked, many clients know that certain fields in their web application do not validate content at the server properly – but have failed in the past to see how this could be turned into an attack. Normally a quick demonstration that injects a little client-side code into the returned page which logs all key presses and re-draws the insecure padlock of the browser to look like it is now “secure” is all that is required. It gets a bit tedious when a typical web-based financial application has dozens if not hundreds of these failures.
In essence, there a number of things that many organisations can undertake to reduce the probability of attack and the vectors for attack. Clients that implement these simple changes will probably find that the Phishers turn their attention to another organisations “low hanging fruit” – at least it won’t be their organisation having to release yet another advisory email to all their customers.