Monday, 13 May 2013

What is wrong with our software?

Everytime I read articles like this: http://www.theregister.co.uk/2013/05/10/atm_megaheist_arrests/ I shiver at the way in which, despite this being 20-odd years since the internet began, we are still allow systems to be broken by basic insecurities.

I am not talking about zero-day exploits or weaknesses in Operating systems, DNS poisoning or SSL attacks, most which we would neither protect from or in some cases, even understand. What we have seen in this recent attack, however, is another system failing on the very basics. From the fact that the gang was even able to hack into the banks involved as well as the ability to modify the database unseen and then to carry out a mass cash-withdrawal against only 12 bank accounts without any attack detection occurring costing in excess of $45M to the banks (read bank customers or investors).

This is not an edge-case. This is not the same scenario as wondering whether 5 new accounts created from a single IP constitute an attack or not, this was 3,000 cash withdrawals, all from within New York (and others around the world) against 12 credit accounts. Accounts, that had already had their max limit increased to be unlimited.

Firstly, the fact that there are many unlimited withdrawal cards around in the first place is worrying but regardless, because this might be the case, you would have a set of standard/obvious security controls to ensure this didn't lead to abuse, as it did in this case. For instance, you could have a mechanism which says that any withdrawal over, say, $500 dollars must be authorised directly by the bank, not by any intermediary. In this day and age, it shouldn't take long. It should also include logic that will not allow this card to be used multiple times within, say, 5 minutes from other ATMs - even the London Boris Bikes will not let you take another bike out until 5 minutes after you replace the previous one! In this case, the cards were mag-stripe cards, something which is still in-use (very sadly!) in America. America take note! However, even if this is the case, why weren't the cards locked down to a specific country? If the real cards were Chip-and-Pin enabled, did the database record this in a way that means a mag-stripe withdrawal would be denied? It's one thing to pay a merchant using mag-stripe where you at least have a chance of easily identifying the culprits but an ATM?

Going back though to the original hack, it does beg the question as to how any bank detects intrusion into their system? With something as massively valuable as an unlimited withdrawal card, why are these not inside a protected database vault with limited access? Why were the database changes not detected or otherwise, if the bank's own system was used to access it, why were these not logged and verified before being actioned?

So many questions but I suspect the answers is obvious like it usually is. There are "process" shortcomings, lack of responsibility (both before and after the attack), probably a combination of ignorance and laziness, security not being given a high enough agenda. All of these things are OWASP Top-10 type issues and most could be thought up by any half-decent trained software developer but I wonder how much longer this will go on until governments start holding companies criminally accountable for gross security breaches - even if it is only money that is stolen.
Post a Comment