Death to antivirus
It’s fun to read other people’s account of something you have gone through yourself. Security legend Marcus Ramun has posted some new articles on his rarely-updated blog, one of which is "Execution control: death to antivirus" where he describes his search for decent execution control software for Windows.
I’ve mentioned application whitelisting before. A couple years ago I researched this for the Canadian military… they were looking for what they initially called a "super anti-virus" to protect their unclassified networks. Management understood that traditional anti-virus is essentially useless since it works as a blacklist, allowing all code to execute unless it happens to appears on the vendor supplied blacklist. AV also has a hard time identifying malware that’s been altered… switch around a few bytes or compress the EXE with a packer and often it will sail right by many AV products. The military wanted something that could protect Windows desktops against unknown malware and targeted attacks, even when the malware was obfuscated.
When the platform being protected is Windows and it has access to the Internet, this is essentially an impossible task. Obviously almost all web sites use some combination of Javascript, Java applets, Flash or other "mobile code". So much for being able to control what code gets executed on the workstation. Worse, fundamental design flaws of Windows allow fun attacks like DLL injection and "shatter" permit any executable from controlling and compromising any other executable running on the desktop.
At first we looked at simple code execution controls. Third party products have been around for years that let you to create a whitelist of EXEs allowed to run. Most use a cryptographic hash to identify the files and detect changes, such as when a virus is attached to the executable. Nowadays Windows XP and higher have a simple built-in EXE whitelist called software restriction policies.
The problem with execution controls is they only make a simple "go/no-go" decision. Once a whitelisted app is running it still inherits all the permissions of the users and so can do anything the user themselves can do. When the app talks to untrusted networks and executes arbitrary code, such as a web browser or email client, that’s just not good enough.
About the time I was explaining and demonstrating this to senior management, a new category of software called host intrusion prevention was emerging (also mentioned previously). These products claimed not only provide the "go/no-go" execution control, but also control what each application could do once running. If the email client was not supposed to write to the registry, HIP products claimed to be able to stop those actions. Essentially, HIP extends the Windows reference monitor so that code doesn’t necessarily gain all the rights of the user that launched them.
So we tested the few intrusion prevention products available at the time, beating on them with various malware and custom-written attacks, including some internal stuff that was way ahead of malware in the wild at the time. The most HIP popular product turned out to be complete snake oil (for one, just renaming an EXE allowed the user to bypass all restrictions). Others weren’t as easy to circumvent but relied on vendor supplied databases of permitted actions.
Now, predefined rules save a lot of work for admin staff. Few people have the knowledge or patience to sit down and discover rules that allow a behemoth like MS Word to function yet still prevent a macro virus from pillaging your network. Vendor-supplied rules eliminate that drudgery for most off-the-shelf software.
The problem was that most HIP products that provided their own rules either didn’t allow you to define define your own at all, or only had a limited ability. For an organization that uses a lot of weird custom code and legacy apps that wasn’t going to work. Another concern was exceptions… what if they had to allow an action that the vendor blocked? The only solution from the vendors was that we had to disable all restrictions on those apps. Again, not good enough.
The other concern was what Marcus discovered with PrevX… vendor databases continue the antivirus-like dependence on continual update subscriptions from the vendor.
Yet another shortcoming in products was that most didn’t protect all the critical areas. For example, desktop firewalls like Sygate had pretty good execution control but only controlled network access. Filesystem, registry, interprocess communications were left completely unrestricted.
In the end we tested around 12 different products. Being government, the process took a ridiculously long time but that was fortunate because the host intrusion market was evolving… second versions of products were a lot more capable that the first.
Eventually we found a product that met all the criteria and survived lab testing well enough. It was quite an ordeal, and few other organizations would go to so much trouble. However, as the use of the custom-written targeted attacks grows I think more commercial organizations will start accepting that hardening the endpoint requires tools like host intrusion prevention, not just antivirus.
Related posts: