Security and ATMs - Part 1: Software, Hardware and Attack Surface.
For the last eight years I have worked on various consumer banking ATM deployments for international banks in the Asia / Pacific region, including New Zealand, Singapore, Indonesia and Taiwan. This blog post consists of two-parts; the first part will focus on an introduction to ATM hardware, software and attack surfaces. The second part will detail security measures you can take to help defend ATM deployments against attacks.
ATMs have always fascinated me due to their black box nature and because they create a very unique security conundrum by partially contradicting Microsoft’s third immutable law of security: “If a bad guy has unrestricted physical access to your computer, it's not your computer anymore”. Although access to an ATM is not unrestricted, you do have physical access to the host device and the ability to interact with the Operating System through a touch screen panel or selector keys. ATMs are essentially an authenticated (logged in) Windows desktop running a full screen user-interface, similar in many ways to an Internet Kiosk - only this Kiosk dispenses cold hard cash.
The now famous bank robber John Dillinger once said “I Rob Banks Because That’s Where the Money Is”, and by looking inside an ATM you can see just how much of a target it is. A fully stocked "money dispensing kiosk" can hold $200k-250k.
Over the past six years an increase in the number of attacks on ATM’s has been observed. Attacks are becoming increasingly sophisticated, more targeted and attackers are becoming more persistent.
The increased focus on hacking ATMs also reflects in the research material released by the security community, in particular the late Barnaby Jack who infamously ‘Jack Potted’ an ATM on-stage at Blackhat 2010, making the ATM spew out fake currency on stage. Since 2010, the concept of hacking an ATM has become far more mainstream for both criminal organizations and malware authors who are now capable of “cashing-out” an ATM.
ATM Hardware and Software
ATMs in their most simplistic form consist of x86 commodity hardware, finding an older Pentium 4 running Windows XP or Windows 7 inside an ATM is not uncommon. If you think it’s strange that an ATM may run Windows XP: In 2014, it was reported than 95% of ATM’s globally still used this End-of-Life operating system. In 2016, many major banks are now rolling out new Windows 7 based ATMs. Smaller banks and vendors appear to be stick with Windows XP, particularly in developing countries where upgrading ATM software is not considered a priority.
Hardware devices used on an ATM are for the most part standard USB devices just like other USB peripherals. These hardware devices are listed in the Windows Device Manager, and often communicate using a simple protocol that emulates RS232 over the USB port. From a security point of view, there really is no security of any form. A USB cash dispenser for example, which retrieves and delivers currency from the cash cassettes, does not implement any form of authentication or host validation. If you plug a cash dispenser into your laptop and send the right protocol packets, cash will come out. The same applies for the encrypting PIN Pads and even the (USB) safe alarm. These devices are designed to explicitly trust the computer they are plugged into.
Two locks are placed on the outside of an ATM. The first lock secures the Service Zone where the desktop computer is held and is accessed by the service technician. The second lock protects the Vault Safe which holds the cash cassettes. Cash cassettes hold the ATM's actual currency and can contain anti-theft technologies like dye packs and gas detector alarms, but the vast majority of cash cassettes in use contain no such features. A typical cash cassette is a re-enforced ABS container with an “optional” safety lock.
From a software point of view, ATMs are designed to be hardware-independent financial platforms, able to provide interoperability between hardware vendors and software developers. This is accomplished with the use of a Hardware Abstraction Layer called XFS/CEN, otherwise known as eXtensions for Financial Services or XFS. An XFS manager runs locally on each ATM and is responsible for interacting with the financial hardware components of the ATM, such as the Encrypting Pin Pad or Receipt Printer, and does so via a Service Provider Interface.
Each ATM vendors XFS manager is a bit different but the overall concept is the same:
ATM client software only needs to make requests to the local XFS Manager which will interface with whatever underlying hardware is required. Vendors will install an XFS Manager with service providers for each of the hardware device types in use. This provides a flexible interface for accessing hardware which is compatible between vendors.
Additionally, ATM software vendors deploy a large number of local Windows based applications on an ATM to manage local tasks. Would you be surprised to know a typical Diebold Opteva ATM contains 3-4GB of custom Diebold software running? The extra vendor software support covers tasks such as managing local encryption keys, UPS, firewall, full-disk encryption, software updates, maintenance and remote monitoring.
When looking at an ATM from the attacker's point of view we are presented with a favourable attack surface.There is almost no integrity verification in the communications between any of the components, a large and diverse attack surface, and a design in approach in which security requirements have been overlooked almost completely.
Today’s ATMs face a wide range of attacks from adversaries and the sheer number of different attacks seems to be only growing.
- Malware – Installing sophisticated ATM specific malware on an ATM allows hackers to force the XFS manager to empty the cash cassette on demand. Malware intercepts and modifies local XFS calls in real-time by hooking or manipulating calls made by the vendor software. Malware can be installed by corrupt service technicians or by anyone who gains access to the Service Zone. Malware on ATMs is far too common - in my career I have seen malware installed on 17 different ATMs. ATM malware is now also becoming big business for both developers and hackers and somewhat of a 'growth industry'.
- Blackbox ATM Attacks – These attacks are relatively cutting edge but work in a similar principle to ATM malware attacks. The idea of a blackbox attack is to physically unplug the USB Cash Dispenser from the ATM and connect it to your own Arduino/Raspberry Pi device, bypassing the ATM’s underlying PC altogether. The Cash dispenser is unable to identify that the XFS Manager has changed and it will sit and await instructions from the new manager.
In the photo above thieves unplugged the USB cash dispenser and plugged it into the black box, along with a cell phone to receive “cash out” instructions. This attack would have required cutting a hole in the back of the ATM’s service zone to access the USB ports.
- Sheer Physical Force – Any ATM on the street or in a mall is vulnerable to physical attacks and this is the likely first attack avenue contemplated. In the early 2000’s I watched a talk by the then CISO of ANZ Bank. He mentioned the difficulty of securing ATMs in Papua New Guinee, where locals were observed simply picking up a ¼ tonne ATM by hand and carrying it away. Thieves will use any means possible to try and open an ATM, and although it is possible it is not easy. There have been news reports of plastic explosives and even combustible gas being used to ‘explode an ATM’ (and hopefully open the cash cassetes). A for effort, but this approach is not very subtle.
- Insider Threat – It is not uncommon for a bank with several hundred ATM’s to outsource ATM maintenance or servicing to a third party. All it takes is one nefarious engineer and your entire ATM deployment can be put at risk. In 2010 ,a Bank of America IT staff employee (Rodney Reed Caverly) was arrested for installing malware on BoA ATM’s which would allow him to withdraw funds without any transaction record. In total he stole $284,750 from BoA ATMs between March 2009 and October 2009 until he was arrested and sentenced to 27 months in 2011. Rodney configured several ATMs to not charge him for any cash withdrawals by installing malware that manipulated XFS calls.
- Card Skimming - Skimming is one of the more well-known and traditional forms of ATM attack in which a physical skimming device is placed over the card reader to catch the magnetic track 2 information held on the ATM card, in-conjunction a pin-hole camera or Pin-Pad overlay to capture a user’s PIN code. Many variations of this attack exist and they are incredibly well known and documented, however skimming is still the most prevalent form of ATM attack world-wide. Skimming-related fraud loss in Europe is estimated at 98% of total card fraud loss.
- Card or Cash Trap – Similar to card skimming, a Card or Cash trap is a device that either traps the ATM card or prevents funds from being dispensed to the user.
Shaped like a fork, the Cash trap is installed inside the cash dispenser. It will prevent any notes from being dispensed fully by the ATM and hold them inside. ATM users may assume the ATM was faulty or had ran out of funds to dispense and leave the ATM, leaving the cash inside the cash trap. Once the cash dispenser is opened manually the fork can be retrieved along with the caught cash.
The underlying issue exploited in many of these attacks is a lack of integrity verification between components. For example, ATM hardware has no method of validating the host it is plugged into, and will react blindly to any request sent to it. Similarly, XFS managers do not perform any authentication or validation on local XFS calls, and simply connect programs running locally directly to financial hardware. Although a safe may have a (semi-decent) lock and perhaps anti-theft devices, the USB cash dispenser requires no authentication, and can fully empty the safe.
This underlying security dilemma is systematic of how ATM software and hardware vendors have evolved over the last 15 years, and cannot be easily fixed. There are however a large number of seemingly small changes you can make to an ATM deployment to help stop hackers, or at least make their job significantly more difficult. Part 2 of this blog post will show security considerations and proposed mitigations to secure ATM deployments.