Pentesting terminals

However, all this relates to classical penetration testing in corporate networks. At the same time, pentesting of the technological network and testing of payment terminals, ATMs, etc. are usually not considered. And if the former is more or less clear, pentesting real working equipment of the ACS TP can easily lead to irreparable consequences and it is better not to develop this topic much, then pentesting various terminals should be covered in more detail. In this article, we will talk about how to check the security of ATMs, payment terminals, and other similar devices. But first, a routine disclaimer.

Hardware, just hardware

First, let's decide who we are actually going to pentest. First of all, these are, of course, ATMs and payment terminals - everything that is related to money. These devices are a tidbit for attackers and, in addition, regulatory requirements of regulators, in particular the Central Bank, require security checks of payment systems.

However, this is not the limit of our work. Also, we can highlight devices that seem to deal with money as well, but their owners do not always comply with security requirements. These are various payment terminals in parking lots, automatic car washes, and similar devices related to automatic payment. Such devices often accept payment only in cash, thereby complicating the lives of users accustomed to cashless payments. But for us, such devices are of interest primarily from a security point of view, namely from the point of view that security measures may be weakened on them, as they are not required to comply with regulatory requirements. Or their owners think they are not required to:)

And the third type of devices are those that are not directly related to money. Various information systems and terminals, electronic queues, etc. These devices do not deal with money, but this does not mean that they are not of interest to attackers. In the event that arbitrary code can be run on the device, especially with privileged rights, it can become a foothold for an attack if it can be used to access the organization's internal network. As a rule, these devices must be connected to the network, for example, the same electronic queue terminal must notify the organization's employees which number is assigned to whom, and these values must be displayed on a large screen on the wall and possibly also announced.

Similarly, a shopping mall map terminal may not be autonomous, but load information about the stores displayed on the map from an internal database or may display the map as a web page in full-screen mode, and the page itself is located on an internal web server.

Thus, it is necessary to protect not only devices that directly work with money, but also other terminal systems, as they may be of interest to attackers.

Types of device pentesting

In fact, it cannot be said that the general principles of device penetration testing differ significantly from software tests. There are also "white" and "black" box tests.

Black box testing assumes that we test the device, whether it is an ATM, a payment terminal, or other equipment, in its natural "habitat" (in a passage, the lobby of a bank branch, etc.), that is, with connected communications. At the same time, the level of impact is discussed when concluding a pentest contract and can vary widely.

For example, a light option involves impacting the device without causing any physical damage or attempting to disassemble it. The maximum a pentester can do is turn off the power or network. It is assumed that the equipment is under constant supervision and the attackers will not have time to physically open the device before the rapid response team arrives.

A tougher option is usually used for ATMs and devices that work directly with cash, allowing for physical damage and noise. Here, the time and means required to open the device are of great importance.

White box testing involves providing the device for legal disassembly, usually in the contractor's laboratory. This option allows for the analysis of the operating system image and applications used in the device, in laboratory conditions, which will also increase the objectivity of the check.

What's under the hood

The most common device models use something not too fresh as operating systems, like Windows XP. This is due to the fact that ATMs and other equipment contain weak hardware and a more demanding OS will be difficult for them to handle. On the other hand, the same ATMs do not require special power, and Windows XP copes quite well with the tasks assigned to the device.

The number of interfaces available to the user on devices is always maximally limited. So, if we are talking about ATMs, here we have devices for dispensing/loading money, a keyboard, a contact/contactless card reader, and a headphone jack. If the device does not involve working with cash, then the number of interfaces is even smaller.

In black-box penetration testing, the available interfaces are practically all we have to influence the behavior of the device, accordingly, the more interfaces we have available, the more potential attack vectors we can consider.

Possible attack vectors

Usually, in penetration testing, we try to find vulnerabilities in order to exploit them later. In the case of terminals, to try to find and exploit a vulnerability, you first need to exit the full-screen mode in which the interface is loaded on the screen. If you manage to exit to the OS, then you need to call the on-screen keyboard (for example, through the Control Panel) and the device will turn into a regular computer.

On old devices, you could try pressing the extreme pixels on the screen to exit to the OS interface. Now this can only work on very old devices, for example, on parking payment terminals. It is unlikely that this will work on an ATM.

Then, in order to try to access the window interface, we need to somehow cause a failure on the device and see how it will handle the error situation.

You can start by turning off the power and rebooting. Ideally, ATMs should have a UPS, but in practice, I have encountered situations where the device also turned off when the power was turned off. Perhaps after the reboot, it will be possible to get into the OS window.

Another direction is to disconnect the network connection. If a wired connection is used, then as a rule, you can pull the cable out of the socket. A wireless connection can be jammed, for example, by covering the antenna with a metal bucket.

One way or another, the device, having lost connection, will issue an error message and may possibly fall into the OS interface. This is a more efficient way than turning off the power because there is no reboot here and everything depends on how the connection loss error is handled.

An error situation can also be caused when working with interfaces. For example, a faulty card can be placed in the card reader, or the card can be slightly held when the reader is taking it, or it can be prevented from issuing the card. As a result, a reader error may occur, and it is also important how the device will handle it.

In general, the idea of error handling is clear. If there is physical access to the network cable, man-in-the-middle attacks can be considered separately, but here all traffic will be encrypted (most likely), although it is certainly worth trying.

How to protect yourself

When ensuring the security of ATMs, terminals, and other devices, the main means is physical security. The presence of cameras, alarms, and other organizational measures that do not allow attackers to quickly gain access to the contents of the device or simply take it away (such cases have happened with ATMs) is mandatory. All communications going to the device must also be protected, and all its interfaces must be closed. The presence of an accessible USB port will significantly simplify the attacker's life.

As for error handling, the application running on the device should be written in such a way that when exceptions occur, it handles them independently without passing control to the OS. That is, in the event of a connection loss, the ATM should switch to temporarily unavailable mode, rather than falling into the OS with a connection error.

Conclusion

Various terminals have become quite widespread, and it is important that these devices are safe to operate. In this article, we have considered the main approaches to penetration testing for various devices and protection methods.