Use of allowlists is not enough

Security should be multilayered, and use of allowlists is appropriate as one of the security levels.

Almost any malware poses its largest threat within the first few hours, or in some cases within the first few days, of being unleashed. The samples soon find their way into the “traps” of antivirus analysts, and then database updates spread all over the world (it happens almost instantly because of cloud technologies), and that fresh piece of malware begins encountering resistance on systems secured by antimalware solutions.

However, even that short time may suffice for hackers to achieve their goals. For example, in many cases, new and unique malware strains are designed for sophisticated attacks. Using allowlists is a popular choice for an effective security measure against such tactics is to use allowlists.

Solutions that employ allowlists block the launch of anything that is not in the list — which may be set up by developers or prepared by administrators for a particular system. In theory, this mode provides absolute protection: Even if attackers manage to deliver malicious code, the security solution should block its execution.

But in practice, things are never that simple. Cybercriminals use many tactics to execute malicious code without having to launch executable files. As an experiment, Kaspersky Lab checked which of a group of applications included in allowlists with trusted certificates tried to refer to known malicious servers. Over six months of observation, our systems registered more than 30,000 attempts by various legitimate programs, such as application servers, databases, ERP systems, design software, and so on, to refer to known malware distributors in 94 countries around the world.

Of course, not all of those cases led to infections, and our statistics included information from only those systems with comprehensive protection. But how did all of those trusted applications fall so far? We decided to examine these cases closely.

It turned out that in some incidents, attackers did not even have to resort to complex hacking methods. These examples stemmed from applications using browser components. As a rule, a user chooses and downloads a browser, uses it, and even regularly updates it. The user may be oblivious to the fact that he or she has another browser in the system, integrated as an additional component in some other software. Therefore, other programs, ERP systems for example, which require access to websites via HTTP, may use the integrated browser, which has not been updated in a long time (if ever). Eventually, the outdated browser may face an exploit pack — for example, the notorious Angler — released after the browser’s last update. That’s one way to get a trusted program to download malicious code.

Another popular trick is DLL hijacking. Specific applications of this method vary, but the essence is quite simple: Numerous vulnerabilities in various software applications give attackers an opportunity to substitute an unauthorized DLL file for the legitimate library an application is trying to download. Thereby a fully trusted application gets new, untrustworthy functions.

In many cases, a server gets infected by its own administrator, using an unlicensed or free version of legitimate application downloaded from an untrusted source. As we explained above, even a developer’s digital signature does not guarantee the absence of <em>any</em> malicious code in a downloaded executable file. And the malware may be not within the executable but instead reside in DLLs that go with it. In that case, the malware infiltrates the memory area of a legitimate application and executes with its privileges.

None of that is to say that allowlists are useless. On the contrary, they prevent a lot of trouble. Moreover, the implementation of the technology varies in different products. For example, Kaspersky Lab’s solutions use Default Deny, a mode that not only prohibits any executable code that is not in the allowlist, but also monitors scripts, firmware, and libraries.

Nevertheless, we believe use of allowlists is never enough. Security should be multilayered, and use of allowlists is appropriate as one of the security levels. Start with an allowlist and then ensure the applications are downloaded from trusted sources only; control the network behavior of all applications; and, of course, enable anti-exploit technology. At that point, you might consider your system well protected from malware.