TORONTO—Automated teller machines are a common sight in modern society, and they’re also obvious targets for attackers looking to steal money. Researchers from security firm Trustwave discussed security issues related to ATMs at the SecTor security conference here, outlining their discoveries of ATM insecurity made during penetration-testing engagements.
The flaws are widespread implementation issues that affect nearly all ATM vendors today, John Hoopes, senior consultant at Trustwave, told the audience. Trustwave wasn’t going to point fingers at any one particular ATM hardware vendor, he said.
One of the first steps in a security penetration-test enumeration is to determine what the operating system is for a given device. In the case of an ATM, there is no Control-Alt-Delete functionality (for a system reboot), but Hoopes has a simple solution: pull the plug. By simply pulling the plug of an ATM device and then waiting for it to reboot, Hoopes said he was able to determine what the operating system was running. In many cases, that operating system was a version of Microsoft Windows, typically Windows XP.
With the versions of Windows running on ATMs that Hoopes and his colleagues tested, many were vulnerable to old Microsoft security flaws. In particular, he said that many ATMs are still vulnerable to the MS08-067 flaw, which is a remote code execution flaw in the Windows Server Service that Microsoft patched five years ago.
At least one of the systems Hoopes tested had a dialogue box on reboot that advises the user not to touch the screen during reboot. So what did Hoopes do? He touched the screen and was then able to get access to the core system of the ATM.
To add further insult to injury, Hoopes found that the majority of ATMs are already running in administrator mode. Administrator mode provides a user, or in this case an attacker, with full access to the device.
“So it’s already game over at that point,” Hoopes said.
Security by Obscurity
Among the root causes for insecurity in ATMs are false design assumptions.
“Most ATM software designers figure no one will ever see their code,” Hoopes said. “So no code is obfuscated.”
Obfuscated or hidden, encrypted code is a common best practice for security, making it difficult for an attacker or a reverse engineer to find flaws.
Some of the ATMs on the market today boot up by way of a Preboot eXecution Environment (PXE). In a PXE boot, the ATM gets its operating system and instructions over the network at boot time. As such, if an attacker is able to put a device in between the ATM and the wall where the network connection comes in, there is the potential to manipulate what the ATM is able to do.
Even for ATMs that are not PXE booted, all ATMs connect to a network. Trustwave has routinely noticed that the network is not always encrypted, Hoopes said. If the network isn’t encrypted, it means an attacker can potentially intercept and manipulate the data.
Going a step further, even in cases where the ATM was using an encrypted Secure Sockets Layer (SSL) connection, the implementations were not always correct, Hoopes said. SSL requires the use of a Certificate Authority (CA) that validates that an SSL certificate is authentic. Hoopes said that a number of ATMs do not properly validate the SSL certificate, leaving the machine open to potential man-in-the-middle attacks.
Defense
There are several things that ATM vendors can do to improve the security of their systems. For one, good locks should be used on the ATM cabinets to prevent any kind of lock picking, Hoopes said.
Also important is cable protection so that attackers can’t just simply pull the power or networking cables to get access to a device.
System monitoring and alarm notifications on ATMs are also necessary. ATMs should be under constant monitoring so if there is a system reboot or other unexpected system event, an alarm goes off and someone is sent to investigate, Hoopes said.
“These are computers that live in hostile environments,” Hoopes said. “This is literally where the money is.”
Sean Michael Kerner is a senior editor at eWEEK and InternetNews.com. Follow him on Twitter @TechJournalist.