Over the past few years, a new class of operating system protection tools—application control—has emerged in the field of information security. There is a need for highly specialized tools in situations where malware cannot be detected using behavioral and signature analysis, or when the system does not have access to the Internet to download an antivirus update.
Theoretically, application control tools can be replaced with local OS security policies, but software of this class helps to manage black and white list policies more flexibly. Today we will talk about how to apply such protection measures using a real example of ensuring ATM security.
What exactly application control tools do
There are a number of ways to check whether an application matches 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 - prohibiting the launch of software not from the white list - or to ensure the security of isolated systems that do not require 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 trick him into launching a malicious application - for example, using an email with a special attachment. In this case, the protection system simply prohibits the launch of the downloaded attachment, not based on behavioral analysis or signatures (which hackers are increasingly successfully bypassing), but simply because such applications are prohibited to the user in principle.
In the second scenario, it is assumed that the attacker has somehow already penetrated the system, that is, has physical or remote access to the system - to the cmd.exe command console or Explorer. Here you need to limit the possibility of running third-party software that can be used to escalate privileges or perform malicious actions (mimikatz, nmap, etc.).
What Can Go Wrong Here: 3 Control Issues
Since application control is a young area, almost all tools related to it have one or another “childhood diseases”. As a result, such products almost never work out of the box; they need to be configured, tested and adapted as they are used. This is explained, among other things, by the difficulties of solving the very problem of monitoring launched applications - we will list the main ones.Whitelisting 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.This means that you can execute arbitrary code at an ATM in different ways without violating the check conditions. For example, using completely legitimate tools, such as PowerShell (ATMs almost always run Windows), as well as utilities that call external code. Over the past few years, many methods have been described to bypass application control using Microsoft Windows tools (for example, “rundll32”, “regsvr32”), simply blocking which disrupts the normal operation of the OS.
This means that the application control system should monitor not so much the fact that these utilities are launched, but a whole set of conditions - which processes use the utilities (system or user), what 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 the execution of third-party code by other means not mentioned earlier: “debug.exe”, “ntsd.exe”, “rasautou.exe”, etc.
Another direction of attack is programming language interpreters (Java, .NET, PHP). In most cases, the conditions for launching them on an ATM should be as detailed as possible. In reality, this is not the case, which opens up the possibility of running arbitrary code. An example of the possible consequences is the recently described attack on .NET to bypass Microsoft Windows Applocker protections .
In our practice, we have also encountered solutions that do not protect in any way from simply bypassing extension control by renaming a 32-bit file extension to an arbitrary one or using 16-bit applications that are not checked in any way because they do not contain a PE header, which is usually a condition for checking a file before launching it.
As you can see, there are a lot of configuration options that need to be configured correctly. It also makes sense to block applications by headers, not extensions, and to prohibit not only 32-bit, but also 16-bit applications.
Vulnerabilities may also exist in security tools.
Like any other software, security tools may contain vulnerabilities. Researchers regularly find security errors in antiviruses and firewalls—application control tools are in the same category.In their case, there are vulnerabilities that open up the possibility of network attacks - for example, disabling security mechanisms by simply repeating an intercepted command or a buffer overflow error. Another type of problem is logical errors in the operation of the application control system; their operation can allow you to bypass security mechanisms .
Not all attacks are equally easy to parry
The use of application control tools has its own specifics 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 he brought with him.As our research shows, sometimes simply writing or reading a particular file is enough. And application control products are not designed in principle to protect against such “attacks,” although they can be configured to reduce the likelihood of an attacker’s success. For example, when starting an analysis of the activity responsible for the interaction of the OS with the ATM peripherals of the MSXFS library, it can interact with the same PowerShell, as well as Regedit and Notepad - notepad is quite enough to read or write configuration files, so such activity of illegitimate users should be prohibited.
Conclusion: There is no silver bullet
Application Control tools can reduce the likelihood of a successful attack and make life more difficult for attackers, but by their nature they are not particularly suitable for protecting systems such as ATMs. There are a number of limitations that make these tools not the most effective method of protection - from the need for very fine tuning to the likelihood of having their own vulnerabilities that allow you to bypass even well-configured application filtering rules.To protect their infrastructure, banks should not just implement tools based on current trends, but implement a comprehensive security strategy - in accordance with it, it will be possible to select a specific security measure. Here are the steps you need to take to solve this problem:
- Create a threat model and an intruder model with the involvement of independent experts.
- Develop policies together with information security auditors and application control solution vendors. Adhere to the principle of least privilege (deny everything that should not be explicitly allowed).
- Consider introducing other tools, the presence of which sharply reduces the attack surface for a hacker: device control tools, mechanisms for protecting against blackbox attacks with a cryptographic signature on the side of the processing center.
Author: Timur Yunusov, Positive Technologies
