Failures like this seem common and widespread. What shocks me, now, is not that all these systems are full of holes, but that banking, the financial industry, still allows these transactions to take place over the Internet.
Sadly, I'm sure most of these code issues could be avoided from the start with better planning, code review and paying programmers who know what they're doing the amount they should be paid.
Then, of course, there's the issue with chip makers building in trap doors, so not just a code issue.
most of these code issues could be avoided from the start with better planning, code review and paying programmers
The bigger code houses work in two ways - offshore new or maintenance coding to anywhere willing to write code for peanuts, or more commonly they buy other companies, and Borg the code into their ERP suite. Not sure which applied to SAP's POS, although I note SAP bought Canadian POS house Triversity back in 2005.
The problem with the purchased companies is that these were (at the time) mostly smaller, slow growing companies. The code was built to work at a basic level of functionality, often by a cash starved gang of five or six developers operating in a small shed, and shovelled out the door. By the time the big ERP house buys the company, it is a package of customer accounts with high switching cost (ready to be milked) and this sticky tarball of code. The ERP houses (not just SAP, Oracle, Infor, Epicor and others) get rid of all the acquired company staff. Usually quickly, sometimes slowly, but it always happens, and so there's this blob of code, for which some designs and documentation exist, but which soon nobody in the big ERP house understands. They don't know the design logic, the botches and bodges, the workarounds, they don't understand any commenting unless it is written in the English of a ten year old, they don't know WHY the code is the way it is. Factor in that doing proper error and pen-testing is expensive, and that proactively maintaining code is also expensive, and the big ERP house has no incentive to find all the holes and fix all this legacy code, other than the initial makeover to bolt it into the Frankenstein core ERP suite.
Obviously if something nasty crops up in the public domain, big ERP leap into action like a greased mammoth to avoid commercial or legal problems, But that's when they hand it all over to cheap code monkeys in developing countries, and hope for the best. Within months they've solved the original problem, and probably added a whole host more latent problems through low quality code.
once on the network...
be interesting to see how many companies post snowden have implemented 100% S-Protocols inside the lan.
Re: once on the network...
If it involves a windows server at any point, forget about secure protocols.
Re: once on the network...
Not sure who would down-vote this statement, possibly someone who hasn't tried to secure windows servers in an enterprise environment.
Re: SAP server connects back to hacker laptop
Unfortunately a VPN doesn't help if someone has control of one of the end-points.
Didn't the attack simulation involve the servers that were on store premises (rather than the back-end servers running the databases)?
Foot: shooting of one's own
Stepping back and scanning the horizon - what can we see? Precious little onion approach to layering security and the obvious ones : using a bank account number or any other extrinsic part of the "what he knows" information or requiring persistent and continuous authentication.
Why bother hacking into SAP?
If you can spell "SAP", then you can rob people in broad daylight as a "SAP Consultant".
"Install the ERP software? Why yes. That'll be $10 million... Oh, I mean $20 million. Unless you also want the 'Put The Fricken' Boxes on the Fricken' Trucks' module. That's extra. A retail outlet in Canada once forgot to buy that module. Hilarious. Store shelves empty for an entire year."