The Final Sandbox #fail? [feedly]

The Final Sandbox #fail?
http://blogs.bromium.com/2013/07/27/the-final-sandbox-fail

At Black Hat USA 2013 the Bromium Labs team will demonstrate a second fundamental design flaw present in all Windows sandboxes (sometimes called "software virtual containers").

The flaw allows malware to escape user-space containment and compromise an endpoint that is equipped with a full suite of traditional endpoint protection software.  Our demonstration exploits a (known, patched) vulnerability in a key Windows service that is exposed (visible) within every sandbox.

Before we dive into the details, you might wonder why Bromium cares about breaking sandboxes.

• We continually conduct research to break our own product and other security infrastructure, to allow us to reason about the overall security of systems that we claim to protect.
• Sandboxes are clearly a good idea as part of an application, but we  have repeatedly questioned the value of general purpose "OS improvement" sandboxes that increase the attack surface significantly.  We wanted to know if they actually help.  (They don't)

Breaking any technology carries with it an ethical reporting obligation.   It is important to note that in our work we did not try to expose any new vulnerabilities.  We used known vulnerabilities in Windows 7 SP1 to demonstrate common architectural flaws present in all sandboxes.   We are not distributing exploit code, and no user will be any more vulnerable as a result of this disclosure than they were prior to it.  All vendors have been informed, and most have thanked us for our work.

We have addressed two key attack vectors:

• Our Research presented at Black Hat EU 2013 showed how malware can bypass any sandbox to take advantage of a kernel mode vulnerability – a rapidly growing class of attacks
• We have now also shown how user-mode malware can escape from any sandbox, permitting it to elevate its privileges and disable or bypass other forms of endpoint protection, and comprehensively compromise the endpoint, including data theft

To research whether or not we had uncovered a common flaw in all sandboxes, we tested the attack on several commercial products, including  Dell DDP | Protected Workspace,  Google Chrome, Adobe Reader XI, Sandboxie, and Trustware Bufferzone Pro.

Findings

• No sandbox can protect an OS that is itself vulnerable
• Sandboxes do not substantially reduce the attack surface of the system as a whole
• Sandboxes are not additive: Layering sandboxes doesn't change system vulnerability at all
• Application sandboxes (eg: the Chrome browser, Adobe Reader XI) are a good idea
  • But they cannot protect against advanced malware
• OS Improvement sandboxes (eg: Sandboxie, Dell DDP, Bufferzone Pro) expose many inherent weaknesses due to their need to work with many applications, and should not be relied upon

Operation Sandstorm Results

The Bottom Line

• Do not rely on any sandbox to protect your users from attack
• Do not assume that you can safely execute malware within a sandbox to understand its behavior
• Continue to regularly patch Windows to address both user-mode and kernel mode vulnerabilities.

Background

Everybody accepts that AV has passed its sell-by date.  To protect against today's torrent of malware, AV would need more signatures than any endpoint could consume.  To get around this ISVs, the security industry and application /desktop virtualization vendors have added a slew of additional technologies to their offerings, each of which has its own advantages and limitations.

This blog is focused on sandboxing, whose goal is to use software to contain malicious code, to prevent it from compromising the endpoint.   The Bromium Labs team has demonstrated that all Windows sandboxes suffers from two fundamental limitations  that are difficult or impossible for the vendor to address: Sandbox bypass, and Sandbox escape.

Sandbox Bypass

At Black Hat Europe 2013, our team showed how every sandbox is (and always will be) vulnerable to complete bypass when the attacker compromises the OS kernel directly, without needing to escape from the sandbox itself.

In our attack (pictured above) a malicious website simply causes the Windows kernel to parse a poisoned font, compromising the kernel directly without requiring malicious user-mode code to escape from the containment of the sandbox, into the kernel.  The attack simply exploits a logic flaw in the kernel itself, and relies on an ability to cause the kernel to stumble when it is doing work on behalf of the malicious application (in this case a malicious web site).   This category of vulnerability (a kernel flaw) is unfortunately being exploited much more frequently, with over 60 CVEs disclosed in 2013 to date.

Sandbox Escape

At Black Hat US in July 2013, the Bromium Labs demo takes advantage of a  design limitation of  every sandbox that permits user-mode code contained in the sandbox to escape, elevate its privileges and arbitrarily attack the system.  The vulnerability allows an attacker to escape from any sandbox and achieves privilege escalation by injecting itself into a shell outside the sandbox, from which it can carry disable other endpoint protection and comprehensively compromise the endpoint.    The architectural flaw results from the requirement that key Windows OS services be accessible to code executing within the sandbox.  A vulnerability in any of these services can be exploited to escape containment.

Here's the attack.  For detail see the Bromium Labs Blog, where you can also download the full pen-tester's guide to evaluation of sandboxes.

1. The attack relies on the observation that key Windows system services are present in (and unprotected by) every sandbox.   The diagram below lists the services that are visible within Sandboxie.  In Chrome they are fewer in number, but key services such as CSRSS are still present in the sandbox.

2. It takes advantage of a bug in the CSRSS service detailed in CVE-2011-1967.   Malicious code running supposedly isolated in the sandbox (for example in the browser) uses the exploit to inject keystrokes into a privileged shell outside the sandbox, which in turn permits it to disable other security software and download a sophisticated attack to comprehensively compromise the device.

Observations

• Today's software based endpoint protection mechanisms all have limitations.  They are useful, but cannot be relied upon.
• You should pay for solutions based on the value they deliver.  The leading anti-virus solution detects 83% of known attacks (and presumably a lot less than that for unknown attacks).   Would you buy a car that started only 83% of the time?  Every sandbox can be readily bypassed.  Pay accordingly.
• Sandboxes are useful components of applications, but are not viable as an endpoint protection mechanism since they cannot prevent advanced malware from compromising the system.
• The increased sophistication of attackers means that you should expect a targeted attack to be able to bypass all of your current endpoint protection mechanisms.

The only way forward is to leverage hardware-enforced protection:

• Hardware encryption of all data at rest (or simpler: hardware encryption of the whole device – such as Bitlocker)
• Attested boot.  This is now a Logo requirement for PCs that ship with Windows 8
• Hardware-based execution protection, including DEP and SMEP.
• Hardware isolated execution of untrusted code, for example using Bromium micro-virtualization.

There is a rich seam of security innovation arriving from Intel.  We are at the beginning of a brighter future in which devices protect themselves – independent of IT controls and pesky legacy security technologies.