Schneier on Security
A blog covering security and security technology.
« Unredacted U.S. Diplomatic WikiLeaks Cables Published |
| The Efficacy of Post-9/11 Counterterrorism »
September 2, 2011
A Professional ATM Theft
Fidelity National Information Services Inc. (FIS) lost $13M to an ATM theft earlier this year:
KrebsOnSecurity recently discovered previously undisclosed details of the successful escapade. According to sources close to the investigation, cyber thieves broke into the FIS network and targeted the Sunrise platform's "open-loop" prepaid debit cards. The balances on these prepaid cards aren't stored on the cards themselves; rather, the card numbers correspond to records in a central database, where the balances are recorded. Some prepaid cards cannot be used once their balance has been exhausted, but the prepaid cards used in this attack can be replenished by adding funds. Prepaid cards usually limit the amounts that cardholders can withdraw from a cash machine within a 24 hour period.
Apparently, the crooks were able to drastically increase or eliminate the withdrawal limits for 22 prepaid cards that they had obtained. The fraudsters then cloned the prepaid cards, and distributed them to co-conspirators in several major cities across Europe, Russia and Ukraine.
Sources say the thieves waited until the close of business in the United States on Saturday, March 5, 2011, to launch their attack. Working into Sunday evening, conspirators in Greece, Russia, Spain, Sweden, Ukraine and the United Kingdom used the cloned cards to withdraw cash from dozens of ATMs. Armed with unauthorized access to FIS's card platform, the crooks were able to reload the cards remotely when the cash withdrawals brought their balances close to zero.
This reminds me of the RBS WorldPay theft from a couple of years ago.
Posted on September 2, 2011 at 6:38 AM
• 8 Comments
To receive these entries once a month by e-mail, sign up for the Crypto-Gram Newsletter.
Yes and one or two other security problems with the likes of ID documents.
Put simply "off line" security does not work the same way as "on line" security, and thus you can have multiple replay attacks against an off line system that would fail with an on line system.
P.S. as it's caused problems on this blog in the past my use of "on line" and "off line" is very specific to the usage mode not the more recent generalised perception of what the terms mean.
@ Bruce Schneier
"This reminds me of the RBS WorldPay theft from a couple of years ago. "
Krebs said the same thing. But he had a few more interesting details in his statement:
"Federal prosecutors alleged that the 2008 RBS theft was orchestrated by at least eight men from Estonia and Russia — the alleged ringleader was extradited to face charges in the United States.
Another key figure in that case was Viktor Pleschuk of St. Petersburg, Russia, who monitored the fraudulent ATM withdrawals remotely and in real-time using compromised systems within the payment card network. Pleschuk and Russian accomplice Eugene Anikin were arrested and charged in Russia. Prosecutors asked the court for five- and six-year sentences, but those requests were ignored. Pleschuk and Anikin agreed to plead guilty for their roles in the RBS heist in exchange for suspended sentences (probation, but no jail time)."
I've known several people who work in online banking, teller networks, and ATM machine software. From them I've learned some interesting things.
You go to Bank X's ATM with a card for Bank Y and try to withdraw cash. Bank X will try to confirm with Bank Y that the transaction should be authorized. But suppose Bank X cannot reach Bank Y at that moment--network problems, say--in most cases Bank X will still let you withdraw the cash and simply queue the electronic transaction to be delivered to Bank Y when connectivity is restored. The ATM behavior is virtually identical whether it was a verified transaction or not, so the customer isn't tipped off as to when an outage is happening.
Bank X takes a risk in dispensing the cash, since it doesn't know whether the account has sufficient funds. This risk is mitigated by per-transaction and per-day limits for the account, similar limits per bank and per machine, historically infrequent and short-lived outages, no public disclosure of when the outages are happening, and interbank transaction fees.
Things change, so this may no longer be true, and I suppose it probably varies by bank and network.
I have worked in the banking/credit card industry, and the fraud rules in place normally would not allow this - credit cards limit withdrawals to X times in 24 hours and amounts too. There are also rules regarding transactions being more then X Miles apart in Y hours.
My guess is someone got lazy and didn't test the hundreds of rules that are part of a new product launch... they assumed they worked and were coded right.... someone found the hole.
There is no reason that the this attack should succeed as the simplest fraud prevention/detection rules would have stopped it.
Schneier.com is a personal website. Opinions expressed are not necessarily those of BT.