Jackpotting in the retail ATM sector
April 16, 2015
by Marc Winn, Chief Security Officer, Japan Communications
You have likely heard about the recent $1 billion ATM heist perpetrated against multiple banks around the world. As a retail IAD or ISO, If that didn't make you pay attention, this should:
In early March, 2015, an ATM operator made a service call to one of his locations that had reported a bill jammed in the cash dispenser. When the tech arrived to fix the problem, he discovered that the ATM was out of money. An online check with his processor told him that it shouldn't be out of money; there should be approximately $8,000 remaining in the machine.
The journals showed that only $9,000 of the $17,000 in the machine had been withdrawn, and that the maximum withdrawal setting on the machine had been changed from $200 to $300. A call to the processor to double-check his balance verified that there should indeed be $8,000 remaining.
The operator was the only person who loaded the machine, and the journal didn't show that the safe had been opened since the last time he'd made a service call. But the money was stolen, and he would have almost no chance of recovering it.
How did this happen?
Clearly, there wasn't a physical breach, armed robbery or internal fraud — to date, been the most prevalent means of stealing ATM cash. This being the case, the only remaining possibility was a cyberbreach.
In this instance, the operator was sharing an Internet connection with the store in which the ATM was located. The ATM software included OpenSSL v3.0, used to establish a VPN with the processor, which: a) should not have been allowed by the processor; and b) should have been upgraded nine months prior because of the "Poodle" vulnerability.
However, whether the Poodle vulnerability in OpenSSL v3.0 was the basis for the hack is questionable. Having changed the withdrawal limit setting, the hacker clearly had access to the ATM, but it is not likely that the Poodle vulnerability was the source of the hack.
Poodle gives hackers the opportunity to see and steal information from what is supposed to be an encrypted transmission, and it might give them opportunity to establish themselves as a man-in-the-middle in order to approve their fraudulent transactions.
However, these hackers had network access to the ATM itself, and there were no journal entries to indicate the fraudulent withdrawals. This leads us to the probability that the hacker gained access through another means.
The assumption that fault lies in a relatively easily fixed vulnerability is a dangerous one that will lead some simply to upgrade production software to its most recent version. Those who care to delve more deeply will find that there are some fundamental security principles that were violated and are more likely the cause of the breach.
We can be almost certain in our assumption that the sharing of the store's Internet connection played a big role in the breach. The operator has called the Secret Service, which handles these issues, and currently is waiting for more information.
Without the benefit of forensics data gathered from the store router and the ATM, we cannot be certain what happened, but we can make a few high-probability deductions:
- The store's Internet connection was
breached and information about the location of the store was retrieved, most likely via the point-of-sale system. (Without that information, the thief had no means of determining where the ATM was located.) The ATM was subsequently breached, as at least one ATM setting — maximum cash withdrawal — was changed.
- The theft included either a man-in-the-middle attack in which the attacker intercepted the transaction approval request and responded correctly within the ATM communications protocol, or the attacker hacked the ATM and found a means of dispensing cash without a journal entry.
It is more likely the latter; presumably the former would have generated a journal entry and, as mentioned previously, there were no entries found for the missing cash. Either possibility is disquieting, as someone with intimate knowledge of either sort could, and might, cause a lot more damage than this single incident.
What might happen?
OpenSSL reported 23 vulnerabilities in 2014 (including Heartbleed and other TLS-related issues) and seven vulnerabilities in the first 10 days of 2015. IPSEC VPNs generally have fewer vulnerabilities, but they are difficult to set up and maintain, and there are still vulnerabilities found.
In short, there will continue to be opportunities for hackers to breach devices or networks connected via VPNs. Any breached store with an ATM on its network might eventually find the ATM breached as well. But, it is a pretty random chance for ATM operators and relatively unlikely to result in catastrophic loss. That's the good news.
Here's the bad news: Hacking of retailers' networks and POS systems has become almost commonplace. There is nothing to prevent the hacker in this story from repeating his exploit as many times as his resources allow. There are multiple attack vectors against ATM operators that can yield the same or worse results.
Upgrading your VPN software is a short-term solution and doesn't address one fundamental problem: You cannot, with any certainty, protect a device that has a public network address from being hacked. In a malware attack, a hacker can exploit distribution points — for instance, ATM and router management systems — to enable broad-based attacks that result in the loss of millions rather than thousands of dollars.
Do your homework
Connecting your ATM via a public network (including VPNs) is a bad idea. Sharing a public network connection for your ATM with a company whose security you cannot control is a really bad idea.
There are multiple private network options available in the marketplace, and you should do your homework to find the most secure among them. Not all private networks are created equal, and some less scrupulous providers will sell you a virtual private network and call it a private network.
We now have a marketplace example of a jackpotted, nonbank ATM. The hacker responsible for this one in early March has been looking for opportunities to do it again, and on a larger scale than before. His methodology ensures that you won't know anything is wrong until you find your cash cassettes empty — and he seems to leave scant evidence of how he does it.
Marc Winn is chief security officer for Japan Communications, a JCI Group company (Contour Networks ). He has held senior positions at Intrusec, Harbinger, Xcellenet, Stonesoft, and several startup companies, and has worked in financial services with Merrill Lynch and Oppenheimer & Co.Source: www.atmmarketplace.com