22

As I'm sure many of you have heard, the end of support for Windows XP is the supposed apocalypse for ATM's worldwide. I am cognizant of the fact that this ensures that no more patches are issued, and that banks need to take that threat seriously. I'm having a hard time identifying potential attack vectors and to me it seems as though this is being sensationalized.

We know that the majority of attacks against ATM's are against the environment of the ATM (ie Card Skimming) and not with the software itself. This threat may never completely be eradicated. That said, can someone point out how the software running the software could serve as an exploit?

Perhaps I'm being naive, however the machine itself offers limited physical interfaces to exploit - No USB or other bus ports, access to a serial port, etc. The network is (theoretically) locked down with means outside the OS running on the ATM, and the only vector I could see possibly being exploited is the card slot itself.

How could someone exploit the OS the ATM is running on?

DKNUCKLES
  • 9,237
  • 2
  • 37
  • 47
  • 4
    Does the OS-agnostic method of gaining root access by driving a stolen car into the ATM count? Because that and injecting acetylene or propane through the slit and blowing the complete thing to pieces are the most common ATM exploits happening more or less every week here. – Damon Mar 20 '14 at 11:38
  • Last I knew, many ATMs were not running Windows XP. I won't say what those are running, in this context; obscurity does have some security value. – keshlam Mar 20 '14 at 14:36

8 Answers8

14

Well there's a couple of potential attack vectors which could be relevant.

First up ports. Surprsingly some ATMs do indeed have USB ports and have been attacked via them (more info here as an example and also this CCC presentation on infecting ATMs with malware). However you'd hope that ATMs have decent physical security to help mitigate that class of risk.

Then there's attack over the network. One of the downsides to windows XP is that services like SMB are running and pretty much impossible to disable without making it very hard to manage the system. You could obviously firewall off the ATMs but there still needs to be some network connectivity for management and to transmit transactions.

Now you'd hope that everyone's ATM network is physically separate and not contactable from any other network, but the idea that companies will maintain good air-gapping is not likely to hold 100% of the time in the real world (look at all the SCADA problems that people thought would not happen due to all SCADA systems being Air-gapped!)

So the answer really is that ATM software will be attacked the same ways that other Windows XP systems will be, it may be harder to carry out but not impossible.

Rory McCune
  • 60,923
  • 14
  • 136
  • 217
  • 2
    Actually and unfortunately they put the money in the vault and the pc on top rather than the other way around :( – Lucas Kauffman Mar 19 '14 at 17:21
  • FYI, ATMs are rarely air gapped. They may be on a secured segment, but they need network access for authorizations and maintenance. – John Deters Mar 19 '14 at 23:04
  • Many ATMs are "air gapped" in a sense that financial data is exchanged over a dedicated modem with a dumb interface. Those can be of raiser curious varieties, such as modems using GSM voice channel for data. – oakad Mar 20 '14 at 04:15
9

Personally I don't think that the support end of Windows XP, is such a great deal for embedded systems like ATMs. I gave a quite detailed answer to this here. It definitely matters for the consumer market, though.

In regards to your question on how these things might get exploited, refer to this blog entry for a few examples from the past. I think you are right in stating that it is hard to come up with schemes that directly attack the ATMs itself. They don't have anything, but the keypad to interact with and I don't think you can reach them directly through the public Internet.

Most of the attacks have at least some sort of social component (e.g. impersonate maintenance staff) or are about skimming cards and such. The latter could even be prevented in most cases by explicitly using chip based systems rather than some sort of magnetic stripe.

Karol Babioch
  • 1,247
  • 8
  • 10
  • I have revised the topic of the question as I think the new topic is a bit more appropriate and reflective of the actual question at hand. The content between the two questions is not similar at all. – DKNUCKLES Mar 19 '14 at 16:19
  • I've changed my answer to better reflect your changed question/title ;). – Karol Babioch Mar 19 '14 at 16:44
  • Its also potentially possible to encode magnetic strips that would exploit vulnerabilities in the card reading code (such as buffer underruns/overflows). Not that far fetched considering the data protocol for the card is probably some proprietary binary format. I'm no expert on that though. – Tim Lamballais Mar 19 '14 at 18:26
  • @TimLamballais: Yes, in theory it might be possible, don't know of any story where this has occurred in practice though. Furthermore this doesn't necessarily have to do with OS security. – Karol Babioch Mar 19 '14 at 18:34
  • 2
    This is similar to my comment on your other post you referenced above, but I will comment here since that was closed. ATM networks cannot be 100% sealed from corporate networks and they may not exclusive to one bank. There is remote admin, software upgrades for the ATM applications, and they do get patched. You can attack the ATM software or the specific hardware, but attacking the OS is a different set of problems. Just because it looks like a terminal app, doesn't mean its not just a normal windows GUI. Crimeware aimed at specific platforms does not necessarily require a social aspect. – Eric G Mar 19 '14 at 22:49
2

The end of support for XP is not that big a concern for ATM security as it is the lack of overall support for the operating system. Right now when an ATM manufacturer runs into an issue with XP they cannot resolve they can call the vendor and get assistance, once XP is end of life Microsoft can simply refuse that help. ATM manufacturers looking to bring in new features may be limited by that lack of support.

That's not to say that there are no security concerns, as Ploutus shows. Ploutus is a malware used by thieves who can slice into an ATM and access a USB port. It started in Mexico but has now been seen in Europe. It exploits an XP vulnerability which will be patched while there is support for the OS. Once that support goes any new vulnerabilities found will remain open, so ATM manufacturers won't get any help.

GdD
  • 17,291
  • 2
  • 41
  • 63
2

Step back from the details and look at the larger question:

Can a computer program that accepts inputs be exploited?

The answer to that question is always yes. Always always always.

It doesn't mean it will happen and it doesn't mean it would be easy but the potential for exploitation exists.

Even an extremely simple program written in a very well-defined language is risky because it has to run through a compiler or interpreter (which is probably complicated) and be executed by an operating system (which is probably complicated) and run on a CPU (which is probably complicated).

With that in mind, back to the specific question…

ATMs run on operating systems built on code and run applications written in code. That code was written by people who are fallible.

Here's a possible attack scenario: tamper with the power source for the ATM and get the host to power down and then power back up. Sometimes when systems reboot they give you the option to boot into a single-user or recovery mode. In that state will pushing buttons on the ATM key-pad make it through to the host as keyboard input?

u2702
  • 2,086
  • 10
  • 11
1

"Limited physical interfaces" aren't much of a limitation. For example, this video shows someone completely re-programming a console video game (Super Mario World) using only the game controller.

Mark
  • 34,390
  • 9
  • 85
  • 134
0

Additionally, the card itself could also be an attack vector. Remember that the data on the card must be read by the ATM and will be parsed by potentially exploitable code.

EDIT: Removed erroneous comment about data format on bank cards.

Tim Lamballais
  • 282
  • 1
  • 4
  • As stated above, I don't know of any practical attacks on this front. Depending on how exactly the ATM software is implemented it doesn't necessarily aim at the OS itself, which is what the question is about. A badly programmed application can be exploited on any platform after all. – Karol Babioch Mar 19 '14 at 18:38
  • I agree chances are remote, but there are still potential hazards in OS packaged libraries for parsing data, OS packaged drivers for devices that provide connectivity with the card reader, etc. Stranger exploits have happened. – Tim Lamballais Mar 19 '14 at 18:45
  • Bank cards use [ISO/IEC 7813](http://en.wikipedia.org/wiki/ISO/IEC_7813), hardly a proprietary binary format. – gowenfawr Mar 19 '14 at 19:27
  • Ah I should've guessed that there were standards for that. Let me amend my answer. – Tim Lamballais Mar 19 '14 at 19:33
  • Legitimate cards follow the standard. A hacker's card could be quite different, and perform a buffer overflow attack, for example. – John Deters Mar 19 '14 at 19:42
0

We know that the majority of attacks against ATM's are against the environment of the ATM (ie Card Skimming) and not with the software itself. This threat may never completely be eradicated. That said, can someone point out how the software running the software could serve as an exploit?

There are attacks against the ATM software, but those are different from attack's on the operating system. When you talk about card skimming or splicing into the hardware, those are separate concerns from the operating system. An operating system security patch typically addresses things like privilege escalation, accessing protected memory, etc. Since the ATM is essentially a computer with a touchscreen and a card reader, if you can takeover the computer and force it to run code its not intended you can modify data, capture data, change the way the program functions. So, if the system is not patched, perhaps I can now execute arbitrary commands with the highest privileges and force the ATM software to do something different.

I think you may be romanticizing the complexity and security of Bank ATM roll outs. ATMs may not be on public networks, but they are often certainly accessible for internal corporate networks. If you need to troubleshoot a box, upload software, etc. you probably don't want to send a Tech out into the field. So, if you compromise the Bank's network you can pivot to the ATM network potentially. You should consider malicious insiders at the Bank taking advantage of flaws in the system.

From the physical standpoint, you can run ATM software on commodity hardware. If a tech goes out into the field, he can of course hook up equipment, keyboard, etc. An attacker could do the same. Some bank's have ATMs built into store front, where the back can be accessed from inside the store. I have seen examples where there is a simple pad lock to protect it on the inside. It would not be difficult to gain physical access.

Here is an example: Let's say you took advantage of something like ms12-053 and developed a real world exploit. You will target this PC from inside the corporate network, or perhaps they are not encrypting their traffic and you physically splice in or otherwise can network level access locally/physically. If you can execute arbitrary code, perhaps you install some malware or remote reporting tools. If you are organized crime, maybe you have a specific exploit to run against the ATM software or a malicious version and you just replace the real ATM software.

At the end of the day, its not different than if you did not patch a pc or server. The difference is that if you can compromise this system, you have a better change of stealing money, identity theft, etc.

Eric G
  • 9,691
  • 4
  • 31
  • 58
0

It's not uncommon for ATM to be in the same ethernet segment as the local PCs. They often use 802.1X/port security to "protect" the network, but it's easily to circumvent by adding a simple hub to the port (at least the most deployed setups).

So here is an attack scenario: You could sneak into the bank and install a hub and a tiny/embeedded system + GSM modem, then login to your system remotely and wait for the switch port to get unblocked by the banks' personal. After that, you have a backdoor in the bank. Now it's just a matter of exploiting bugs in Windows XP which shouldn't be that hard.

Given that network design, you can of course just try to get access via wifi or getting a backdoor on an employees PC. There are a lot of options.

Thing is: They all require you to be there in person to actually retrieve the money, guess that's why we don't see such attacks often.

Johannes 'fish' Ziemke
  • 101
  • 1
  • First: There are ATMs that will _accept_ money to transfer it into some account - based on a card inserted. Compromising such an ATM opens the possibility to transfer such money (the revenue of one day for a 'small' shop owner) to a different account - possibly compromised in a different way. Then you go to a different ATM, get your money and disappear. Second option: Get the compromised ATM to give you the card credentials of any/all users. No need to be present in person, create a new card with stolen credentials, go to any ATM and collect your money. – Johan Bezem Mar 20 '14 at 16:30