Application Sandboxes: A pen-tester’s perspective

No. Even when it's sometime hard to compare these product types and often it is spoken that shadow defender is a system wide virtualisation, look what the product currently is doing: It is using a filtering driver (kernelmode) and redirects all write processes from real disk sectors to the virtual file (diskpt).

So when we see the 2 issue groups discussed for sandboxes:
(1) windows design flaw: When malware gets kernel access (f.e. via kernel exploit) Shadow Defender can do nothing against it and the filter driver can be disabled. From user mode this should be harder...

(2) runtime issues: Normal malware works in shadow mode. Even if it can do no permanent damage to file system: keyloggers can steal passwords, trojans can steal files etc.

 

Less, if anything.

The issue is not application sandboxes, it is all sandboxes that attempt to be generic. They are all very very loose, and even tight ones like a well configured sandboxie are not particularly strong, because they don't have the right focus.

 

HM, if it was that easy to bypass Sandboxie, why aren't there any real life cases of real malware that uses the technique described by the guy in the video? Where are the Sandboxie users that are getting infected because of the existence of this particular Windows vulnerability? I dare you, show me real malware based on what the guy talks about that bypasses Sandboxie. Malware bypassing SBIE in a YT video means nothing. The Windows vulnerability is real but that's it.

Bo

 

I cannot comment on the technical aspects of this analysis because it's way over my head, but I trust the author's argumentation. The only thing that's bothering me is that this is pimarily unsettling people without giving further advice (aside from using Chrome on Linux). There are many "alternatives" out there which are far more expensive, resource demanding and even easier to bypass. I already see people ditching Sandboxie for worse solutions because they are not mentioned in this discussion.

 

@Bo,

Because why would anyone bother? If there were significant money to be made doing it, they *might* do it, but otherwise it's not worth it. Being unique gets you one thing as an attacker - attention, and that's bad.

To call this a 'Windows vulnerability' is to misunderstand the research. It leverages Windows inability to allow for strong sandboxes against sandboxing programs.

Maybe to you! But that's not really my issue.

The Windows vulnerability is irrelevant. This is an issue of capabilities.

@Peter,

Everythign done in the video can be run from a compromised process.

@Fleisch,

I was actually at this particular conference and one of the things discussed was that many presenters say "Here's how we break things" without "Here's how we should fix them". In terms of "how to fix this" there is little that you as a user can do - you can pretty much just hope that developers start to build stronger sandboxes, and that Microsoft provides the capabilities to do so ASAP. Chrome uses a powerful sandbox already, so if you want strong sandboxing I suggest using that. Or, use Linux, which allows for much stronger sandboxing.

 

@Hungry man, you forgot:

No answer means there is none.

FleischmannTV, I see a little of what you are saying and it bothers me because this BS is coming from people that have their own product to sell.

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

The HOW Sandboxie can be bypassed described by the guy in the video is probably real. HM says is real, guess what, I believe him. But the "How" it can be done means nothing if its not being done.

I think Tzuk is a pretty smart guy. Why the hell should he spend his time on something that to this day it has not affected anyone using Sandboxie.

Bo

 

I figured that was covered in the other answers when I said attackers don't care about Sandboxie users.

I was very happy to see that the Bromium talk didn't actually bring up Bromium. Some talks are really sales pitches, and it's annoying. His wasn't, it was a lot of information displayed very well, in my opinion.

How something is done is very important because research like this usually predates attacks that use the techniques - ROP is now incredibly common, but research for it has existed for well over a decade, and we only really saw ROP attacks multiple years after that. I am sure that people at one point were saying "Oh, ROP is just a 'how', it's not something to worry about" until it *was* something to worry about.

I think understanding limitations of security solutions is important. I think this video demonstrates those limitations quite well. That's pretty much the long and short of it.

 

Ten years! HM, you think I am going to worry for the next ten years for something that might never happen? You or I might not even be here ten years from now.

Anyway, I like you HM, you are a good man and very knowledgeable. But I guess, you are recognizing that as of this moment there is no known malware that bypasses SBIE as described by the guy in the video. Right?

Bo

 

Peter,
Sure. So if you were running a Firefox sandbox then it would be Firefox that must be exploited, as would be a necessary step with or without the sandbox.

Bo,

I do not expect to wait 10 years. ROP did not take 10 years at all, the first research for it was in the mid to late 90s and once DEP became popular so did ROP.

As sandboxes become more and more popular I expect to see attackers move to kernel based attacks, or other simpler post exploitation attacks - right now attackers have still been playing around with other attacks on sandboxed apps. I don't expect it to take 10 years at all, in fact I'm surprised we haven't seen an attack already, but I guess that's largely because the world is still running largely unsandboxed software (out of date adobe reader, java, flash, etc).

Having talked to attackers, they really like the idea of sandbox bypasses, but kernel exploitation is something they are less familiar with. That won't always be the case.

 

In any of the million ways a browser gets exploited.

 

Usually I've been one to hotly contest HM's security concern assertions, particularly against Windows, in these forums, but recently I'm seeing he has many valid points. All those millions of line of code (loc) the Bromium author alluded to in the Windows kernel have indisputably resulted in numerous vulnerabilities discovered in it over the years.

Even if it's not currently easy to exploit from the path of point A to B, if the inherent security design of the kernel contains enough sloppy coding to make attacking it successfully possible, then I'm open to alternatives. We know what Duqu could do, so it can be done. BTW, the latter two of the exploits used in the sanbox testing, mishandling of true type fonts by the Windows kernel, can be triggered by a victim visiting a malicious website. Sure it might take some social engineering along the way, and there's plenty of evidence of how alarmingly successful that is.

 

How about not using proper input validation, which accounts for 99% of buffer overflows? Not tracking pointer logic well enough, or free[]s? I can list a large number of attacks against modern programs, but you could just google for Firefox's vulnerabilities and find much more detail.

Of course I can give an example. It's just irrelevant because you could just as easily google for something like that with "CVE Firefox".

Exploitation would be an attacker leveraging flaws in your browser (or other code) in order to execute their own code, typically in the form of a ROP chain (in order or out of order execution attacks, if you want something to look into), in which they control the instruction pointer or some other area of the processes address space, and leverage that for further control of the process. Eventually they are quite literally the Firefox process, executing Firefox code. They can then drop their own code into the Firefox address space (they do not have to and attacks HAVE used all-ROP gadgets to form their attacks), have the pointer to the code, and it executes.

They can run local privilege escalation attacks (as described int eh video) or perform other great post-exploitation tactics, like pulling in password files, registry keys, AV information, update information, etc. all of which aids greatly in post exploitation.

So the attack vector is, to be short: Attacker breaks Firefox. Attacker uses Firefox to attack kernel. Attacker is no longer confined by the sandboxes.

 

Hi HM, I'm a big SBIE fan but nothing you're saying surprises me.

For clarification I think people, including me, struggle with the concept that exploits can come from within the Sandboxed process so you don't need a traditional executable dropped and launched.

Am I right in assuming that what your saying is that in principle visiting a vulnerable website can initiate scripting (that is allowed because browsers need it to control/display content) that can get an attacker control of the browser. From there the browser can exploit the kernal and escape the sandbox? If not and there needs some form of exceutable launched then how are sandboxes with start/run restrictions compromised?

I'm not saying any of this is happening ITW but want to better understand how even with start/run restrictions sandboxes can be compromised.

Understanding what is possible and then making your own decisions about how probable that is for you is fundamental in establishing your security set up in my view.

Thanks

 

This is, essentially, correct. It doesn't have to be scripting, per se, but at some point an attacker gets your browser to take in content that they control, and they use that to take control of the browser.

You have a browser "process" executing. It can open files, close files, create new memory, etc. An attacker who controls your browser does all of those things within the context of that browser. It can interact with the kernel, and so can the attacker, which means that it can exploit the kernel.

That is my view as well.

@Peter,

I'm less familiar with Appguard than Sandboxie. But yes, layering is the way to go, it is just very important to understand which layers are doing what.

 

Indeed and I and possibly many others sure don't. It would have been better if the article had cleared up in advance with possible misconceptions that might arise in the readership. I'm thinking of scenarios like replacing sandboxie with an anti-exploit program or an internet security suite with a so called feature or the thought that Chrome's sandbox could be hardened with it.

I don't have the competence to do so, but I would appreciate it if somebody could clarify that the vulnerability against these advanced and targeted attacks applies to most if not all of the other security solutions out there just as well.

 

I understand this threat isn't in the wild but what type of program or policy would be good to back up Sandboxie? I've always assumed that Online Armor would alert me when something new and untrusted would run but it seems this is different. Is there anything in my signature that covers this type of exploit?

 

When we take the time to choose security applications to secure our O/S, and in some cases augment those applications with built-in measures, aren't we in effect doing this because the foundation they reside on - the O/S, or kernel - is too inherently weak to guard itself against attacks thrown at it? It's a bit like using hydraulic concrete and metal braces to secure a cracked foundation. All one has to do is search up CVE's on the Windows 7 kernel and see there are hundreds of them related to it, many of them with scores of over 9.

I think I now understand what HM has meant when he has stated many times "it's Microsoft's fault" I never thought I'd agree with him but I believe he has a most valid point.

In my case I never before considered the integrity of the O/S, only satisfied that I was using my favourite combination of security products and built-in O/S measures to form a fortress against potential malware attacks, but now with recently taking the O/S in to consideration I don't feel so satisfied that these measures are sitting on a foundation rife with potential targets.

A disclaimer: I'm not trying to promote linux here:

I fully understand linux not being a solution for many. For myself it seems to be turning into one, because my needs are very simple. No doubt it has vulnerabilities of its own, nothing is perfect, but the current distro I'm using works very well for me and fulfills my needs completely. The Chrome sandbox indisputably is a superior sandbox solution on this platform as well. Frankly, however, it does pain me some to use Chrome because of its reported privacy concerns, but its security structure seems to be superior to other browsers, especially Firefox, although I have the latter installed with the inimitable NoScript extension (if only chrome could get a javascript control extension like this ). Both browsers are nicely fortified with Linux' built-in to the kernel Apparmor module. The only other measure is using UFW to block inbound and restrict outbound.

From my admitted technically limited pov, I'm quite confident this is a simple yet graceful and robust solution, right from the base kernel and up.

 

No, it's because of our operating system's inherent out-of-the-box default permit status. If you take a look at Windows_Security's setup, you will see that he can get at least as secure as with any AV just by using the operating system's own mechanisms.

The operating system's kernel weaknesses on the other hand cannot be compensated by software which rests upon that same compromised fundament. Chrome on Linux is much more secure because of it's extremely restricted interaction with the kernel.