I must confess that ATMs have always intrigued me. Don’t misunderstand me though… I know that, in most cases that would sound like a rather “suspicious” statement for obvious reasons, but trust me when I say that it is not about the money they hold, I really do genuinely find them fascinating devices for the way they are built, and not particularly for what they do.
This is why I couldn’t have been happier when I recently was given a chance to put my hands on a fairly broad set of ATM machines. It was in the context of a broad security auditing project aimed at evaluating the overall network and application security posture of the ATM base for one of the most important and renowned banks in the world. So I thought that it would be nice to share at least some notes from the fun and rewarding experience I had since it cannot exactly be considered an everyday business case.
Determining the surface of exposure
As usual, preparation starts with defining how an ATM works in practice and what the critical components and interfaces are. More specifically, it’s key to define what determines a target’s actual “surface of exposure”, which is why I started with the basics and studied the main elements of an ATM.
From a front-end perspective, you notice that most ATMs have two main inputs (card reader and keypad) and four outputs (screen, receipt printer, cash dispenser and speaker). However, simply hacking into an ATM by leveraging on such user interfaces would not be a recommended approach. And, the ATM application would have to be affected by very significant logical flaws.
Of course, the picture changes quite a bit when we look at the more interesting and “richer” back-end side. There’s a whole bunch of other input/output interfaces and connection points that populate the “dark side” of an ATM (or, better, the IT-related side that nobody ever sees) i.e., the connection to the authorizing ATM financial host, administration applications, application software downloading, operating system updates, monitoring of the ATM, anti-fraud, just to mention a few. Either way, should truth be told, ATMs are no different from any other common (stand-alone) network-attached device. That basically means that, just like any other common network-reachable entity, any exposed service, system or application interface could be attacked by anyone with access to a local or adjacent network segment. And, that was actually at the core of my activity as ATM security assessor: trying to manipulate the various detected interfaces with the aim to determine if unauthorized access or other malicious activity could lead to unauthorized distribution of cash.
XFS and overall architecture
Before doing that, I felt the need to study the ATM-specific architecture that underlies the proper ATM application. In general, from a logical standpoint, the ATM application doesn’t run directly on top of the OS (in most cases a stand-alone Windows desktop system, such as 7, though XP might unfortunately still be around) but there are some layers in between. Apart from various ad-hoc security solutions that allow the ATM application to run in a very restrictive environment with limited services and processes in the back end, which may vary from deployment to deployment, an ATM architecture will always involve a so-called XFS (eXtensions for Financial Services) middleware layer. Such middleware normally provides a client-server architecture for financial applications built on top of the Windows platform. In particular, peripheral devices such as ATMs, which are unique to the financial industry.
XFS is an international standard promoted by the European Committee for Standardization (known under the acronym CEN, hence CEN/XFS). It provides a common API for accessing and handling the various peripherals and financial service devices regardless of manufacturer.
The ATM application then communicates through the XFS layer, which in turn is the one actually giving commands to the hardware. As such, it is therefore the one that, for instance, interacts with the cash dispenser of the ATM to dispense the cash, which explains why access to XFS commands should be very carefully restricted through the access control mechanisms of the ATM operating system.
This also explains why gaining knowledge around XFS might be key when assessing ATMs. This was by far the most time-consuming part of the preparation, also since XFS is usually the result of a proprietary development by the ATM manufacturer and involved lots of documentation.
Pentest approaches
At any rate, it’s clear that a preparation strictly depends on the actual approach that will be followed during the active part of the testing. What I mean is that if you’re about to carry out a white-box penetration test, that’s obviously a must-do. If you’re instead more on a grey/black-box area, then it is rather left up to you to decide, depending on whether you think you’ll succeed at getting access to either the proper ATM application or OS. Which, trust me, is not absolutely granted – which is a good thing!
So, once again, you quickly realize how, in the first instance, it all boils down to treating ATMs like any device that you could find attached to a network. Therefore, in most of cases a penetration tester will most likely not be forced to work outside his/her usual “port map/vulnerability scan/exploitation” comfort zone. Which doesn’t mean that assessing ATMs is an easy feat. Keep in mind that ATMs have specific threat models that one must be aware of!
Network Traffic Sniffing
Aside from trying to break into the systems through credentials brute forcing at any detected login point and attempting to exploit possibly unpatched or insecurely configured network-reachable services, another broad set of testing activities that can be performed are determined by the inspection of sniffed network traffic, if and whenever there is a chance to do that. Those who are familiar with network traffic analysis will be well aware of how much of a challenge such a phase can be, especially when in the presence of swarms of (almost never self-explanatory) connections to and from the surrounding environment. Putting all sniffed traffic in a sorted and intelligible format can be a really involved matter and you can expect tons of uncommon proprietary protocols. It will however provide plenty of useful info that might, even significantly, extend the usual borders of a pentester’s checklist. Just for instance, we have a way to determine whether weakly encrypted, or, even, plain text communication could transmit possible critical or sensitive data. In general, you get a definitely accurate, high-level picture around the whole surrounding IT ecosystem, which is what I meant with “extending the usual borders”.
Indeed, although some may regard it as a bit of a boring test phase, I have actually gotten some of the most interesting findings right during such a stage of my activities! Looking at generated network traffic discloses what’s really going on behind the curtains and, in fact, enabled me to both confirm the nature of findings detected in previous (more active) phases and, at the same time, indirectly guess other system and application configurations that could not be inspected directly.
Defense in depth
It was right at this stage that, thanks to the knowledge collected through the network traffic analysis, my commitment broke outside the boundaries of a common, internal network/application pentest engagement and turned into a more proactive security consultancy, aimed at securing the targets to the bone as best as possible. So I focused on the proper onboard ATM system itself and helped my technical contact person define a set of bespoke patch packages, which were tuned in a way to achieve the following main security goals:
- Enable only necessary system and network services and disable anything else
- Prevent the ATM application from being bound to any network interface
- Harden the necessary services and OS according to the most relevant industry accepted configuration standards
- Impede direct inbound access to the necessary services through a combination of both local and perimeter FW policies
- Revise the encryption settings of all of the client components, so that the strongest possible ciphers and protocols only are enabled (if and where possible, of course, compatibly with what the various server endpoints actually negotiate)
- Never allow ANY plain text data exchange between client and server endpoints, not even for minor accessory services
Happy ending
By putting all of the above pieces together at the same time, and adding some other ad-hoc security mechanisms, such as IP-based connection rules towards the server endpoints with two-way certificate validation enabled, the network-related surface of exposure of all of the in-scope ATMs was so dramatically and effectively reduced so that IT-based attacks now seem to represent an attack channel with an extremely remote risk of compromise. Not even if you got to attach yourselves to the ATM directly and tried to split the main TLS channel toward the authorizing host. In a nutshell, if you want to get cash in an unauthorized way now, you’d better turn to the “good ol’ rude manners”.
Conclusion
It is not an easy task to describe such an extensive job in a few lines. Also, I could not disclose too much detail for obvious reasons, which is why this post could not come in form of a more explicit technical tutorial.
Either way, one thing should be clear: it’s almost impossible to meet the expected security goals without first getting a full understanding of the targets’ nature and overall context, especially when they are so uncommon. Which translates into: always allocate enough time for studying, reading documentation, googling around, getting yourself fully knowledgeable around the kind of targets you’ll have to deal with. And, ask all possible questions that might come to mind: the more knowledge you acquire in advance about the targets, the more power you have when testing them.
To conclude, one resource that considerably helped me define a bespoke checklist in the considered engagement, was PCI ATM Security Guidelines (in particular, Chapter B), since it’s a really inspiring document when preparing a security assessment of this kind.
