Application Sandboxes: A pen-tester’s perspective

Sure, thanks, I guess that explains why it is possible to use SBIE4 on Windows XP Service Pack 3.

 

You can't compare flat Earth with POC at all, because there is no flat Earth it's been confirmed time and time again, I used to watch James May on Viasat Explorer where he went on 21 km height with special plane above Earth's surface and actually you can see the curvature of the horizon. Than there is international space station where you have astronauts see the curvature of the Earth as well.

It is true, and you're absolutely that POCs take a very long time to become reality and that's a huge if, since there is no guarantee how many of the POCs will ever become reality, if you want more suitable example take the Big Bang theory or Multiverse theory-actually hypothesis; which are both POCs in science since they can never be truly proven, since they cannot be detected by anything (and that includes scientific experiments in CERN).
Cheers.

 

Sorry, but that code breaking POC still does not prove anything, because why don't they use this code to break SBIE4 in a real deal, not with POC, why creating a POC if the danger is real-if the code presents a real danger?

If it's a POC and than its code in reality cannot do any harm, if I was Tzuk I would ask them to do the same but not without a POC code, but with real deal code against a true SBIE4.
That's the limitation of the POC, it means absolutely nothing, until you actually prove it in a real deal, in a wild.
Plus that keylogging can be blocked, like everything else in the list. The only real threat are kernel exploits-but again this is a mere, hypothetical POC.

Wikipedia on POC:
A proof of concept (POC) or a proof of principle is a realization of a certain method or idea to demonstrate its feasibility, or a demonstration in principle, whose purpose is to verify that some concept or theory has the potential of being used. A proof of concept is usually small and may or may not be complete.

 

It's all got very circular and repetative.

Seems really clear to me. The Bromuim demo clearly shows applications running in the sandbox can exploit Windows vulnerabilities to write out of the sandbox where any mitigations put in place by the sandbox are null and void. That should not be open to debate.

Users of sandboxes just have to decide how much of a threat that is and whether the risk outweighs the other benefits of sandboxing.

In coming to that decision cognisance should be taken of the fact that sandboxes do well against off the shelf exploits and that any, and I mean any, application is vulnerable to a targeted attack.

So you have a piece of software you like but recognise it can't protect in every circumstance. Do you embark on an impossible search for something that is invulnerable or get on with it. I know my choice.

Equally denying the existence of the threat is futile.

I know I could be stabbed in the street tonight but it does not stop me going out. I know I could be killed in a car crash but it doesn't stop me driving. It does make me take reasonable precautions to avoid those things though.

I know Sandboxie, and any other security app, will always be a potential attack vector because it is a piece of software written by a human being running on an OS incessantly under scrutiny by those trying to subvert it. However I take the view that for now it's less likely to be targeted than some alternatives. Like walking on well lit streets and driving safely it cuts down the chances of anything untoward happening.

You can't ask for anything else in my view. If you do you'll be continually disappointed or permanently in denial.

Cheers

 

I am just realising that might be true, allthough curvature is no circle, just a part of circle, like a PoC only contains part of the code needed to exploit a kernel bug. So let's use Ronan Tzur (Tzuk) the developer of Sandboxie as a replacement for James May. Picture taken from http://www.sandboxie.com/phpbb/viewtopic.php?p=75473&sid=a9cf26ce8082451b1a9a94d7f1dece80

 

It's not might be true, it is true that Earth is a round globe and this has been 100% proven!

Regarding Tzuk, he also said the following:
Don't understand why HungryMan is so sure that adding Sandboxie on top of Chrome can't help and can potentially hurt.

This is a one-sided and unsubstantiated claim that Chrome is absolutely perfect and beyond reproach, and Sandboxie can only introduce a weakness in the mix. I question the decency of posting something like that on this forum of all places.

There is no reason to disregard a scenario in which Chrome is exploited and web page can run a program outside the Chrome sandbox. (And there were actually talks all over the Internet about such an exploit just in May this year.) But very unlikely that such a browser-specific exploit would also break through the Sandboxie sandbox.

So in my opinion, it is a good idea to combine Sandboxie on top of Chrome.


As for running more or fewer security apps, that's your decision. Clearly every additional piece of software that you introduce to your system adds more security risks. And let's suppose that some security software that you add has an unknown exploit hidden somewhere. What if that expoit is never actually exploited, but that security software does protect you five times against other exploits? So in the bottom line, was it a good idea to add it, or not? Things are rarely black and white in life.

When you say something terse like "increased attack surface" it completely closes the door on the possibility that Chrome would have an exploit which Sandboxie would protect you against. But since you now seem to acknowledge such possibility, I would ask you to consider losing the bit about "increased attack surface" and just say that your opinion is that you're personally comfortable with using just Chrome, and leave it at that.

POC is just a POC, and I until I actually find this all in the wild through plenty of computers, POC is just hypothetical, this is how everyone should treat any POC whatsoever.
Denying that POC is only hypothetical, and not real and and does not spread out, than there is simply a matter of useless panic, much like multinational, pharmaceutical companies who told that swine flue is POTENTIALLY dangerous/lethal-and guess what, it wasn't, it was unnecessary panic to steal millions of dollars for useless drugs against swine flu.

 

Denying that POC is only hypothetical, and not real and and does not spread out, than there is simply a matter of useless panic, much like multinational, pharmaceutical companies who told that swine flue is POTENTIALLY dangerous/lethal-and guess what, it wasn't, it was unnecessary panic to steal millions of dollars for useless drugs against swine flu.

 

Google Chrome:
Design principles

Do not re-invent the wheel: It is tempting to extend the OS kernel with a better security model. Don't. Let the operating system apply its security to the objects it controls. On the other hand, it is OK to create application-level objects (abstractions) that have a custom security model.
Principle of least privilege: This should be applied both to the sandboxed code and to the code that controls the sandbox. In other words, the sandbox should work even if the user cannot elevate to super-user.
Assume sandboxed code is malicious code: For threat-modeling purposes, we consider the sandbox compromised (that is, running malicious code) once the execution path reaches past a few early calls in the main() function. In practice, it could happen as soon as the first external input is accepted, or right before the main loop is entered.
Be nimble: Non-malicious code does not try to access resources it cannot obtain. In this case the sandbox should impose near-zero performance impact. It's ok to have performance penalties for exceptional cases when a sensitive resource needs to be touched once in a controlled manner. This is usually the case if the OS security is used properly.
Emulation is not security: Emulation and virtual machine solutions do not by themselves provide security. The sandbox should not rely on code emulation, code translation, or patching to provide security.

Sandbox windows architecture

The Windows sandbox is a user-mode only sandbox. There are no special kernel mode drivers, and the user does not need to be an administrator in order for the sandbox to operate correctly. The sandbox is designed for 32-bit processes and has been tested on Windows 2000, Windows XP 32 bits, and Windows Vista 32 and 64 bits.

Sandbox operates at process-level granularity. Anything that needs to be sandboxed needs to live on a separate process. The minimal sandbox configuration has two processes: one that is a privileged controller known as the broker, and one or more sandboxed processes known as the target. Throughout the documentation and the code these two terms are used with that precise connotation. The sandbox is provided as a static library that must be linked to both the broker and the target executables.

Other caveats
The operating system might have bugs. Of interest are bugs in the Windows API that allow the bypass of the regular security checks. If such a bug exists, malware will be able to bypass the sandbox restrictions and broker policy and possibly compromise the computer. Under Windows, there is no practical way to prevent code in the sandbox from calling a system service.


How does Sandboxie protect me, technically?

Sandboxie extends the operating system (OS) with sandboxing capabilities by blending into it. Applications can never access hardware such as disk storage directly, they have to ask the OS to do it for them. Since Sandboxie integrates into the OS, it can do what it does without risk of being circumvented.

The following classes of system objects are supervised by Sandboxie: Files, Disk Devices, Registry Keys, Process and Thread objects, Driver objects, and objects used for Inter-process communication: Named Pipes and Mailbox Objects, Events, Mutexs (Mutants in NT speak), Semaphores, Sections and LPC Ports. For some more information on this, see Sandbox Hierarchy.

Sandboxie also takes measures to prevent programs executing inside the sandbox from hijacking non-sandboxed programs and using them as a vehicle to operate outside the sandbox.

Sandboxie also prevents programs executing inside the sandbox from loading drivers directly. It also prevents programs from asking a central system component, known as the Service Control Manager, to load drivers on their behalf. In this way, drivers, and more importantly, rootkits, cannot be installed by a sandboxed program.

It should be noted, however, that Sandboxie does not typically stop sandboxed programs from reading your sensitive data. However, by careful configuration of the ClosedFilePath and ClosedKeyPath settings, you can achieve this goal as well.

 

It sounds like you're only going to be convinced of an attacks efficacy when you see it in the wild. Waiting for people to start being attacked before you start defending is a way to perpetuate the cat-mouse game that defenders have found themselves in.

 

Exactly, if they happen, if the POC becomes real reality-not before, why making your software more robust against any POC if it could potentially mean also that creating a more robust software creates new holes/vulnerabilities in that software?
This is why POC is useless, and only when it becomes real reality and spreads out than we can say, OK this is for real, but so far I haven't seen any POC becoming real so far.

I bet any computer system can be created bulletproof, but it's not the interest of the business, so they create holes/vulnerabilities-it's all about money.
People you're too paranoid.
This is why I gave my example with the swine flu scandal.

 

I'm going to play devil's advocate for a moment, and say that it might take a very long time for these POC attacks to start appearing in the wild.

Over the last week I've been spending rather a lot of time testing different security software. What I've been finding is that a lot of it is actually very good at preventing persistence. Even when I do have kernel access, messing around in kernel space is painful and difficult; so far I've had zero success with it. Could be I don't know enough about the Win32 API to be effective...

But that's when I do have kernel access. Several times I've observed HIPS software causing kernel exploits to fail; sometimes apparently from blocking syscalls, mostly just from blocking things the attacks require (such as migration or code injection).

A properly configured Windows system, it seems, is pretty resilient against root access and persistence.

The problem is, you don't necessarily need root access or persistence to cause damage. If you can run code in the context of a user account, maybe even with some restrictions, you can steal all kinds of "useful" data. Almost any client-side exploit will get you that, and few of the programs I tested provided any defense against it.

So yes, securing Swiss cheese kernels is a problem. But from what I've seen so far, I think the more urgent issue is preventing userspace exploits against client software. Kernel exploits are difficult, and don't pay that well; userspace exploits are plentiful, easy, and lucrative. And most security software is really bad at preventing and/or containing them (because it specifically focuses on peristent malware).

 

GJ,

I don't expect to see kernel attacks used commonly in the wild any time soon, though not for the reasons you've listed. While you have had issues, it's largely because you're using public exploits that aren't really designed to be 'attack-ready' but instead for use and modification by pentesters (who *do* heavily modify the attacks for what they need) and for demonstrative purposes. I personally have not worked with that sort of thing enough, so I, like you, would not be able to modify the payloads to work the way I want. That isn't to say it's very difficult, but it does require the background.

HIPS software can do a bit. I am reluctant to have too much of a discussion on this because it will vary so greatly from one variation to the next (every sandbox is, in reality, a HIPS, as are a thousand other security products), and I'll just get 50 responses saying "well product X does Y", which will lead to endless discussion.

The way I see it, attacks can go one of two ways. They can go with kernel exploits, or, as you mentioned, they can monetize from within the sandbox.

Right now it's incredibly profitable to create a botnet. Hundreds of thousands of dollars a year, potentially millions if you work on a decent team, all if you can perform a few simple commands on the system. But sandboxes can kill those commands. So attackers either need to break out of the sandbox to create their botnet or they need to find a new way to make money (not that hard).

Where kernel exploits will always be very common is in targeted or watering hole (semi-targeted) attacks, both of which I think will continue to become more prevalent over time. While these attacks are not necessarily going to affect the 'average user', they can.

 

Fair enough. I don't know much about the threat landscape at this point, so I'll admit I could be barking up the wrong tree. As modifying my payloads, I knew I'd have to bite that bullet sooner or later...

Re botnets, I'd be interested in seeing some statistics on how many botnet trojans have capabilities for kernel exploitation, breaking out of sandboxes, etc. (not including social engineering).

 

Waiting until it's too late is the philosophy of a Sandboxie user? You're previous posts shows otherwise, seeing how much energy you put into the concern of this "non-reality".

Please, tell me how putting a sandbox inside a sandbox isn't paranoia.

 

In Sandboxie I trust, amen. These humorless adversaries. They are so desperate in their pleads like just some poster above lol.

I really don't much trust Google. So it has somekind of a sandbox. Does not mean a thing for me if it has or not with using SBIE.

See Google can take care of what it does with that surfing thing. I need something to care about with its extension or what **** it might spawn out, thats why SBIE.

 

So throw away facts altogether and just go with preference. Or you could prove to me that Chrome was bypassed in real life without social engineering (which Sandboxie is also powerless against).

 

They don't, afaik. Or, well, not many do. I've talked to hackers about this and their response is typically "I don't want to do anything special because I already make tons of money and being special gets you attention."

Once one person starts though, it stops being 'special' to do it. And as sandboxes become more prevalent (the trend) there's a rising chance of someone deciding to break the ice.

 

Just a few of the comments that have made me decide to mothball my XP machine. I'll be running strictly Win7 from now on.

 

It isn't, at least not to me, I'm not a paranoid, I don't have dozens of security programs like most of the users here on these forums have.
Usually, I don't like to use SBIE with Chrome, sandbox within sandbox, not because of security issue-because there is no issue in this category, but because of incompatibility issues (like getting bsods, re-installing windows).
I tried Chrome and it works superbly under the SBIE, but because of the incompatibility issue, I decided it's better to use one them at a time, not 2 of them at the same time (sandbox inside a sandbox).

This is not just a matter of SBIE or Chrome, it is a matter of every single security product that increased security code and than makes your system even more vulnerable-so according to this research, none should have any kind of additional protection (from firewall, antivirus, antimalware, HIPS, Sandbox and etc...) because it increases attack surface, becausing the increasing security code actually makes more vulnerable.
Who is nuts here they or me?

Why have a protection at all.
Read above what Tzuk said about Chrome sandbox inside Sandboxie-just because Hungry Man says something it doesn't mean it's always right.
It has to be tested first, than make conclusions.

 

Obviously you trust hypotheses, not facts. Chrome pays others to bypass it-and it was bypassed:
http://www.zdnet.com/blog/security/cansecwest-pwnium-google-chrome-hacked-with-sandbox-bypass/10563

http://www.vupen.com/demos/VUPEN_Pwning_Chrome.php

Plus, the problem with testing with SBIE is that they did not configure SBIE before putting into test-the evidence is that keylogging would not be possible, also, user mode/kernel mode exploits (well, most of them, because kernel mode exploits are the trickiest ones since they are the most critical and can be used to bypass your computer OS, SBIE or any other security software), remote webcam/MIC access, Clipboard Hijack, Screen Scraping, Steal Files, Network Shares Access would not be possible with tightly configured SBIE, so when Tzuk says that to exclude SBIE from similar testing, it should be noted that SBIE with default settings should be excluded from similar testings (because it says to malwares and exploits "all doors are open come and infect computer system, please"), not tightly configured SBIE-and that's only thing that should be done before testing SBIE, I don't know why so many people do not see this obvious difference.

If you really want to test SBIE and claim the bypass, than above mentioned fact is the first thing that should be changed when you test SBIE.

 

So you would've done the unnecessarily paranoid anyways if not for incompatibility. Speaking of tested, it hasn't been and yet you're already supporting one side over the other.

And how are those Google-sponsored bypasses different from these POC's? You're the one who stated that it must be in the wild to count. Now you're giving the same kind of testing environment more credit than others. Plus, why not tightened Chrome if your going to harden Sandboxie and claim that's how it should be done? Clearly, there's obvious favouritism that I've personally been guilty of still lingering.

 

Because this was not a POC nowhere in links I gave to you in the previous post there is a mention of POC!
What are you talking about, you seem to chose side not me, I gave you a link above where a hacker broke through Google Chrome's defenses-and you ignore it.

 

Tell me how Bromium's tests are invalid compared to the links you gave me, especially considering how you supposedly only accept in the wild results.

 

The very first thing mentioned: POC, there is no mention of POC in links I gave you above-because hacker did not use any theoretical signs of vulnerabilities, but the real holes/vulnerabilities and broke through Chrome's defenses. Also, they should test tightly configured SBIE and not SBIE with default settings-there is a huge difference, this mistake always repeats itself over and over again.

If the bypass mentioned on links I gave above are also only hypothetical POCs like that research within Bromium labs, than they should be both completely ignored, because it's another hypothesis.