This author has long been fascinated with ATM skimmers, custom-made fraud devices designed to steal card data and PINs from unsuspecting users of compromised cash machines. But a recent spike in malicious software capable of infecting and jackpotting ATMs is shifting the focus away from innovative, high-tech skimming devices toward the rapidly aging ATM infrastructure in the United States and abroad.
Last month, media outlets in Malaysia reported that organized crime gangs had stolen the equivalent of about USD $1 million with the help of malware they’d installed on at least 18 ATMs across the country. Several stories about the Malaysian attack mention that the ATMs involved were all made by ATM giant NCR. To learn more about how these attacks are impacting banks and the ATM makers, I reached out to Owen Wild, NCR’s global marketing director, security compliance solutions.
Wild said ATM malware is here to stay and is on the rise.
BK: I have to say that if I’m a thief, injecting malware to jackpot an ATM is pretty money. What do you make of reports that these ATM malware thieves in Malaysia were all knocking over NCR machines?
OW: The trend toward these new forms of software-based attacks is occurring industry-wide. It’s occurring on ATMs from every manufacturer, multiple model lines, and is not something that is endemic to NCR systems. In this particular situation for the [Malaysian] customer that was impacted, it happened to be an attack on a Persona series of NCR ATMs. These are older models. We introduced a new product line for new orders seven years ago, so the newest Persona is seven years old.
BK: How many of your customers are still using this older model?
OW: Probably about half the install base is still on Personas.
BK: Wow. So, what are some of the common trends or weaknesses that fraudsters are exploiting that let them plant malware on these machines? I read somewhere that the crooks were able to insert CDs and USB sticks in the ATMs to upload the malware, and they were able to do this by peeling off the top of the ATMs or by drilling into the facade in front of the ATM. CD-ROM and USB drive bays seem like extraordinarily insecure features to have available on any customer-accessible portions of an ATM.
OW: What we’re finding is these types of attacks are occurring on standalone, unattended types of units where there is much easier access to the top of the box than you would normally find in the wall-mounted or attended models.
BK: Unattended….meaning they’re not inside of a bank or part of a structure, but stand-alone systems off by themselves.
OW: Correct.
BK: It seems like the other big factor with ATM-based malware is that so many of these cash machines are still running Windows XP, no?
This new malware, detected by Kaspersky Lab as Backdoor.MSIL.Tyupkin, affects ATMs from a major ATM manufacturer running Microsoft Windows 32-bit.
OW: Right now, that’s not a major factor. It is certainly something that has to be considered by ATM operators in making their migration move to newer systems. Microsoft discontinued updates and security patching on Windows XP, with very expensive exceptions. Where it becomes an issue for ATM operators is that maintaining Payment Card Industry (credit and debit card security standards) compliance requires that the ATM operator be running an operating system that receives ongoing security updates. So, while many ATM operators certainly have compliance issues, to this point we have not seen the operating system come into play.
BK: Really?
OW: Yes. If anything, the operating systems are being bypassed or manipulated with the software as a result of that.
BK: Wait a second. The media reports to date have observed that most of these ATM malware attacks were going after weaknesses in Windows XP?
OW: It goes deeper than that. Most of these attacks come down to two different ways of jackpotting the ATM. The first is what we call “black box” attacks, where some form of electronic device is hooked up to the ATM — basically bypassing the infrastructure in the processing of the ATM and sending an unauthorized cash dispense code to the ATM. That was the first wave of attacks we saw that started very slowly in 2012, went quiet for a while and then became active again in 2013.
The second type that we’re now seeing more of is attacks that start with the introduction of malware into the machine, and that kind of attack is a little less technical to get on the older machines if protective mechanisms aren’t in place.
BK: What sort of protective mechanisms, aside from physically securing the ATM?
OW: If you work on the configuration setting…for instance, if you lock down the BIOS of the ATM to eliminate its capability to boot from USB or CD drive, that gets you about as far as you can go. In high risk areas, these are the sorts of steps that can be taken to reduce risks.
BK: Seems like a challenge communicating this to your customers who aren’t anxious to spend a lot of money upgrading their ATM infrastructure.
OW: Most of these recommendations and requirements have to be considerate of the customer environment. We make sure we’ve given them the best guidance we can, but at end of the day our customers are going to decide how to approach this.
BK: You mentioned black-box attacks earlier. Is there one particular threat or weakness that makes this type of attack possible? One recent story on ATM malware suggested that the attackers may have been aided by the availability of ATM manuals online for certain older models.
OW: The ATM technology infrastructure is all designed on multivendor capability. You don’t have to be an ATM expert or have inside knowledge to generate or code malware for ATMs. Which is what makes the deployment of preventative measures so important. What we’re faced with as an industry is a combination of vulnerability on aging ATMs that were built and designed at a point where the threats and risk were not as great.
—
According to security firm F-Secure, the malware used in the Malaysian attacks was “PadPin,” a family of malicious software first identified by Symantec. Also, Russian antivirus firm Kaspersky has done some smashing research on a prevalent strain of ATM malware that it calls “Tyupkin.” Their write-up on it is here, and the video below shows the malware in action on a test ATM.
In a report published this month, the European ATM Security Team (EAST) said it tracked at least 20 incidents involving ATM jackpotting with malware in the first half of this year. “These were ‘cash out’ or ‘jackpotting’ attacks and all occurred on the same ATM type from a single ATM deployer in one country,” EAST Director Lachlan Gunn wrote. “While many ATM Malware attacks have been seen over the past few years in Russia, Ukraine and parts of Latin America, this is the first time that such attacks have been reported in Western Europe. This is a worrying new development for the industry in Europe”
Card skimming incidents fell by 21% compared to the same period in 2013, while overall ATM related fraud losses of €132 million (~USD $158 million) were reported, up 7 percent from the same time last year.
Thanks for the informative article. The “Ten Immutable Laws” sprang to mind. If the bad guy has physical access to the system, it’s his system now. I wonder if ATMs are making use of Secure Boot at all these days. That would preclude booting alternate OSes.
At any rate, for once it’s not a case of personally-identifiable information data getting pwned.
Nope – any OS can get registered for secure boot, for about $100 US and a lot of paperwork. Several Linux distros have been through the process.
True for the general case. Microsoft manages the root key which you can have sign your thing, for $100.
If you are the hardware manufacturer, you just install *your* root key.
The problem with Microsoft’s Private key is all it costs is $100 and a lot of falsifiable paperwork (How much verification does $100 buy?) to get your boot able custom linux OS signed, and then you configure it to boot your ATM Jackpot attack binary.
There are alternative solutions but I’m sure for the kind of cash you’re talking it isn’t worth it to load the thing down with a convoluted, layered design.
But if the hardware only trusts the custom key list that the manufacturer installs, rather than the default list, then they could be completely specific about what can boot and what can’t. My UEFI motherboards can load the default keys or custom ones, for example.
Given that the tactic is being used, I would at least be looking into that capability, if I were NCR or someone in their position.
All Secureboot is doing is integrity checking very specific binaries at bootime, and that’s it.
It does not integrity check every binary, it hands off trust to the OS at some point. A Chain of trust is required for each binary executed, and that ends right after boot up.
The only time secure boot stops something from running is in the UEFI Environment. That the system leaves that environment the gloves are off.
Indeed, if I was a miscreant, I’d just piggyback onto an existing Linux distribution that’s signed, then make changes to the boot environment so it loads my custom code once SecureBoot is out of the picture.
It’s not really all that horribly difficult, anyone who’s created their own services under Linux by hand could do it (and I can do that, they can do that).
Just set the OS to load at a runlevel, adjust the services for that runlevel to match what you need / don’t need, then boot, boot, boot away…
You might be thinking of Measured Boot. If you poke around in the Secure Boot section of a typical modern-day motherboard, you’ll see that you can load your own list of Secure Boot-related stuffs, if you don’t want to roll with the default lists. So locking out SB-signed Linux distros, for example, should be as simple as loading your custom SB database that does not contain those keys, or any others besides the one you’ve specifically whitelisted. For example, if I deleted the Secure Boot database on my UEFI motherboard here, it would no longer load *any* OS if Secure Boot is still in force. Conversely, if you wanted to specifically blacklist certain OSes, such as all SB-signed Linuxes, you could add them to your motherboard’s custom Secure Boot revoked-signature database.
In general, OS whitelisting on ATMs looks like a good idea, however it’s accomplished.
But how long before the PII actually gets taken? Seems like that would be an easy add on to the jackpotting.
Wow, what refreshingly honest and informative responses from a company representative. It certainly raises my respect for NCR. This wasn’t the usual “security is our top priority” blather. Great story, Brian!
Really? He appeared to be avoiding the issue of Windows XP.
OW: “Right now, [XP is] not a major factor.” …witters on about updates being available somehow mitigating that they weren’t applied or proactively researched.
Brian: “The media reports to date have observed that most of these ATM malware attacks were going after weaknesses in Windows XP?”
OW: “It goes deeper than that.” …fails to mention XP again.
XP is not as huge an issue as you might think. These standalone ATMs that are getting owned typically run XP Embedded which is supported through January 2016. As the person from NCR points out, it’s getting the machine to spit out its money through manipulating the hardware, not screwing with the OS although there apparently is some of that.
Yes, he says pretty explicitly that most of the attacks (at least on NCR machines) are either direct hardware attacks or introducing malware through hardware attacks. It doesn’t sound to me like he is evading any questions.
The OS has nothing to do with the security. It’s a single use system with little to no user interaction at the keyboard. So little to no chance for normal infection avenues. Tie in a firewall that restricts all communication inbound and the system is protected from all but physical access attacks.
Note that banks are not a target, but merchants. Also note the attacks so far have targetted turning the machine into a cash output instead of accessing the journal of transactions to pull account numbers and associated card data. When these attacks get more sophisticated, the merchants will never even know and there will be card compromises that are even harder to trace back the source.
To date consumers just have to worry about a skimmer in the device. Wait until the day that just using the system even without a skimmer means your card is compromisable.
—
The OS isn’t a factor per-se, but… wasn’t there a case not too long ago that involved someone drilling a hole, plugging in a USB keyboard, and basically killing the ATM front-end to gain access to the underlying Explorer app?
XP Embedded is just a stripped down version of XP, and it’s really not all that stripped down. Remote Desktop, for instance, is present and can be enabled… not that it would net thieves much, assuming the network the ATM is attached to wasn’t configured by idiots, it’s just a way of illustrating that potentially damaging services are still present in embedded copies of Windows.
Frankly, I question the wisdom of some of the things they did trim from embedded vs. the things they left in. It appears to have been done from a marketing perspective and not from a security perspective. What can they cut that 95% of customers won’t notice… aren’t tracert and some other basic ip tools missing?
BK, Padpin and Ploutus does not exploit any vulnerability in Windows XP, these attacks interact with the Middleware (XFS Framework) to control the Dispenser and get all the money they want.
To interact with the middleware an attacker needs to run his code on the ATM.
Loading of executables is but controlled by the OS.
So: to avoid attacks on the middleware of the ATM just restrict the loading of executables to “secure” locations.
This is possible with software restriction policies on XP.
Seems like ATMs are the new POS (Point-of-Sale machines). Same attack surface (mostly outdated Windows machines) and same vendors (e.g. NCR is selling both POS and ATMs) lead to the same attack techniques, i.e. infection by malware.
However, from the attacker perspective, ATMs seems to have the advantage of a simpler monetization path as the attacker can get cash directly and not a credit that requires a complicated scheme to monetize, as Brian had described in the past.
I think that understanding current attack campaigns against retailers (Target,Kmart and others) is imperative to understanding current and future ATM attacks. (and much more relevant than skimmers)
Mr Owens is very candid. He speaks like someone who knows his business and knows he’s has done his job correctly.
I think when he says ‘standalone’ ATM he means the monolith type that allow access to the top and rear, as opposed to the models that mount into a wall and limit access to the electronic components.
Those standalone models could be inside a protected lobby, or outdoors where no one is watching them.
Impressed with NCR’s comments, honest and open.
Thank you.
Great stuff as usual Brian.
It seems the response for this will be slower as these ATM are (mostly) owned by large corps who can afford to take the hit as it is cheaper to allow these attacks than spend money on upgrading their networks, similar to why CHIP&PIN uptake has been so slow up to now in the US.
In the UK The National westminster Bank have a system where as if you have lost your Debit/Credit Card it is possible to enter a code on one of their ATM machines and it will give you cash.
Hence the code is in place to exploit
Good interview Brian. Must be nice to actually talk to someone like this instead of the usual; “We are aware of reports that a breach may have occurred and are investigating with the local authorities.”
Great interview and a interesting read
very good interview.
Hi Brian
I seem to remember that ATM’s used to run OS/2, before everyone switched to XP.
Any thoughts on that?
Where these any more secure than now?
I remember when OS/2 used to rule the ATM world. I heard that a few still run it. I suspect that if you have physical access no OS is going to stand up to the attack. Especially the one where you tow the ATM away through the front door!
The OS is irrelevant if the attack is via a boot CD that directly interacts with the hardware cash dispenser.
The OS never boots during the attack, hence the recommendation to lock the BIOS to prevent booting form anything other than the hard drive.
However if they have access to the CD drive, it’s not hard to imagine the next attack replaces the hard drive.
Thanks to NCR for their candid responses.
This story has parallels to the recently released story about two Americans who figured out how to press buttons in the right order to jackpot ubiquitous poker slots across the US for five figure payouts. They could do it at will, over and over, from casino to casino.
The parallel ends when the gaming industry, casinos, and the machine manufacturer twigged to what was happening and landed on the two gamblers with both boots. The machine software in thousands of slots was updated immediately and instruction to prevent recurrence was issued in all casinos owning the particular slots.
You would think the banking and credit card industries could launch a equally powerful response to being ripped on in the tens of millions.
PadPin and Tyupkin are the exact same thing, Vicente Diaz confirmed; great read.
Great article Brian, thankyou.
I’ve been in this field for 20 years and I actually wrote a research paper on these same threats and weaknesses 12 years ago (http://www.sans.org/reading-room/whitepapers/threats/security-online-transaction-processing-white-label-financial-switch-927).
Given that, I’m a little skeptical about Mr. Wild’s comments “ATM technology infrastructure is all designed on multivendor capability. You don’t have to be an ATM expert or have inside knowledge to generate or code malware for ATMs”. The internal machinery of these ATMs, especially the older Persona series he mentions, were not all that standardized and you *did* have to know what commands to send, how and to what system device in order to get jackpotting to work. I do agree however with his advice about turning off CD and USB boot access in the BIOS – that would be effective in blocking non-privileged access. Unfortunately during the massive global growth of private ATM deployers between 7 and 12 years ago, where many ISOs got into the ATM business, very few of them really understood or implemented good security measures like these. The race to control costs, deploy faster (ie. use default configurations) meant that long-term security took a back seat to immediate business concerns.
Regards
If you have time and money you can always reverse engineer the commands sniffing the ATM BUS and create your own set of commands, besides testing it… My point is: information for a device that can be stolen is not a barrier if you think on the old technologies used there.
If the attacker has access to the HW, he can install a new OS there, that can do whatever commands you want (e.g.: stole creds by fake login screen followed by a “communication error, please try again latter” -> harvest the outputs by EOD and reboot in the original OS so any tech team will think there was actually a communication error, in case someone opened a ticket…)
Am curious about the future of ATMs at NCR as both its Cash Dispenser ATM models and Deposit ATM models appear to support only Windows XP Professional:
http://www.ncr.com/products/banking
Does NCR have new ATM models in the works? Or is it exiting the ATM business? Or something else?
Seems like a lot of trouble when you can just throw a chain around the standalone ATM, drag it out of the store with your truck, and then disappear into the forest and chop it up at your leisure. This is a pretty common MO in these parts. Maybe criminals outside the US have less access to big trucks 🙂
Eventually someone may notice the ATM sitting in the back of your pickup truck on the way out to the woods. The noise of tearing it off the foundation may alarm some neighbors, as well. Not everyone has the keystone cops for a police force.
Drive up in a rented van with some cheaply printed logo attached to the side and you can sit there banging away at the ATM for an hour or two. Then you do the exact same thing a couple weeks later to an identical model unit in another location – only expense is a new logo.
Single payout with risk vs. multiple payouts with minimal risk.
Keep it simple…ATM operators could easily add intrusion devices integrated with alarm systems to detect any local ATM access via door switches, vibration sensors etc…Yes, these additions would add to the cost of operation for each ATM system, but in comparison to the cost of attempting to plan and implement fixes for every “what if” that the good guys can reasonably imagine to combat the bad guys…
As of 10/27, Staples still is refusing to identify the stores where credit card compromising occurred. This is all the will say:
“Staples is in the process of investigating a potential issue involving credit card data and has contacted law enforcement. We take the protection of customer information very seriously, and are working to resolve the situation. If Staples discovers an issue, it is important to note that customers are not responsible for any fraudulent activity on their credit cards that is reported on a timely basis.
Thank you for shopping with Staples.
Bonnie
Customer Service Representative
Hardly convincing, is it?
Great article Brian! Still on the bleeding edge; and just when we though every vector on ATMs was explored! Not really, but I hadn’t thought about it for a while! This is what keeps us coming back for more!
I used to work for NCR in 1 of their manufacturing plants. I am really surprised that they are still in manufacturing. They were making much more money from data warehousing and the rumours at the time was they were going to sell off or split the manufacturing side.
What is worrying is the number of banks that are using clearly outdated hardware with just as outdated software.