Whitelisting: an important component, but not enough

©James Barber via 123RF

However, whitelisting does not prevent an attack, it just makes it harder for the attacker, and organisations that may be targeted by more advanced actors need to consider whitelisting merely as a component of a mature set of security controls that provide much stronger holistic protection in combination than whitelisting would alone. A number of actors have been observed using strategies that bypass the whitelisting in place and as it grows in popularity this will only become more common.

Many attacks exploit web browsers or common document editing software, such as Microsoft Office or Adobe Reader, in order to gain code execution inside the process that was exploited. At this point, more common attacks will use the code execution achieved to download full-feature malware as a binary executable to run on the system. This would be prevented by whitelisting as the downloaded malware would not be allowed to run.

Advanced attackers

However, more advanced attackers will not download a binary directly and may remain fully memory-resident within the memory space of the exploited process. To avoid losing control when the targeted software is exited, the memory-resident malware may migrate to the memory space of another approved process that is expected to remain running for as long as the system is powered on, such as explorer.exe.

Alternatively, a new approved process may be launched and used specifically to host the memory-resident malware. This technique is known as 'process hollowing' and involves launching an approved process permitted by whitelisting and replacing the executable code in memory with malicious code. Whitelists are only strongly enforceable against users who do not have local administrative access to their systems because administrative access can be used to disable the protection, add exceptions or otherwise render it ineffective. An attacker who exploits an administrative user could make configuration changes such that any further malware they wanted to use would be permitted.

Technique not limited

However, this technique is not limited to use against administrative users. Privilege escalation attacks could be used as a second stage attack in order to get around whitelisting. For example, our security consultants used a kernel exploit as part of a Chrome browser exploit in Pwn2Own to both gain remote code execution and escalate privileges to break out of the browser sandbox and gain administrative level access. At this point, whitelisting protection could be disabled.

Whitelists are a good control but not all whitelists are created equal. Each organisation will set up a whitelist that suits its working habits and in MWR's experience, there are often holes in the whitelisting that an attacker can exploit to gain persistence. Common flaws include:

• Validating only the program name - this can easily be circumvented by renaming.

• No validation of DLL loads - common tools such as rundll32.exe can be used to load executable content as DLLs instead.

• Writeable paths - path rules are commonly used to allow execution and if these are writeable then the whitelist can be bypassed by writing malicious executable content to the allowed paths.

By identifying flaws such as these, the attacker can compromise a system with whitelisting in place.

Many whitelisting tools monitor native binary loads but do not appropriately account for other ways of executing arbitrary code. These are common scripting and bytecode engines that are either default or commonly installed by enterprises and can be used to achieve arbitrary code execution. Common examples include:

• Java
• PowerShell
• Office Macros
• VBScript
• Batch files
• InstallUtil bypass

Our security consultants have successfully exploited environments with whitelisting in place using some of these technologies. Many whitelisting solutions cannot directly control these technologies other than to fully disable the entire scripting engine, which is often not viable when the technology is required for business applications.

Alternative systems

A simple bypass assumes not all hosts in an environment will be using whitelisting. Alternative operating systems such as servers, Linux desktops and OSX hosts may not be whitelisted so aggressively. By targeting these hosts, attackers can gain the foothold on the network they need.

Similarly, not all user profiles are subjected to whitelisting restrictions. Typically administrators and sometimes developers are able to run arbitrary executable code and so whitelisting can often be avoided by targeting these users. Organisations should ensure that whitelisting is robustly and aggressively configured so that there are not obvious gaps that an attacker can exploit to plant malicious code on a system. This includes ensuring whitelisting is present on all hosts, regardless of operating system, that can be reached by an attacker.

This should include tight control of scripting and bytecode engines such that they do not represent a generic way to bypass whitelisting controls in place. In many cases, most users will not require the use of technologies like PowerShell and other configuration controls exist for controlling execution of VBScript and Office macros. For technologies that may be more problematic to control directly, such as Java, centralised logging of process execution can be used to help detect malicious use of Java specifically.

Live memory analysis

For example, detection of the use of process hollowing or thread injection as a technique to bypass whitelisting will require detailed process execution logging and live memory analysis to detect properly. Dedicated endpoint threat detection and response software will generally be required to achieve this.

Application whitelisting is a great preventative security control and is arguably the most effective first line of defence against initial endpoint compromise. However, no security control can protect against every attack and so it does not replace the need for good attack detection for when preventative controls fail. A large enterprise without strong whitelisting controls is likely to have endpoints compromised by generic malware and adware that anti-virus misses regularly. An advanced attack is likely to slip under the radar easily in this situation.

Whitelisting can help reduce the noise of common malware infections. Additionally, due to the low noise from common malware infections, there should be much more resource available for investigating advanced attacks.