Vulnerabilities are discovered in software on an extremely regular basis. Sometimes it’s the internal team or an external penetration testing team which discovers them and informs the developers. Sometimes there are malicious attackers who exploit vulnerability in your software and steal your source code or data. Worse still, they might publish all the data and make it available for download on some file sharing site.
It is extremely important that all your applications are secure and are protected against all known attacks. If your applications handle financial data…directly or indirectly…it is imperative that you understand your application’s attack surface and the threats it is exposed to. And if you’re a bank or a stock trader or an investments handling firm…you already know it. Your data is too critical to be stolen. In this brief blog post, I’m going to look at a few major threats that financial applications are exposed to and what attacks can be used to steal your customer data. I also co-wrote a book on this topic due to its critical nature.
Threats your application is exposed to.
So let’s look at a typical Internet banking application to start off with. A client will have to authenticate before gaining access to his/her bank account. Many a time, this is the only page that is publicly accessible and hence has a big bull’s eye on it. An attacker who has an account in the bank could first try and enumerate the bank’s password policy. If it allows weak passwords, you can be reasonably sure an attacker will try and guess them. It’s extremely easy to automate this password guessing process.
Once you log in you can view your account balance and verify all the transactions you made. I’m sure you wouldn’t like it, if an attacker was able to manipulate just a customer ID and view transaction data of the CEO of your biggest customer. It’s also possible for an attacker by injecting content into a request, to steal every single bit of information from your bank’s customer database depending on how well your database is locked down.
An even bigger threat would be an attacker being able to transfer funds from your account to their own account or being able to buy a truckload of shares which you would never touch with a barge pole, without you ever knowing about it.
Did you know that an attacker could, via a vulnerability in the application, run malicious JavaScript and gain control of your browser and your machine also in the process? This could happen despite you being very careful and never clicking a link or viewing any attachments sent to you.
Sometimes there are links inside the bank which on clicking, take you to a completely different site. Since the link starts with the bank’s name you trust it and click. That site could be malicious and download a banking Trojan to your computer. What this Trojan does, many a time, is load a malicious page which looks exactly like your bank’s home page, from disk, each time you access your bank’s site. You end up entering your credentials on that page and voluntarily sending them to the attacker.
I could go on for quite a bit to be frank; but I guess you get what I’m trying to say. There’s plenty of ways your information could be stolen. And no… SSL will not protect you against all of them (just in case you’re thinking it will).
Am I vulnerable?
Well, you could be. That’s more likely if you wrote a lot of your code years ago, and have never tested it. You might still be writing dynamic queries that are vulnerable to SQL Injection, not escaping untrusted user input before it’s displayed to the user or only checking if a user is valid before allowing him/her to access their resources.
- What was the last time you analyzed all your code to check if it was vulnerable?
- How many different languages do you use... for your customer facing and internal applications?
- What was the last time your developers were trained in secure development in all the languages your code is written in?
- Do you know which of your applications are your most critical assets?
- How many of the OWASP Top 10 vulnerabilities do you know for a fact, they are protected against?
- Have you integrated security into your SDLC?
- If you did perform a penetration test against them, how long did you or the vendor spend on it?
- Did you “trust” your automated scanner implicitly? Do you know what tests it performed?
I’m not going to give you the answers to those questions; they are all rhetorical :). Frankly though, if you don’t get positive answers to some of those, it’s time to think of addressing them and improving your overall security posture.
Conclusion:
At the risk of sounding like a broken record I’ll say… ’Application security IS important. Please take it seriously.’ The bigger you are, the harder you’ll fall… so the best defense against that, is to not fall at all. :)
