In the last few years in the field of information security, a new class of protection tools was formed. It is known as Application Control (AP). The need for highly specialized tools appears in situations where malicious software cannot be detected through behavioral and signature analysis, or when the system does not have access to the Internet, for example, to download an antivirus update.
Theoretically, application control tools can be replaced with local OS security policies, but AP helps to manage the black and whitelists more flexibly. This article is going to explain how to use Application Control methods while securing ATMs.
What exactly are the Application Control tools?
There are many ways to verify if an application belongs to a given whitelist. You can check the path to the executable file or its hash or analyze the digital signature and extension.
Application Control is most often used for additional protection of client computers like forbidding the launch of software which is not in the whitelist or ensuring the security of isolated systems that do not imply constant human intervention, for example, ATMs.
In the first case, you need to protect the user from various attacks, for example from very popular phishing attacks, when an attacker tries to convince the user to run a malicious application using an email with a malicious attachment. In this case, the security system blocks the launch of downloaded attachments not based on behavioral analysis or signatures detection (which hackers successfully bypass these days), but simply because such applications are forbidden to run by the user by default.
In the second scenario, it is assumed that the attacker has somehow already penetrated the system. He has physical or remote access to the system – to the cmd.exe or to the explorer. Here you need to limit his ability to run third-party software, which can be used to increase privileges or perform malicious actions (mimikatz, nmap, etc.).
What can go wrong here: 3 problems
Because Application Control is relatively young security practice, almost all the instruments 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 set up, tested and adapted on the fly. This is explained, among other things, by the complexity of solving the task of controlling applications that are run. Let’s list the main problems.
1) The whitelist is much more difficult to implement
If the blacklist of extensions that should be blocked is more or less universal and easy to configure, the whitelist of what is allowed to run is by default redundant. It often includes all applications of the OS at the time of creating the configuration.
Moreover, this means that you can execute the third-party code on the ATM in various ways and without violating any rules and conditions. For example, using quite legitimate tools, like PowerShell (almost always ATMs are running Windows), as well as numerous utilities that can execute external code. Over the past few years, many methods of bypassing Application Control using Microsoft Windows tools have been described (for example rundll32 and regsvr32), locking them will disrupt the normal functioning of the OS.
This means that the Application Control system should monitor not so much the fact of the launching of these utilities, but a whole set of conditions like which processes these utilities use (system or user), what privileges are used, how and what libraries are used, etc.
The interpreters of programming languages (Java, PHP, .NET) pose another attack vector. In most cases, the conditions for their launch on the ATM should be as detailed as possible. In fact, this is not so. Moreover, this opens the possibility of running third-party codes. An example of possible consequences is the recently described .NET attack, which bypasses the Microsoft Windows AppLocker protection.
Some solutions do not protect you from bypassing extensions’ controls by renaming the extension of a 32-bit file into any arbitrary file or the use of 16-bit applications that cannot be validated in any way because they do not contain PE headers, which are usually checked before files get launched.
As you can see, many configuration parameters need to be properly configured. It makes sense to block applications by headers, not extensions, to disallow not only 32-bit but also 16-bit applications.
2) Vulnerabilities can also be found in security tools
Like any other software, security tools can contain their own vulnerabilities too. Security researchers regularly find security loopholes in antivirus tools and firewalls. Application Control tools do not differ in this regard.
Here some vulnerabilities open the possibility of conducting network attacks. For example, disabling security mechanisms by repeating the intercepted command or a buffer overflow error. Logical errors in the Application Control system is another type of problems. Exploitation of logical errors allows bypassing protection mechanisms.
3) Not all attacks are equally easy to stop
The use of Application Control tools has its own nuances and depends on the sphere of application. Attacks on ATMs differ from attacks on nuclear power plants. In the first case, to steal money, an attacker does not have to launch the malware brought with him.
To get money from an ATM, sometimes it is enough just to write or read an executable or config file. Application Control methods are not designed to protect against such attacks. However, they can be configured to reduce the probability of a hacker’s success.
For example, In ATMs, OS often interacts with the ATM periphery, MSXFS library. It can interact using PowerShell as well as Regedit and Notepad. So, the Notepad is enough to read or write configuration files. Such actions of illegitimate users should be forbidden.
Conclusion: there is no silver bullet
Application Control tools can reduce the likelihood of a successful attack and make intruders’ life more difficult. However, in fact, they are not very suitable for protecting systems like ATMs.
There is a number of limitations that make these tools not a very effective method of protection. These are the need for scrupulous fine-tuning and own vulnerabilities, which allow attackers to bypass even properly configured application filtering rules.
To protect their infrastructure, banks should follow all security trends and implement a complex security strategy. It will then be possible to select a specific protection tool. Here are some useful steps that can help solve this problem:
- Create a threat model and an offender model, possibly inviting independent experts.
- Develop corresponding policies, again desirably inviting information security auditors and vendors of Application Control solutions.
- Adhere to the principle of least privilege (forbid everything that should not be explicitly permitted).
- Think about using other tools, the presence of which greatly reduces the attack surface for the hacker like device control tools, mechanisms for protecting against black box attacks.