‘Jackpotting’ Attacks Hit U.S. ATMs
krebsonsecurity.com
krebsonsecurity.com
I was surprised to learn that they run full Windows. In fact, one of the projects I was on had a requirement that we upgrade the OS from XP to Windows 7 for security reasons.
Regardless though, you can make an ATM do whatever you want if you have enough time and access to it. One of our low level debugging tools allowed you to effectively control every aspect of the device, so it could spit out whatever denominations you liked without talking to the banks mainframe.
We used to have fun printing out ATM receipts showing our fake balances of millions of dollars etc.
And want to know something else? The UI layer was html + javascript and some funky css that ran on a custom modified version of ie6.
Beneath that, to handle fetching of data, comms, navigation, window management and other business logic etc, we used good old .Net and C#.
It was a bizarre setup from a dev perspective but once you got used to it you could crank out new features incredibly quickly as you had a heavily regimented workflow (Usability trumps _everything_ with these machines).
If you open up an ATM you will find your standard run of the mill beige PC inside it and in fact in many of the older machines they _literally_ stuff an _entire_ PC case in there simply laid on it's side.
There is also an extra monitor back there with a little keyboard attached.
The only impressive aspect of ATM's is the engineering that goes into all of the supporting hardware and peripherals such as the stackers, the cash acceptors, the cheque validators, the printers, the recycling cash canisters, the electronic pin pads, the various fraud detection features etc. I found that stuff much more interesting than the dev work I did day to day.
http://www.kal.com/en/video/multi-vendor
This article states that other manufacturers using Kal's software can be targeted as well with some alteration to the code. How possible could that be?
https://arstechnica.com/information-technology/2018/01/in-a-...
> I didn’t mention it in the story, but perhaps I should have: The original mission of the Secret Service when it was created in the 1800s was to safeguard the U.S. currency from counterfeiters. Only after a few presidents were assassinated did their mission grow to include protection of the president and other dignitaries. Both are their dual roles today.
“In 1984, the US Congress passed the Comprehensive Crime Control Act, which extended the Secret Service's jurisdiction over credit card fraud and computer fraud.”
https://en.m.wikipedia.org/wiki/United_States_Secret_Service...
You're mistaken. That's the "Bank Secrecy Act" https://en.wikipedia.org/wiki/Bank_Secrecy_Act
FTL: "Specifically, the act requires financial institutions to keep records of cash purchases of negotiable instruments, and file reports of cash purchases of these negotiable instruments of more than $10,000 (daily aggregate amount), and to report suspicious activity that might signify money laundering, tax evasion, or other criminal activities."
I'm not sure why this hasn't really been done in practice but it shouldn't be to difficult to figure out how to do correctly.
In most ATM's the computer hardware and interface connectors are also all housed in the top (mostly plastic or low-quality cast metal) shrouds (as opposed to the currency locked in a safe). Traditionally wafer locks were also used to secure this section however they are slowly migrating to higher security locks like Abloys.
ATM manufacturers may want to take a look at slot machine manufacturers for clues on how to harden machines against tampering.
Encrypt the signal from the host to cash dispenser, have a debugger process that is connected to the host process that also stores the encryption keys and or talks to an HSM. Mitigates tampering of a live system, makes flashing new firmware problematic.
Physically limit the cash dispenser from outputting k bills over n seconds. Have those limits be session based, again signaled by main host process. Would require a full login/logout cycle for k bills.
Most likely, the systems are left wide open internally to ease development and mask bugs.
My ending blanket statement is that finance people know how to be cheap, they can optimize along one axis, replacing a 5$ with a 2$ part, but the really good ones optimize the whole system over a long time horizon.
NCR is focused on profits not security, even though they sell POS (point of sale), ATM machines, and airport kiosks.
From my personal dealings with NCR, I can confirm that they care very little for security, regardless of what their corporate line.
To put this in perspective: if you go to a grocery store, restaurant, or quick service (fast food) establishment and use a credit card then your full account number, name, and exp is recorded in their system. This information is accessible by anyone with store level admin (not windows admin, but think a manager with manager card).
This violates PCI but hey, fuck PCI, hard sending the system takes resources and who wants to do that?
On HN, folks keep talking about security and other such nonsense, however, anyone who has seen the other side isn’t very optimistic. Between ease of use, profit margins, and no pushback on insecure systems, all loses are just write offs.
Plain text ... and before two years ago, they also had regional master passwords. As in one password for all systems sold by a particular reseller.
A lot of money has gone into locking this hardware down, and I think for the xbox 360, which was released in 2005(!) there is still only one hack they couldn't solve with a software update, and that's soldering to the CPU and glitching it on a specific compare instruction.
I would bet, this "sophisticated malware" is a lot more trivial than glitching the CPU on one specific intruction and having to take a soldering iron to the ATM, then fiddling trying to get the timing exactly right.
Building a chain of trust and authenticate commands to the cash dispenser really shouldn't be an issue.
Really, just put a fucking xbox in these ATMs. Lots of people attacking those while being able to do whatever they want to the hardware with limited to no success. (I don't think anyone has managed to open up the xbox one?)
But breaches happen, and lead to lawsuits, and I can just imagine trying to impress a jury about the security of your ATM while the other side cracks jokes about gold coins in Super Mario and speculates about your low Halo ranking.
ATMs on the other hand are designed to interact with physical hardware that sucks money up and spits it out. Locking down the operating system is easy, but if the hardware is controlled by serial interfaces then you've got a weak point there unless the serial interfaces are encrypted (spoiler, they are not!). To encrypt them you'd need to put something at the OS side and something at the hardware (pneumatics/motors) side and ensure they aren't accessible (ie, located inside the safe part of the ATM). Its not impossible to do, but I somehow doubt they'll do it anyway.
No, it's not. Look at pretty much every console ever made except for the xbox 360/one.
> unless the serial interfaces are encrypted (spoiler, they are not!)
Yeah and that's obviously a problem. Nitpick though, the interface doesn't need to be encrypted, messages just need to be authenticated. Confidentiality of these messages isn't really important since you'll see the cash comming out, and you actually probably need some kind of challenge/response protocol to avoid replay attacks.
But you want them authenticated by a key that is very difficult to get out of the thing controlling the cash dispenser/serial/whatever. Which is why I said put a gaming console inthere, millions of dollars have already been spent, and are still being spent making sure nobody is getting secret keys out of them, even with full access to the hardware.
> To encrypt them you'd need to put something at the OS side and something at the hardware (pneumatics/motors) side and ensure they aren't accessible (ie, located inside the safe part of the ATM). Its not impossible to do, but I somehow doubt they'll do it anyway.
Well no, that's the point. You only need to make sure the pneumatics/motors only take authenticated commands, and that nobody can mess with those. For the OS side you piggy back off console security.
(c) In the case of a gaming device, a copy of all executable software, including data and graphic information, and a copy of all source code for programs that cannot be reasonably demonstrated to have any use other than in a gaming device, submitted on electronically readable, unalterable media;
http://gaming.nv.gov/modules/showdocument.aspx?documentid=29...
Makes one imagine what kind of political trench wars probably went on behind the scenes about this regulation.
Edit: On second thought, this seems awfully easy to circumvent. What stops me from making a rigged PRNG and then refusing to make the source code available on the grounds that there are lots of non-gambling applications for PRNGs?
This was true even before electronic slot machines.
E.g., if someone already dumped a lot of money into other games, I can give them above-average odds of winning and be sure I still make a profit (and they make a loss), otherwise I'll give them below-average odds.
If I tune this right, the average outcome over all players will still look "fair".
Or I simply give the above-average play sessions to strawmen.
I could hide the above manipulations in some component I don't have to expose and have the machine play nice under testing conditions. (See certain automakers for examples)
The attackers typically use an endoscope so they can attach a cord to the computer and install malware. This makes ATM remotely controllable!
In previous Ploutus.D attacks, the ATM continuously dispensed at a rate of 40 bills every 23 seconds. Once the dispense cycle starts, the only way to stop it is to press cancel on the keypad. Otherwise, the machine is completely emptied of cash.
Jackpotting it is.
The age of (common) embedded system exploitation is finally upon us.
This isn't an embedded issue. This is a physical access to OS issue.
Nowadays the communication link to the dispenser is encrypted, making swapping the hard drive useless. The real problem is the machines aren't replaced very often so there are quite a few old models out in the field that are susceptible to these sort of attacks.
Interesting. Is there a source for this?
Secure Boot should be able to prevent this even with physical access.
https://www.theregister.co.uk/2005/10/21/phantoms_and_rogues...
I also remember seeing a report that was aired on UK TV by Channel 4 back in the 1990s that showed how easy ATM fraud was. I can't seem to find the clip, but if anyone has better luck than me I'd be interested to see it again. The only other clue I can think of was that I believe the report was presented by Krishnan Guru-Murthy, but I think it might have been on a different show than the Channel 4 News.
I had no idea ATMs ran Windows!
But on the other hand, it only takes one.
For starters, Windows XP has always optimized for "plug random hardware in and it Just Works" while OpenBSD aims more at "what is the minimal number of services we can have running in the base image."
Sure, OpenSSL vulnerabilities found in the intervening time will still affect both, but we're still talking orders of magnitude difference in RCE vulnerabilities.
A bank I worked for years ago had ATM domains (in different forests) and had policies applied to the ATM's.
They ran XP at the time.
I've never seen one like this though: https://www.betaarchive.com/imageupload/1182228936.or.19648....
BTW, that one retailer that used the Linux version? They replaced it with the Windows version on their next hardware refresh.
https://krebsonsecurity.com/2018/01/first-jackpotting-attack...
Nice little punchline at the end too:
"The Secret Service alert says ATMs still running on Windows XP are particularly vulnerable, and it urged ATM operators to update to a version of Windows 7 to defeat this specific type of attack."
ATMs need to be more physically secure, like bank safes, if they are to be resistant to such attacks. The software part is mostly immaterial here, IMHO --- it doesn't matter what the software is, if you can get access to the physical money.
Achieving 100% physical security is going to be hard.
By offering cash back you're reducing the amount of cash kept in store, reducing the chance of being robbed (less worthwhile). By putting an ATM in store you're increasing the cash on premises, and in your tills (as people use the ATM rather than cash back)
Cash back is a win-win for stores.
People withdrawing cash from the ATM (often incurring a non-trivial fee) to pay in the same store, rather than just paying on card, seems to be a marginal case and indeed inferior to card payment.
When I worked in a convenience store 20 years ago, we’d dump cash into a safe through a mail slot every time the cash in the till rose over a certain amount (the register computer would show a red bar with a message to this effect), and we’d routinely have to turn down requests for all but trivial amounts of cash back for this reason.
In aggregate these small freestanding ATMs are a huge business, it's unlikely they will harden their whole fleet by building in-wall installations.
The thing is that ATMs from larger vendors (IBM, NCR, Bull, Siemens, etc.) have layer upon layers of protection features. For example, you can configure a secondary combination for the safe which will open it and also send an emergency alert. This is for the cases when someone is being forced to open the safe at gunpoint. There are batteries for secondary power supply. There are options for physical lock-down in case of a power loss. Tilt and movement sensors. Redundant communication options, including exotics like x.28 radio.
I mean that all of this was readily available even 20 years ago. ATMs are not designed by amateurs. The issue is that all these are _options_. They need to be bought first and then they also need to be properly configured and enabled, which falls on the banks or their IT service providers to do. The smaller the bank, the less willing they are to spend even more money on configuring secondary stuff and setting up an infrastructure for it, so many of these options will remain off even if they are available.
With one of offices of my bank being nearby (to be able to block my card if I couldn't get it back), I tried it two more times, just to check that it wasn't a random occurrence.
While it was probably nothing that could further be escalated into gaining access without additional hardware, it gave me a chuckle (and a bit of fear for my card, initially).
You find a lot of these ATMs that are even more insecure than the larger WinXP machines. Those little kiosks are perfect for skimmers, manipulation, or just fucking around with.
> At this point, the crook(s) installing the malware will contact co-conspirators who can remotely control the ATMs and force the machines to dispense cash.
Realize what this means. The ATMs are connected directly to the internet, with a VPN (hopefully...) sitting over the top of that. The ATM can still call out to the internet directly!!
That is, honestly, shocklingly insecure. I'm stunned.
I read https://news.ycombinator.com/item?id=16250498 and how ATMs have different options for security, but "allow anything except the VPN software access to the NIC default route" doesn't sound like something _anything_ should be able to disable.
I mean... I know nothing about networking, and I was able to configure this exact behavior on FreeBSD - which I'd never used before - in a day. I set it up so a torrent program was physically incapable of doing DNS/anything outside of the VPN tunnel interface.
Encourage companies to only pay employees through banks by making it practically impossible to pay through cash. Expand money laundering laws so that banks are liable if they give out or take in physical cash, with short and hard limits to ATM's. Make it acceptable to have police confiscate money if a person carry more than a few hundred dollars. Just to give examples of those, a person was stopped by a routine police stop when they saw $350 and confiscated it on the concept that such huge amount of money was a sign of money laundering. A few further months ago a elderly couple (70+) had sold their car but could not put the 10 grand into the bank since the sale papers (including government signed transfer) was not enough to prove definitively that the money was still not part of any money laundering. Sweden invalidated all bills and coins made before 2015, forcing everyone to have them exchanged or put it in the bank which was why the elderly couple needed to put the money in the bank.
Add to that a heavy joint campaign between banks and government to paint any physical cash transaction as putting employees at stores at risk and that its a moral responsibility that everyone only use banks, and a strong decline in the availability of bank offices that handles cash.
Banks want it because credit card transactions are significant (almost infinitive) more profitable than distributing physical money around and having bank offices open for customers. Especially in Sweden where the population/km2 can take a very sharp dive and the distance between banks and ATM's can be far.
Many large companies also wants it. Mass transit want that people get a subscription so that the only one buying tickets is tourists that then can pay tourism prices. Supermarkets want that people user the membership card that is linked to a credit card.
If the purpose was only to do crime prevention then the solution would look very different. Instead what we have is the mixing of multiple interests of strong parties against the interest of everyone else.
Here's a good Canadian example - banks now refuse accounts to "high risk" businesses like money services (currency conversion etc.) under the guise that the KYC/AML requirements involved make it too risky for the bank to service them. And yet, our major banks have huge currency conversion businesses - so in essence these laws are being used to stifle competition.
For merchants, credit cards and debit were originally billed as items that would improve their sales - so who cares if interchange fees add up to a whopping 3% on transactions? But now with almost everyone demanding that stores accept credit/debit, merchants are hit with what is essentially a non-government tax on their revenues. Every "cash back" or "rewards" card is basically funded at the expense of merchants.
We have/had that in the US too: https://en.wikipedia.org/wiki/Operation_Choke_Point
In this case the federal gov't (FDIC and DOJ) pressured the banks. They even attacked a Constitutionally-protected activity (firearms)
For that reason I'd like to see legislation which makes it illegal to refuse customers on the basis of their business model, so long as it is legal.
Then the other half of my brain is like "you're expecting the gov't that gave you Operation Chokepoint to do a 180 and suddenly be benevolent?" and "the reason banking is congealing into an oligopoly in the first place is because of the staggering amount of banking regulations churned out by the gov't every year, significantly raising barriers to entry" ¯\_(ツ)_/¯
If your car ever gets towed away on a private-property parking violation, good luck getting it back paying in anything but cash.
My barber takes cash only.
It's not as uncommon as you might think.
With a combination of new online banks that have no physical presence, credit and debit card fees capped by EU laws, and businesses who are happy to pay those fees to get rid of cash, it makes a lot of sense.
They pop in one with modified code and reboot it to read the new drive.
Only similar ATM I can guess in Canada would already be suspect, in convenience stores, clubs, weed shops, strip clubs lol... The none bank name brand.
Had one bluescreened after taking money from account but before outputting money.
Was running Windows.
Didn't give any money, but kept the money from the account.
Had to call my bank.
Ok, like breaking the machine open, but that's cheating, and hasn't got a lot to do with software security.
Obviously they do add features, like topping up phone credit or bill paying. But I would guess nowadays the bankers would rather pay smartphone app developers rather than the ATM developers...
[0]depending whether you do (or even consciously don’t) include indirect costs such as law enforcement and knock-on effects such as funding other areas of crime with the proceeds
I would argue that Windows isn‘t at all the right OS for this.
If you wish, you can put the actual UI in a separate chip, with more modern hardware, handling rendering and input.
But please, do not run the control logic for the ATM on a desktop OS
You don't need a fully featured OS, with the massive attack surface that it provides.
I think this applies, mutatis mutandis: https://xkcd.com/463/
Also Windows CE.
A lot of people are not comfortable with that.
What we should be agitating for is proper control over the use of this info, not trying to limit ways to collect it.
https://www.csoonline.com/article/3202771/data-protection/ge...
But laws are tightening on cash payments, a lot of countries have already made cash transactions over a certain amount illegal. At the moment only for services, you can still exchange cash with your friends, but you may get a lot of scrutiny if you wish to deposit said cash into your bank account.
Cash is doomed by the same problem - it's inconvenient, and also pretty insane to carry around paper tokens when we could carry digital ones.
Even if you do manage to evade some tracking (e.g. by using cash) cameras are tracking you everywhere, we have facial recognition improving rapidly, car number plate tracking etc etc. At some point it will be possible to track your entire life with ease simply from following your movements, and it will be very difficult to circumvent without laws to control that sort of information.
I do think it's more important to control the use of extensive personal information and tracking than to try to limit it, because limiting it simply won't work, and can be easily bypassed.
We had this in Austria a few months ago where one if the biggest providers for electronic payment terminals stopped working for 1 1/2 days