How a Security Upgrade Has Led to Riskier ATMs
John Abraham
Ironically, banks refitting ATMs for Triple DES security are introducing a serious new vulnerability by moving their
machines to IP networks and Windows software. Segregating ATM traffic is a short-term answer. Longer-term solutions
will be more difficult.
Would it surprise you to learn that unencrypted ATM data are being routed through banks’ internal networks? Would it surprise you
even more that most bank managers aren’t even aware that unencrypted ATM data are traveling across their local area networks? And,
by the way, unencrypted? There’s ATM data that’s not encrypted?
Yup.
Historically, ATMs were connected directly to processors (organizations that provide electronic fund transfers to ATMs
worldwide) via private lines that made it difficult for anyone to tap into the data stream. Encrypted data were protected by the Data
Encryption Standard (DES), which was instituted in 1981. By the late ‘90s, as security professionals publicly cracked DES, it was
clear a new standard was necessary.
Visa and MasterCard mandated a solution in the form of an improved encryption standard known as Triple DES, which is rigorous
enough to withstand code-cracking attempts for the foreseeable future. Triple DES has been instituted at the host level, where the
transactions are accepted, and bank and non-bank ATM owners have been upgrading their ATMs to comply with a somewhat fluid
deadline.
As banks have gone through the Triple DES upgrade, at a cost of anywhere from $1,000 for a simple software update to $35,000 for a
whole new ATM, they’ve taken advantage of the opportunity to aggregate their connections to the processor. They’ve migrated the
ATMs—each previously on its own dedicated line—to utilize a single connection back to the processor.
This connection goes through the banks’ transmission control protocol/Internet protocol (TCP/IP) networks. This eliminates
expensive leased-line fees, streamlines ATM management functions, and supports up-to-date functions such as touch screens and
video.
However, the bank’s network that simplifies so much is often connected to the Internet. Also, because IBM Corp.’s OS/2 operating
system is no longer being supported, ATMs are switching to Microsoft Windows.
The banks’ own networks? The Internet? And Windows? What could possibly go wrong?
Passive Sniffing
While it was always theoretically possible to get access to the data-communication lines carrying ATM data, it was very difficult and
required a high level of expertise as well as physical access. It is much simpler for an attacker to get onto the banks’ LANs in a
reasonably inconspicuous manner.
So? Aren’t the data encrypted? Isn’t that the whole point of Triple DES?
As Jon Stewart is fond of saying, “Funny story. Not so much.”
It turns out that only the personal identification number (PIN) is encrypted. The card number, expiration date, account balances,
transaction information—all that data goes across the banks’ networks in clear text, which, as the name suggests, is not terribly difficult
to decipher.
This protocol goes back 25 years, to when not only was the PIN uncrackable, but the data itself were traveling from a single ATM
through a dedicated line to the processor. Now, the data from all of a bank’s ATMs are going through the bank’s LAN before being
forwarded, offering the added benefit of economy of scale for insider and Internet-based attacks.
An additional problem introduced by TCP/IP networks running Microsoft Windows is the potential for worms and viruses to shut
down ATMs, or to be subject to denial of service attacks. In 2003, the Nachi worm infected Diebold ATM machines at two different
U.S. banks.
In a nation that loves its $29 Staples paper shredders, it’s probably disconcerting to many to know that their ATM information
isn’t exactly Triple DES-proofed. The most obvious consequence of this ATM vulnerability is the possibility of forged plastic. When
the data sent in clear text are captured, a duplicate physical card can be created for signature-based transactions or online purchases.
This information can be passively sniffed off of the wire without setting off any alarms.
A second, somewhat more theoretical attack is based on the lack of protection inside the current architecture. There is an inherent
trust relationship that exists between the ATM and the processor; the data stream between the ATM and processor gateway is assumed
to be secure, and the source of the data stream is trusted by both the processor and the ATM. Yet, there are no controls built into the
protocol to protect this trust relationship.
Perhaps the easiest attack would use a so-called man-in-the-middle technique to gain access to the data stream, allowing an attacker
to spoof either end of the connection. By spoofing the processor, it may be possible to direct the ATM to dispense money without the
processor ever knowing a transaction occurred. Indeed, without the processor enforcing a daily maximum withdrawal limit, it may be
possible to empty the entire ATM. Back up the money truck.
By spoofing the ATM, an attacker could infiltrate existing accounts, the credentials of which were captured on the network.
Ironically, the encrypted PIN is more useful for network-based attacks than the actual PIN. Once a user’s account number and encrypted
PIN are captured, their account is compromised until the ATM encryption key is changed—often months away or never. With these
credentials, a number of attacks are possible, such as an account-balance modification or transfer.
Clear Text Forever?
The good news is that none of these problems are insurmountable. The solutions are mostly operational, and involve awareness as much
as anything else. The bad news is few bank managers are aware of the potential problem: they are generally surprised to learn that
unencrypted ATM data flows through their network.
The simplest, most important step that banks can take is to segment ATM traffic from the rest of the bank’s network flow. They
need to institute rigid operating standards and procedures, and to have strict firewall rule sets. Physically separating the ATM network
from the bank’s Internet-connected networks is the optimal solution, but if that’s not possible, then firewall segmentation is essential.
Even more important than making sure banks are informed of the potential risks is making sure that vendors know what they are
selling. With more than a million ATMs worldwide, there’s a huge market of ATMs that need to be upgraded. Vendors must be sure
that they are including all of the protections needed to ensure that migrating to a TCP/IP network running Microsoft Windows doesn’t
create new vulnerabilities.
Longer term, large-scale solutions are much more difficult, precisely because of the sheer number of ATMs in use. It’s taken years
to upgrade to Triple DES, and the process is ongoing. Changing the application protocols to prevent sensitive information being sent
in clear text would prove to be as or more difficult, with less obvious advantages to the ATM owners.
Encrypting the remaining clear-text data from the card also seems like an obvious solution, but that information currently has
additional uses. For example, the first few digits of the card number are used for routing purposes, and the expiration date is used for
authentication purposes. Additionally, a number of services rely on customer information sent in clear text—such as video
surveillance systems used to monitor ATMs—which creates an additional concern when allowing third-party vendors access to this
sensitive information.
What is the extent of the problem? Based on Redspin’s security audits of over 100 small to mid-sized banks, a majority of them
were found to be unaware of the problem, which is in itself a big problem. While there has been no public disclosure of attacks taking
advantage of these vulnerabilities, further awareness of the issues is necessary to proactively address the problem.
Redspin will be holding an academic contest with an entire mocked-up system, including an actual ATM, to determine how
theoretical these vulnerabilities are. We hope this will also identify some more solutions.
The recent news concerning the compromise of hundreds of thousands of PINs and customer account numbers associated with
Sam’s Club and OfficeMax should alert issuers and processors, indeed the entire banking industry, that network-based attacks are
growing in severity.
ATMs are not immune to this trend because they share the very same network and similar protocols as point-of-sale devices. While
Redspin has mostly focused on smaller to mid-sized bank architectures, even larger banks with TCP/IP ATMs are vulnerable without
the proper controls. All of these devices use the same application-layer protocol with sensitive customer information transmitted in the
clear.
So the problem is urgent. Banks that haven’t already protected their ATMs from the rest of their network should do so quickly.
John Abraham is president of Redspin Inc., Carpinteria, Calif., an independent auditor specializing in network security assessment and
compliance. Contact him at jabraham@redspin.com.