ATM Security: Application Control Application Difficulties

Image: Pexels

In the past few years, in the field of information security, a new class of operating system protection tools has emerged - application control. The need for highly specialized tools exists in situations where malicious software cannot be detected using behavioral and signature analysis, or when the system does not have access to the Internet to download antivirus updates.
')
Theoretically, application control tools can be replaced with OS local security policies, but the software of this class helps to manage black and white list policies more flexibly. Today we will talk about how to use such means of protection on a real example of ATM security.

What exactly do application control tools do?

There are a number of ways to check whether an application complies with a given white list - from checking the path to the executable file or its hash to analyzing the digital signature and extension. Application control tools are most often used for additional protection of client computers - a ban on launching non-whitelist software - or securing isolated systems that do not imply constant operator intervention - for example, ATMs.

In the first case, you need to protect the user, including from phishing attacks, when an attacker tries to convince him to launch a malicious application — for example, using a letter with a special attachment. In this case, the protection system simply prohibits the launch of the downloaded attachment, not on the basis of behavioral analysis or signatures (which hackers increasingly successfully bypass), but simply because such applications are prohibited in principle to the user.

In the second scenario, it is assumed that the attacker somehow has already penetrated the system, that is, has physical or remote access to the system — to the cmd.exe command console or explorer. Here it is necessary to restrict the ability to run third-party software, which can be used to elevate privileges, or perform malicious actions (mimikatz, nmap, etc.).

What can go wrong here: 3 control problems

Since application control is a young direction, almost all the tools related to it have some kind of “childhood diseases”. As a result, such products almost never work out of the box, they need to be customized, tested and adapted already in the course of use. This is due, among other things, to the complexities of solving the very problem of monitoring launched applications — we will list the main ones.

The white list is much more difficult to implement.

If the “black list” of extensions that should be blocked is more or less universal and easy to configure, then the “white list” of what is allowed to run is redundant by default - it often includes all applications from the OS at the time of configuration.

And this means that it is possible to execute an arbitrary code in an ATM in various ways, without violating the conditions of checks. For example, using quite legitimate tools, like PowerShell (almost always ATMs are running Windows), as well as causing external code utilities. Over the past few years, many methods have been described to bypass the application control using Microsoft Windows tools (for example, “rundll32”, “regsvr32”), a simple blocking of which disrupts the normal operation of the OS.

This means that the application control system should monitor not only the fact of launching these utilities, but the whole set of conditions — which processes use utilities (system or user), which rights are used, how the required library is called, etc.

In a relatively short time, Positive Technologies experts were able to expand the list of OS utilities that allow executing third-party code by other means not mentioned before: “debug.exe”, “ntsd.exe”, “rasautou.exe”, etc.

Another direction of attack is interpreters of programming languages ​​(Java, .NET, PHP). In most cases, the conditions for their launch on an ATM should be as detailed as possible. In fact, this is not the case, which makes it possible to run arbitrary code. An example of the possible consequences is the recently described .NET attack to bypass the Microsoft Windows Applocker security features .

In our practice, there were also solutions that did not protect the extension control by simply renaming a 32-bit file extension to arbitrary or using 16-bit applications that are not checked because they do not contain a PE header, which is usually a condition for checking the file. before its launch.

As you can see, there are so many configuration parameters that need to be properly configured. It also makes sense to block applications by headers, not extensions, to prohibit not only 32-bit, but also 16-bit applications.

Vulnerabilities can also be found in protection tools.

Like any other software, protection tools may contain vulnerabilities. Security errors in antiviruses and firewalls are regularly found by researchers - application control tools are in the same row.

In their case, there are vulnerabilities that open up the possibility of carrying out network attacks - for example, disabling protection mechanisms by simply repeating an intercepted command or a buffer overflow error. Another type of problem is logical errors in the application control system, their operation can bypass the protection mechanisms .

Not all attacks are equally easy to repel.

Using application control tools has its own specifics and depending on the scope of application - for example, in the case of ATMs, it is important to protect against attacks of a different profile than when protecting the infrastructure of a nuclear power plant. In the first case, in order to steal money, the attacker does not have to launch the malware that was brought with him.

As our research shows, sometimes it is enough to simply write or read a specific file. And to protect against such “attacks”, application control products are not designed in principle, although they can be configured to reduce the likelihood of a hacker's success. For example, when running an activity analysis that is responsible for the interaction of the OS with the MSXFS ATM ATM periphery, it can interact with the same PowerShell, as well as Regedit and Notepad - a notebook is enough to read or write configuration files, so that such activity of illegitimate users should be is prohibited.

Conclusion: There is no silver bullet.

Application Control class tools can reduce the likelihood of a successful attack and make life difficult for attackers, but in essence they are not very suitable for protecting systems such as ATMs. There are a number of limitations that make these tools not the most effective way to protect - from the need for very fine-tuning to the likelihood of having your own vulnerabilities that allow you to bypass even well-tuned application filtering rules.

In order to protect their infrastructure, banks should not just implement the tools under the influence of current trends, but implement a comprehensive security strategy - in accordance with it, it will be possible to make a choice of a specific remedy. Here are the steps you need to take to solve this problem:

1. Create a threat model and a violator model with the assistance of independent experts.
2. Develop policies in conjunction with information security auditors and the vendor of application control solutions. Adhere to the principle of least privilege (to prohibit everything that should not be explicitly allowed).
3. Think about the introduction of other tools, the presence of which dramatically reduces the hacker's attack space: tools for controlling connected devices (device control), protection mechanisms against blackbox-attacks with a cryptographic signature on the side of the processing center.

By Timur Yunusov, Positive Technologies