Application whitelisting
The folks at Dark Reading have a fun article about the revival of application whitelisting. As the article points out the concept of enforcing a list of what applications can run on a workstation is nothing new, but some recent products have appeared that are pushing the concept once again.
Controlling what code can run on workstations is essential in any managed environment, but it’s only one small part of the overall defenses needed. A product that just allows specific executables doesn’t help when a permitted application itself has a vulnerability.
Windows group policy provides a weak form of both application blacklisting and whitelisting through Software Restriction Policies, though it’s not difficult to bypass even with a limited user account.
Whitelisting apps consumes a lot of administrator time. Thomas Ptacek is quoted as saying
"Some poor group of souls in IT is charged with deciding which applications every sales person or project manager can run, and has to backstop all the ensuing arguments."
Well, of course. But if you’re not controlling what applications are being run on your organization’s workstations you don’t have a managed environment… you just have a bunch of personal computers. Controlling the desktop is just something you have to commit to if your goals include things like security and license compliance.
Most organizations already have a change request and QA process for desktop applications, though they only enforce it through policy. Some organizations audit compliance periodically by running desktop inventory software, but usually that’s as far as it goes (one security manager I dealt with recently felt auditing wasn’t necessary because "no one has local admin privileges and can’t install anything". A quick visit to portableapps.com quickly disabused him of that notion.)
Whitelist products attempt to enforce policy at a technical level so even applications that don’t need "installation" won’t run.
When you first introduce whitelist application control you suddenly find all the applications users have been running (and in many cases relying on to get their job done) that were never approved for use. Sometimes it’s only a few apps, especially if users don’t have admin rights on their workstations, but initially there is a lot of work in vetting, licensing and approving all those newly discovered apps. Once that’s over with, the whitelisting process just adds a few more steps to the existing application rollout procedure and not much more overhead at all.
Controlling which applications can run is essential if you’re to have any hope of protecting your environment, but vulnerabilities in whitelisted applications themselves are another story. Most application whitelist products are make a very simple "yes/no" decision… a permitted app once running is allowed to do anything.
With some of these products that "anything" also includes launching other executables, which then inherit the trust given to the parent app. A buffer overflow able to execute shell code can then potentially own the system.
About a year ago I tested a bunch of application whitelist products and every one could be bypassed in some trivial way.
The worst offenders simply ran as an app in userspace. End users (and malware) could use Task Manager to close them.
Better products run as a system service, with a separate userspace component (usually in the form of a system tray icon) to display alerts to the user. Still, some of these could be killed by sending them an appropriate Windows terminate message.
Separate from self-protection features where the ways the products identified applications. The really stupid ones just used the filename on disk… so to run an authorized app a user just had to rename it to be the same as any trusted app. Rename "onlinepokerclient.exe" to "iexplore.exe" and it would run.
Slightly better products used the full path, filename and a checksum to identify apps. Nearly impossible to circumvent, provided the whitelist database was not stored on the local hard drive and writable by the user.
Almost every application whitelist product I tested could be terminated or bypassed in some trivial way.
If you’re going to go to all the trouble of installing an application whitelist product you might as well go all the way and install desktop host intrusion prevention (HIP). The better HIP products out there, like Okena Cisco Security Agent provide application whitelisting but can also control what specific system resources they can access (files, network, inter-process communications, etc). Buffer overflow detection, DLL injection control, and control over what sub-processes are allowed to do can all be specified.
CSA and similar HIP products can be a lot of work to deploy but offer far better endpoint protection than simple application whitelist products.
Related posts:
- Death to antivirus
- The most important Windows security tool
- Windows .NET rootkits are easy
- Free host intrusion prevention for Windows
Tags: endpoint security, intrusion prevention, Malware, Windows security