Saudi cops cuff four for mad bank card scam
Easy money
Regcast training : Hyper-V 3.0, VM high availability and disaster recovery
Four teenage Saudis have been arrested over a technically implausible ATM scam said to have netted US$533,000 (two million Saudi Riyals) over two years.
The unnamed youngsters from the Taif area of Western Saudi Arabia apparently discovered game cards from the local mall allowed them to withdraw the same amount of money as the last previous legitimate ATM customer. The Terminator 2-style trick only worked at the machines run by one particular bank which "used an old system", according to authorities.
Funds came straight out of the bank's reserves and not from those of the previous customer. Bank officials reportedly noticed the discrepancies and called in the police, who tracked down one of the miscreants using video records and photos taken by ATM cameras.
The arrest of one of the group led to the arrest of three of his cohorts, who had used their ill-gotten gains to buy five cars, various Japanese imports.
Local reports are technically sketchy and fail to explain how the ATM machines, however old they were, accepted game cards.
The only theory that comes to mind is that the game cards were in some way similar to maintenance cards used by engineers to service the machines. This doesn't seem at all likely, and it seems more plausible that some sort of ATM skimming and reprogramming of the game cards was involved in the scam. ®
COMMENTS
Obvious reasons this worked
If the kids had a card that specifically spit out the same amount as the previous transaction. It simply was not a "service card" as a service card would provide additional diagnostics and almost certainly would require additional intervention such as a switch to be flipped behind the locked door before actually giving out money.
There may be a bug in the ATM software which triggers from a buffer overflow judging the transaction was incomplete. Then the cards the kids got were just dumb luck. But, the chances of this are very slim since the readers usually transmit the numbers, not the pulses to the main system.
Of course, the bank would have probably thought the cash delivery guy was to blame if no extra transactions were showing up, but there was money regularly missing. Either he was pocketing it, or he was installing it in a way where bills were sticking together.
Now, on the other hand. If they look deeper, it's very likely they're find some code in their system specifically responsible for making this happen. Then it's a matter of finding out who wrote it. It's extremely likely that someone was in fact tampering with the system internally. The kids either found out about it through leaked information or through luck.
As a former programmer at a banking warehouse (when I was young and couldn't get a real job), I found that if you were the guy working on something like ATMs and you needed some way to test code, it was much easier to use an old $1 prepaid phone card than it was to go through the bureaucracy involved with battling with the overpaid secretary who was responsible for issuing cards to get a test card. So, just swipe the prepaid card, link it to your test code and there you go. Now the programmer can test repeating the last transaction by using the calling card he used for calling his mom from college.
It might not have been intentional. It might be that there's a programmer somewhere living in a palace. Either way, it's almost certainly in the code.
P.S. - I even know banking programmers these days... I've seen at least one of them leave his car door unlocked with his wallet on their dashboard while going into the gas station to take a leak and buy a hot dog in a city. If that's how he treats his own money... do you really think he cares if the bank he works for which deals with 50 types of electronic theft a week loses a few bucks from an ATM?
I wonder
How they cuff repeat offenders who don't have any hands?
Not so unlikely after all.
I remember as a kid finding out that daddy's car would lock fine with a key from a wildly different brand... but not open. That seems impossible, but nonetheless, that's how it was.
The thing is that these systems are more tested positively than negatively. That is, every change you make you check that nothing breaks. But do you also test, at every change, that everything that shouldn't work, doesn't? Probably not.
I've tinkered with state machines and such to *really* have input validation done correctly, including rejecting all invalid input next to accepting all valid input, and oftentimes getting every last corner case right took quite a bit of effort. And that was when I was out to get it right. Most programmers don't even try. "It compiles, ship it."
Not entirely unrelatedly, I wouldn't be surprised if this was an unauthorised testing back door as surmised elsewhere in the comments, or something to that tune. If people start to circumvent bureaucracy then that undermines your security. So best not be too bureaucratic, eh.
For the kids to have found out, well, that is probably sheer dumb luck. But it wouldn't be reality if there were no outlandish surprises.
IT infrastructure monitoring strategies
Agentless Backup is Not a Myth
Top 10 SIEM implementer’s checklist
Steps to Take Before Choosing a Business Continuity Partner
Requirements Checklist for Choosing a Cloud Backup and Recovery Service Provider
