ATM attackers strike again: Are you at risk?

The United States National ATM Council recently released information about a series of ATM attacks using rogue network devices. The criminals opened the upper half of the ATM and installed the device, most likely into the Ethernet switch. The device then intercepted the ATM’s network traffic and changed the bank’s “withdraw denied” response to “withdraw approved,” presumably only for the criminals’ cards.

For many readers, the attacks’ success may be surprising. However, IBM X-Force Red has warned our clients of this type of attack for a while. The success is due to ignoring several, well-established security principles – good locks, network encryption, and rogue device detection.

Locks aren’t just for canals

Before I started testing ATMs eight-years-ago, I assumed that their physical security would be great. In fact, the external locks on an ATM are usually trivial to pick. On an ATM test this summer, I was with a colleague who was skilled at network and application testing but had never tried lock picking before. He saw the rest of our team open the locks and wanted to try. I gave him a one-minute lesson on rakes and tension wrenches and set him loose. He was able to open the ATM within 20 seconds – the very first time he had every tried picking a lock!

The internal safe that holds the cash is usually protected with exceptional locks, but the safe is literally a USB-connected cash dispenser. The computer that controls it sits in the upper half of the ATM enclosure. The network equipment, often a small router/switch combo, is usually right next to the computer.

SS-What?

Arguably the most popular encryption protocol in the world, SSL, was released over 20 years ago. It is ubiquitous on the Internet along with its successor, TLS. X-Force Red always recommends that applications use SSL encryption. Even when an application uses some method of data field encryption, it is often vulnerable to issues such as shared encryption keys, and network replay attacks. One of the more common arguments we hear is that the application is only designed to be used on trusted networks.

In the ATM world, the definition of a “trusted” network tends to be a bit more expansive. ATMs can be connected to the backend servers in a variety of ways. Some are connected using traditional telephone lines (POTS). Many modern ones are connected using cell phone networks. And quite a number are using Ethernet connections connected to the organization’s sites where they are deployed.

During one particular ATM test we performed, we discovered that the ATM was not encrypting any data between the field unit and the backend processor. We pointed this out as a finding, and the service provider argued that the device was deployed in a trusted environment, and that no one would be able to access the system or the network lines. Unfortunately, we’ve seen time and time again that supposedly “safe” network connections are ignored by staff on a routine basis. Everyone assumes that the guy who looks like a service technician has been validated by someone else and obviously belongs there. “Private” networks in areas accessible to the public are anything but protected.

Some vendors will argue that because they are unware of methods to compromise a communication method that the method is safe. Unfortunately, the criminal world is very much in tune with the latest technologies and is adept at deploying them in a swift manner. We advise anyone designing platforms to deploy their own encryption using vetted libraries implemented for this purpose. Depending on the integrity of a cell phone network, they could be one exploit away from disaster.

Rogue devices

It is hard enough to keep track of legitimate devices, let alone malicious ones. Network closets and ATM enclosures are often chaotic, to put it mildly.

Rogue devices can be incredibly compact as well. During the last five years, there has been a proliferation of small, off-the-shelf computers. The $50 device below is about one cubic inch (16.4 cubic cm), barely larger than the RJ-45 port. It runs Linux, has a microSD card for storage, and Wi-Fi for remote retrieval. It can be powered from a USB port, external battery, or a powered Ethernet switch. Unless someone was specifically looking for rogue devices, it could be easily missed.

Network Access Control (e.g., 802.1x) can make it more difficult for attackers to introduce unapproved devices. However, attackers sometimes find ways around NAC, and it can be very expensive to implement. Regardless of which access controls are on your network, assume that an attacker can eventually gain access.

Not just ATMs

The risk of rogue devices goes well beyond ATMs. Many organizations routinely use plain text network protocols on their internal networks. “But it’s not going over the Internet” is the typical defense. That may be true, but how well do you know your environment? The larger the network, the easier it is for someone to access it. Posing as janitors, delivery staff, or job applicants can give a criminal access to employee desks. It may only take seconds to introduce an attack device where no one will see it.

What banking institutions should know

Validation is obviously critical for security. X-Force Red recommends regular testing of all systems and networks that handle sensitive data.

ATMs are particularly important because they store actual cash, handle financial data, and can be used as a beachhead into an internal network. X-Force Red recommends the following best practices for ATM testing:

• Conduct an in-depth, manual penetration testing of the ATM’s physical security controls, electronic hardware, software, OS hardening, network communications, and backend systems.
• Perform internal network penetration testing either on-site, or, more frequently, using virtual appliances that allow remote access, but simulate physical access.
• Physically access internal networks using techniques like badge tailgating, social engineering, and even lockpicking.