The bottom line is this: adding additional layers to your existing “Layers on Layers” (LOL) of end point protection – just like any Defense in Depth (DID) strategy – is a game of diminishing returns: The security chain is only as strong as its weakest link, and if that link happens to be a vulnerable Windows kernel, no matter how many agents or defenses you deploy to protect it, in the hands of a sophisticated attacker, you’re in trouble.

Let’s step back a moment. We all understand that the endpoint is vulnerable. What’s telling about our approach is that we seldom stop to think through a threat model. And if we did, we’d find that the limitation of every threat detection/prevention tool that we use today is the same – the Windows kernel – and that therefore a simple attack that targets the kernel will deliver great payback. Before I describe our latest research, here is a quick summary of the so-called “next gen” endpoint security tools that vendors recommend to bolster the traditional defense of signature-based AV:

Sandboxes have become standard components of the most vulnerable apps (browsers, players, renderers). Some vendors recommend layering sandboxed apps in another sandbox.

Exploit mitigation technologies are implemented in Microsoft EMET – a powerful free tool set that can block known memory corruption attacks

Hardware-assisted security, such as Intel OS Guard (SMEP) and hypervisor based root- or bootkit detection tools such as McAfee DeepSafe attempt to protect vulnerable software using privileged CPU instructions or a hypervisor for introspection.

You’d be forgiven for thinking that if you layer all of these tools on a single endpoint; you’d be in great shape. Of course, the user experience would be so terrible that the end user would probably abandon the device, but end point security would be mission complete.

Wrong. Layers on Layers, just like other forms of Defense in Depth, cannot save you from a sticky ending.

An Attack in the Wild…

While many in the security industry were aware of last year’s discovery of the TDL4 rootkit that was rumored to be using kernel exploit code; few paid it any serious attention – a serious mistake. By simply ‘tweaking’ the exploit, our team found that they could bypass all of the typical security software you’d expect to encounter on any corporate user machine – at the same time. The full details of the approach are in Rafal Wojtczuk’s talk and the labs blog.

In his research, Wojtczuk used the public exploit for the so-called “EPATHOBJ” Windows kernel vulnerability it to bypass application sandboxes, AV, HIPS, rootkit detectors, Microsoft EMET and SMEP – even when all of these solutions are layered one upon the other. Modifications to the exploit allowed us to bypass all of these technologies.

This highlights the fact that “defense in depth” – based on simultaneous deployment of multiple solutions that share the same weakness – does not advance security posture. In this case the entire chain of protective measures shares a common vulnerability – the Windows kernel, which unfortunately is the component with the most rapidly growing set of vulnerabilities – over 80+ CVEs in the last year alone. As a result, the Bromium Labs team makes a compelling argument for defensive tools that are immune to kernel mode exploits.

CVE count by year for the Windows Kernel

What to Do?

Using hardware isolation – courtesy of the integrated hardware virtualization features on every CPU – to isolate each untrusted task that executes on the end point, solves the problem of the weakest link: the security posture of the end point is no longer dependent on the Windows Kernel, but on the hardware isolation capabilities of the CPU. Micro-virtualization can take advantage of this to deliver a seamless end user experience while protecting against kernel mode attacks. Micro-virtualization depends only on a small hypervisor – a Microvisor- whose code base can be specifically hardened. In Bromium’s use of micro-virtualization, the Microvisor is based on the Xen hypervisor, which is widely used in cloud computing and other environments..

A few recommendations:

Do not rely solely on AV, or other detection technologies that rely on signatures

Evaluate the entire stack – a layered defense is not enough if layers share the same weak link

Attackers will always try to exploit the Achilles heel of any system. In this case it is the OS kernel. If you use a layered architecture, make sure it covers all aspects of the system architecture

Any security technology that isolates threats needs to be able to reliably protect the integrity of the OS kernel. Application sandboxes cannot do this.