Before this pandemic, Neil Burrows and myself (Bruno Oliveira) from Trustwave's SpiderLabs were assigned to an ATM engagement in a beautiful country by the coast in Central America. Previously, I had some experience with PoS (Point of Sale) devices and entertained myself with kiosks at hacking conferences, but never had touched an ATM before. My companion on this saga had already some fun hacking with these devices and had some precious insights to guide us during our engagement.
In this engagement, we worked with two different brands. The next ATM schema can be applied for both.
Even not being able to touch/hack ATMs before, we know by fact that ATMs are nothing more than a simple PC with some security hardening and a big lock!
We enumerated some challenges that could be divided into four parts: Physical, Software, OS, and Network.
The physical part is composed of the locks, tampers, and safe. Each vendor uses a specific manufacturer for the components and may improve quality over the versions and updates. Sometimes, the customer may update their locks with no contact with the ATM vendor. So each ATM has unique characteristics. The physical part also includes a USB or another port (e.g. Firewire) where access could allow interaction between the attacker and the machine.
The software is an important piece of this puzzle as it provides the interface between the user and machine and also handles all the transactions. Of course, this includes ATM balance and withdraws -- our main goal. The software normally works with a standard API called CEN/XFS or XFS (extensions for financial services) to deal with this type of operation. This is very relevant information since that could be utilized for compromise.
Then, we have the Operating System that could be manipulated in order to try to prevent unauthorized access to files and applications. There are numerous techniques for bypassing security controls set to protect the system's internals. This could allow malware execution. Each vendor takes its own precautions in the arena as well.
And finally, the network. While most of the applications work through encrypted traffic, it is possible to investigate the traffic to discover holes in the transmission where plain-text data can be identified. Also, as seen in this case, it represents the network security setup to protect the perimeter of the ATMs when receiving and sending data over TCP/UDP ports.
In every element of this schema, the vendor might work to deliver the most secure environment possible and we, as testers, have to find security flaws for successfully exploiting the devices.
While exploring the opportunities for exploitation we set some goals for the engagement:
After we bypassed the physical part and opened the ATM, the machines were all ours for control.
Once opened the USB ports were enabled and available for both ATMs. This allowed us to plug in our HID devices and proceed with the engagement.
In the 1st ATM, we were unable to call any application or resources using shortcut keys including Microsoft Help which is "helpfully" known for breaking out of a gated system or sandbox when invoked.
After discovering that the Operator Mode was protected by a default password ("000000"), we discovered that it was possible to modify settings to allow us to jump to the Microsoft Help.
After we were able to break out of the sandbox and then we could search for “cmd” and open it.
This wasn't easy at first. I tried multiple applications like explorer, notepad, and others with little luck. We quickly identified that the context menus were disabled. It means that it was not possible to use the right-click for executing an application. Therefore we were unable to use the "open/save file" feature and interact with system files to open the "cmd" application.
In the 2nd ATM, we could call the Help (Win+F1) after using the ALT+TAB keys to move from the ATM application to the desktop. At this point, we thought we were done and could use the same process as 1st ATM. But, alas, "cmd.exe" was disabled.
The context menus were enabled in the 2nd ATM vendor, so we were able to open applications like notepad.exe using Microsoft Help but while trying to use "open/save files" we were unable to see the files on the disk, only on its own directory. There was some kind of jail that was applied -- different from 1st ATM where it was possible to browse all files with no restriction.
However, while looking for files from “System” as root search we could reach any file on the disks. We were still unable to execute "cmd.exe", but fortunately, we could search and run "command.com" which gave the same ability to execute commands on the system as well.
On the 1st ATM vendor, the USB mass storage was disabled, so we used an FTP server on our local machine to transfer the files to the ATM. On the 2nd ATM vendor, the USB mass storage was enabled making it possible to plug a USB flash drive for copying files.
We were only able to communicate with the ATM because the network access on the ATMs' motherboard was accessible -- in some cases, the cable with the connector was provided as well. That allowed us to connect and receive connections from the 1st ATM.
Even with the protections that could be done in the OS, it is very common for the client to adopt additional protection layers for controlling what binaries are allowed to run on the system. The application control will whitelist the specific binaries that can be executed in order to prevent malicious files.
To bypass the application control in place for both ATMs we used the approved binary MSBuild.exe from the .NET package along with C# code. That allowed us to run anything on the system including a meterpreter payload.
We also utilized the RunDLL32.exe with our special code compiled as being DLL. This code takes advantage of the XFS API for dealing with the transactions on the ATM.
The application was then used to withdraw test money from the machine, our ultimate goal!
BIOS Password
The 1st ATM was running using the default BIOS password ("*******12345"), so we could change the boot order to use any other portable system and investigate the installed one.
Disk Encryption
Both ATMs did not have disk encryption. On the 1st ATM with a default password on BIOS, it was possible to collect critical files from the system including the SAM database.
Windows 7 End-Of-Life
Both ATMs were running Windows 7 despite the fact that it has been end-of-life with no more security patches being issued by Microsoft.
Despite these techniques being relatively well known, we still have plenty of old/outdated/bad ATM versions running across the world. The subject still demands more attention and during this engagement, we saw some interesting things. While the 1st ATM had the context menus and USB mass storage disabled, it was running under the local administrator. The 2nd ATM disabled the "cmd.exe" execution, attempted to jail the user, and was running under restricted access. That made us wonder, why not apply all hardening techniques on one? It could make it a bit harder for us ;)