Application Sandboxes: A pen-tester’s perspective

http://labs.bromium.com/2013/07/23/application-sandboxes-a-pen-testers-perspective/

 

This is because many sandboxes confine a user in terms of file system access, but they don't actually limit an attackers knowledge of the system, or the attack surface.

So it ends up being +1 vuln.

 

Isn't a sandbox supposed to prevent something from making changes to your system as opposed to accessing to your system? Aren't most of their leakage criteria access requests that fall under the domain of a HIPS and not a sandbox? Or am I missing something?

 

While I don't trust containment based security policies as a primary defense, I have been using SandBoxie for its ability to automatically eliminate usage tracks from the browser. I also viewed it as a secondary layer of isolation for attack surface apps running inside of it. Default-deny and reducing the attack surface are my primary defenses, but now I'm wondering if the sandbox itself and the permissions it requires are creating more vulnerabilities than they're fixing.

 

Were tests performed on default settings of sandboxes?

If for example the sandbox were set to deny any process except a browser, what would the results be?

Another example, if the browser were running at Low Integrity, what would happen. Not a broker process at High with children at Medium or Low, but all of the processes at Low. As in the case of chrome if you set it manually.

 

Any program adds vulnerabilities. That's a given. It's a matter of compromise. In the case of a sandbox program like Sandboxie (more so with the direction it's going with V4), the sandboxing benefits it provides for otherwise programs that don't come with their own sandbox outweighs vulnerabilities it potentially creates.

Of course, in your case, you're already missing out on the modern security technologies that are simply not there in Win98SE (or XP for that matter). It makes the vulnerabilities in Sandboxie (V3 and below) matter less. Just keep Sandboxie for what you're using it for.

Depends on how you view it. In my definition, a sandbox like Sandboxie is a HIPS predefined with it's own set of rules to limit file system access and redirect it to a 'virtual' area. When you use such a sandbox, by principle you are generally expecting it to deal with untrusted code.

If that code can keylog and access areas like your cilipboard, it already has 'win some'. To Sandboxie's credits though, Tzuk has been clear and upfront about Sandboxie's limitations on this and that users should not be expecting more than what Sandboxie was designed for. You need to know what's the purpose of the sandbox you're using.

Doesn't matter. If Chrome's sandbox at Untrusted IL can be bypassed with the right vulnerabilites in the underlying OS, Sandboxie won't do any better (as much as I admire Tzuk's dedication to his software).

-------------------------------------------------------------------------

Anyway, it's all very interesting if you read the report

-http://bromiumlabs.files.wordpress.com/2013/07/application_sandboxes_a_pen_tester_s_perspective2.pdf-

Here are a few quotes:

Lesson: Sandboxie is a good tool for sandboxing programs that do not come with their own built-in sandbox, as long as the threats are not sophisticated or targeted. Leave Chrome's sandbox on it's own.

Lesson: Security-wise, pointless to use Sandboxie to sandbox Chrome. Leave Chrome's sandbox on it's own. Privacy-wise, as an alternative, you might want to use Chrome's Incognito mode instead of Sandboxie.

Lesson: All it takes is an OS vulnerability to bypass a sandbox. So, best practice: Patch! No software can replace patching. Yes, I do know about the The Six Dumbest Ideas in Computer Security and I somewhat agree.

If you're safe without patches, it's mostly because your setup is different from the majority of users and you're not targeted. Security by diversity and not security by design.

A good read:
Operating Systems Define Security

 

I was specifically thinking of how an exploit is going to run (and get root or whatever) if the only process allowed to run is the browser (in the case of sandboxie anyway). If the browser were at Low integrity in addition (within the sandboxie) how would this change things. Also, what if (again, in the case of sandboxie) the reduced rights option were used.

I also wonder, because I don't know, are exploits being discussed (and not necessarily limited to this pen-testers report) soley limited to a process running within a sandbox that escapes it, or is there also included outside attacks that neuter the sandbox so future use of sandbox allows exploit. I ask because, there would seem to be a large difference between running a browser in the sandbox and there being a way to escape it versus something running on the system that compromises the sandbox.

 

Is there a page that goes into detail about the working differences between the 4.x and the last 3.x versions of SandBoxie? If I understand it correctly, the 4.X versions were developed because Win 7 and 8 don't allow the mechanisms used by the 3.X versions, and on XP, the 4.X versions aren't as strong.
Regarding:

These "modern security technologies" in themselves are good, but I question their implementation on Windows. Compared to other operating systems, their implementation is weak and incomplete, maybe deliberately so. Like you said earlier regarding SandBoxie, "It's a matter of compromise." IMO, the privacy implications of Win 7 and 8 outweigh the benefits of their "modern security technologies".

For me SandBoxie has been primarily a privacy enhancement. I appreciated it's ability to delete everything added via the browser as soon as it was closed, including items not stored in the browsers own directories. On my 9X system, I accomplished much the same by moving the browser user profile to a ramdrive. It should be fairly easy to do the same on XP.

Regarding SandBoxie and attack surface isolation, much of what SandBoxie does is redundant on my system. The classic HIPS combined with registry and file system permission restrictions had most of the isolation covered. My concern is the sandbox itself, the system access it requires, and whether or not a default-deny policy enforced by HIPS is capable of mitigating the risk added by the additional attack surface.

On a system where SandBoxie is the primary defense, I would agree that its benefit outweighs the risk due to the additional attack surface. That too would depend on what one considers to be the bigger threat. Given recent events and revelations, I consider "mandated" backdoors and vulnerabilities to be a very real threat.

 

None of this would have an effect on the results, unless you also had low integrity with no reading higher integrity files, in which case a few of the "stealing file" type results would be more difficult.

An attacker can run exploits from within the browser to escape a sandbox.

It's referring to a process escaping the confinement of a sandbox.

@noone

I still think that if you consider backdoors a legitimate threat than Windows as a whole should be considered a lost cause. Their involvement with the NSA predates Vista/7.

 

@biased

The AE component in Sandboxie doesn't block DLL so that's 1 thing.

As to how they're going to run, exploiting kernel vulnerabilities. Font handling, bugs in graphics subsystem, etc etc. Look at the report. Your browser renders all of this thing. Once they get root, forget about your defenses.

https://threatpost.com/using-kernel-exploits-bypass-sandboxes-fun-and-profit-031813/77638
https://threatpost.com/of-truetype-font-vulnerabilities-and-the-windows-kernel

Have a look at what Tzuk has to say about it:

Source: http://www.sandboxie.com/phpbb/viewtopic.php?p=75473&sid=a9cf26ce8082451b1a9a94d7f1dece80

@noone_particular

V3 utilizes kernel patching/hooks. V4 was redesigned to alter the permissions (like Untrusted IL on Vista and above) mainly due to Kernel Patch Protection. On XP, some hooks are still being used.

SANDBOXIE INTERNALS REDESIGNED IN VERSION 4

As for which one's "stronger", here's what Tzuk has to say:

http://www.sandboxie.com/phpbb/posting.php?mode=quote&p=88126

Just take note that you need a minimum of XP SP3 for Sandboxie V4.

Well, that's another topic for a different discussion. Let's not go there on this thread.

 

Very interesting, and a bit disturbing. However, I do wonder about other HIPS, is it easy to defeat them too?

I mean what if a process (malware) breaks out of the sandbox like Sandboxie, isn´t it still being monitored by regular HIPS?

Btw, the Bromium vSentry tech looks kinda cool, it works about the same as the Qubes OS.

I also wonder about when we will get to see tech like Mcafee´s DeepSafe and Hypersight Rootkit Detector (from North Security Labs).

I can´t wait for these hypervisor based HIPS!

http://www.bromium.com/products/vsentry.html

http://www.mcafee.com/us/solutions/mcafee-deepsafe.aspx

 

What HIPS? Classical HIPS? Well, yes, it is supposed to. Unless you have a bad whitelist or take the wrong decision.

 

Thank you BoerenkoolMetWorst, that was an interesting read.

I must admit I'm surprised and disturbed how ineffective Sandboxie is, esp. with preventing keylogging of unsandboxed programs from within the sandbox, which it is supposed to do. In general there seems to be a lot of leakage from "Type A" sandboxes. OTOH the results re malware and kernel vulns are exactly as I would have expected.

Other things of note:

- Dell Protected Workspace is based on Invincea. I thought that was a hypervisor based sandbox like Bromium, and therefore much more secure than Sandboxie? (Evidently not.)

- According to the PDF, a some high-level functionality in the Windows graphics subsystem (e.g. functions for creating a new window) is still in kernel space. This surprises me, I thought they moved a bunch of this stuff to user space in Windows Vista/7. Anyway this suggests that Windows may have some of the same issues as Linux/X11, no?

 

What do you expect with generous read access and Internet access for compatibility by default? Sandboxie can be configured with a variety of whitelist/blacklist access restrictions, not to mention such things can be managed by other software such as a firewall.

Therefore leakage isn't something you should be worrying about if your data is secured and security properly configured. As for kernel exploits, you're pretty much screwed at that point, don't depend on third-party software to protect you.

 

Yes, I wish they could also test this. A lot of people are using multiple HIPS (or layers), I wonder if they can still save you if one of the HIPS fails.

Yes, good point, I also thought that Invincea was more advanced? I wonder what they have to say about this.

Also, I never really knew that the sandboxes in Chrome and Adobe Reader were meant to protect from zero day attacks?

I do know that Google got the tech from GreenBorder which offered a solution similar to Sandboxie, it´s a shame they killed the app.

http://www.informationweek.com/greenborder-sends-bad-software-to-the-sa/190400272

 

If a HIPS is well configured then it'll be extremely difficult to defeat.

While I'm always intrigued by these scary bypass tests I'm far more interested in Real-World examples of bypasses that can defeat an advanced security setup without the need for user stupidity.

As for Sandboxie,I've not read through the report,but was this in a stock configuration or were rights limiting/access restrictions in place?

 

Same over here, I think these tests are interesting but I believe HIPS offer good enough protection for the real world.

I haven´t been hacked since I started using HIPS like 8 years ago, I don´t think that´s purely luck. Of course common sense also helps a lot.

I don´t think SBIE was configured for extra security. I also don´t know if that would have made a difference.

 

It still requires a more responsible user though.

 

any POC that can bypass the new sbie 4.05? if not i dont trust
scenarios about "OS exploits-buffer overflow-kernel attack etc."
i tried many samples vs sbie 4.05 and i think its the best security layer
without a POC yes even your house is hacked and under surveillance.

 

Nice read BoerenkoolMetWorst,

Sandbox leakage
Most application sandboxes are designed to protect the system from the application, not the application from the system. So leakage happening in a sandbox session comes with the benefits (Tzuk has also asked to withdraw Sandboxie from the financial malware/MITM tests, because it is not designed that way). So I think it is a pitty this is also incorporated in this research. Provides SBIE fans with "I am a believer" reasons to ignore (and be deaf and blind for this read), because it lacks in their view the understanding on how application sandbox works.

Off the shelves PoC's
I have critisized Sandboxie (as Kees1958 ) for running Admin in (XP times) and not running Low Integrity Level (Vista and early years of Windows7). My critique was that it made no sense in adding a security layer which lowered security in the first place. Tzuk has solved those issues. This test also shows that SBIE blocks known PoC's, so risk of priveledge elevation is minimal. Case closed IMO .

Exploit protection
For starters no application software using OS-mechanism (hooks/API's/etc) can protect you against malware using exploits which bypass those OS-mechanisms. The conclusion type A does not give much benefit over type B sandboxes is something which is as logical as an falling apple proofs the law's of gravity. Only most SBIE users are IT-outsiders and will fall over this report to say "a properly configured bla bla" or "I have yet to see any malware bypassing my setup with SBIE so bla bla". This in contrast with Tzuk who clearly states that when the foundation which is used by Sandboxie is bypassed, Sandboxie could (will) be bypassed also (honestly one cannot blame Sandboxie for this).

Going to enjoy this thread

 

Why is it an option in SBIE to sandbox Chrome if it is not the right thing to do, security wise? I have searched the SBIE Forum for direction on this and I have not found a statement that advises against sandboxing Chrome. Chrome is my default browser and I have the paid version of SBIE. Having read this thread I am going to remove Chrome from SBIE protection unless someone convinces me that I should not. This is the first time I have seen such a definitive statement on this subject. I will keep FF and IE under SBIE control (do not know if IE has any SB built in as I very rarely use it).

 

Confirmed Sandboxie fan boy here but but I'm not going to argue with anything you've said or anything in the report. No surprises in either for me.

Sandboxie, is in my view, a brilliant program but its not a panacea for the prevention of malicious activity taking place on a system it protects whether there are a string of well thought-out start/run etc restrictions in place or not. Surely nobody (including Tzuk) thinks it or any other application is?

Everyone who knows the product must know Sandboxie does not protect you from anything running outside the sandboxed environment. The nature of integration with the OS on which it runs will mean that, while Sandboxie will prevent many common (and some not so common) techniques, it cannot be expected to prevent leakage in every case - particularly targeted cases.

What you do get from Sandboxie though is a well written, well supported light application virtualiser that restricts unwanted behavior by default and can be hardened (and made more vulnerable I admit) through a myriad of user options. Because vulnerable applications can be restricted you can close down many common attack vectors and the remnants flushed away on close-down.

I admit I may run across a site that executes code that escapes the sandbox and kicks off some unforeseen/unwanted/malicious actions but in my experience that code will be successful in delivering its payload less often in a sandboxed environment than it would using many of the bog standard AV/suites etc which (other than Kaspersky) seem hopelessly inadequate at dealing with exploits.

So in the end it is down to choice and balancing of your needs. Nothing is full proof and everything you add to your system adds a potential vulnerability. You need to pick what makes sense to you and gives you the best coverage for your usage habits. For me that's Sandboxie.

Couple it with something like AppGaurd at lockdown restricting memory manipulation and your getting as good as you'll get IMO, recognising something no doubt can and will get past it. That type of malware will be much less prevalent than those looking to by-pass your more common approaches to security I would think.

Cheers

 

Emmjay,

In XP most people ran as administrator. Xp had much less protection against exploits than Windows 7/8 (DEP on XP, DEP for all on Win7, with ASLR, SEHOP, EMET). So the threat of something bypassing the OS internals and thus Sandboxie were much greater at that time. Now with UAC and the additional low integrity level which Chrome sandbox is based on, the browser is not as weak as it was in XP-days.

Bottem line: nowadays the level of security now with UAC/Sandboxie/Low Integrity Level/EMET is a factor two to three more secure than with XP. In regard to exploits it does not make a difference running Chrome with or without SBIE, but against a lot of ordinary malware SBIE stops it dead cold.

Because this report proofs that 2x sandbox does not add up to twice the security, does not imply it is wrong, SBIE is simply not the solution for every malware problem (but still a very good solution, like DefenseWall which allways scores 100% in MRG effitas test).

 

Of course the stopped dead cold part depends on the user's downloads/system and Sandboxie configuration. If they keep everything at default, no point running Chrome in it unless they execute downloads within Sandboxie. What I mean by system is whether it's infected or not, Sandboxie restrictions and other settings can prevent data transmission, detect/limit the infection, etc.

Personally, I don't feel any need for sandboxing Chrome. I don't execute downloads without checking them. I don't need restrictions with 3 anti-exploit programs, Avast, Tinywall, and various extensions. And my system has been clean since installation.

 

Tnx Windows_Security for the explanation. I guess I should not have used the word 'wrong', but instead 'not advisable'. When there are competing forces at work then it is best to know why it is so. As each product becomes more powerful I can only assume that one or the other may have to recommend they are not compatible. For downloading one can always use another browser under SBIE control as they support so many.