Application whitelisting on critical Windows systems: useful or not?
Application whitelisting is the practice of specifying an index of approved software applications that are permitted to be present and active on a computer system.
The main goal to protect critical systems from potentially malicious applications.
How it works?
The general concept behind application whitelisting is quite simple.
Instead of attempting to block malicious files and activity, application whitelisting will only permit known and approved good files, based on files hash.
Essentially, whitelisting flips the antivirus model from a ‘default allow’ to a ‘default deny’ for all executable files (binaries and scripts).
How can be implemented?
A lot of vendors provides whitelisting as a component of existing solutions or frameworks, trying to differentiate themselves primarily in their management approaches, but also their ability to compensate for weaknesses in the whitelisting model.
Here a brief look at the major commercial solutions for application whitelisting.
AppLocker replaces Software Restriction Policies (SRP) which was part of Windows XP and Vista and allows to control which apps and files users can run on system, including executable files, scripts, Windows Installer files, dynamic-link libraries (DLLs), packaged apps, and packaged app installers.
A really base solution, included with enterprise-level editions of Windows.
Ivanti Application Control combines dynamic whitelisting and privilege management to prevent unauthorized code execution. Is part of a more complex solution that uncludes also antivirus, device control, vulnerability, patch and configuration management.
McAfee acquired whitelisting vendor SolidCore in 2009, in order to create a strong candidate for existing McAfee antivirus customers and those who utilize their EPO management solution.
Faronics is probably best known for their Deep Freeze,a solution which returns a computer to a known good state after each and every reboot.
Faronics solution also offers antivirus, power management and configuration management.
How can be bypassed?
Simple attacks such as DLL proxy, that manipulates the default Windows loading
mechanism to load a malicious DLL with an identical name to the original from a predefined list of paths usually are useless, because application whitelisting will examine the PE file properties to confirm its legitimacy before loading it using file name, path, and hash.
However, other kinds of attacks are however available, for example:
Using rundll32.exe or regsvr32.exe
Rundll32.exe is used by Windows to load DLLs and can be exploited by loading malicious code.
Regsvr32.exe is used to register OLE controls in the Windows registry andt herefore can be used to register a malicious component that will be loaded by a legitimate program.
Both this application are required for Windows functions, so the whitelisting is not applicable.
Powershell is installed on all newer systems.
Usually this application is used for a lot of administration tasks and is whitelisted per default.
Obviously every application control checks if an attacker tries to start a Powershell script (a file with .ps1 extension) and only allows the execution of whitelisted scripts.
However, it’s still possible to abuse powershell.exe by specifying the complete script inside the arguments.
For example, it’s possible to start calc.exe by using the following command:
powershell.exe –nop –windows hidden –noni –command calc.exe
Further, using an encodedCommand argument a more complex scripts can be started.
The following powershell script encodes a command:
$cmd = 'calc.exe' $bytes = [System.Text.Encoding]::Unicode.GetBytes($cmd) [Convert]::ToBase64String($bytes)
The base64 encoded output can be used to invoke calc.exe from powershell.
The following command is an example of an encoded command which starts calc.exe:
powershell.exe -enc YwBhAGwAYwAuAGUAeABlAA==
Finally, it’s also possible to access and invoke any function exposed by a Windows library like CreateThread() or VirtualAlloc(): combining both functions it’s possible to allocate additional memory to store shellcode in the current process and start a new thread to execute it.
Using Java Applets
One of the most common attack vectors nowadays is to embed a malicious Java applet on a website and trick the victim to start it.
Not all application whitelist solutions allows to prevent the execution of not whitelisted Java applets.
Therefore it’s possible to achieve code execution by abusing Java applets if the Java runtime is installed and whitelisted on the target system.
Using Office Macros
Old but gold!
If the victim enables macros in a malicious word or excel file VBA code starts to execute.
Typically the code just drops a binary to the file system and then starts it, and this code could be blocked by the whitlisting solution.
However, to overcome this, one of the whitelisted applications (e.g. powershell), can be started instead.
A lot of solution laks a correct check of HTML applications (HTA files), delivered to the victim for example via E-Mail or USB stick, with a simple social engineering attack.
Using the run method from the Wscript.Shell object it’s possible to start other whitelisted applications on the system which is required in a later stage of the attack.
More information here: Application Whitelisting Bypass: mshta.exe – Conscious Hacker
Below an interesting speech by René Freingruber:
The malware problem is significant and shows no signs of lessoning.
While new signatures and heuristic techniques are developed each day, clearly current protection technologies are struggling to keep up.
Application whitelisting is not perfect. Managing the whitelist can prove difficult in large, open environments.
The challenges in dealing with memory based attacks such as buffer overflows are clear.
However, regardless of these challenges, application whitelisting can provide significant benefit to any organization.
First, whitelisting provides a dramatic improvement in the level of visibility into files being introduced into an environment.
This can be extremely helpful for incident responders.
Second, organizations can use the technology to significantly reduce the risk of today’s malware.
This helps reduce the likelihood of system compromise and reduces cost of staff to deal with malware related issues.
While no security solution can be described as a panacea, application whitelisting certainly is not propaganda.
In fact, application whitelisting is the most effective way to significantly reduce the impact of malware in today’s environments.
References and further reading
- Ivanti Application Control
- McAfee Application Control
- Microsoft AppLocker
- Faronics Anti-Executable
- Dynamic-Link Library Search Order | Microsoft Docs
- Application Whitelisting Bypass: mshta.exe – Conscious Hacker
- Kernel-Based Endpoint Detection vs. Whitelisting – Cyberbit
- McAfee Application Control – The dinosaurs want their vuln back | SEC Consult
- Application Whitelisting: Panacea or Propaganda