Sandboxie Acquired by Invincea

True, very true, when you talk about compatibility issues between Chrome and Sandboxie, this is why I didn't use Google Chrome for the most of the time with Sandboxie, because I always had some problems with compatibility issues in the past, but right now, everything works smoothly, after several years of delay.
When the next problem rises regarding compatibility issues between SBIE and Chrome, I'll run and surf with Chrome unsandboxed, again.

 

I use Chromium for browsing to known sites (in my bookmarks/favorites bar). Chromium is unsigned and I have UAC set to deny elevation of unsigned binaries. I run Chromium without flash, use EMET 4.1.1 to mitigate memory exploits, only allow javascript from NL and COM domains and use AVG Linkscanner to scan javascript for irregularities and exploit kits.
So double sandbox (Chromium's own low rights sandbox and UAC's elevation sandbox).

When I use virtual PC on Windows 7 host and let host hibernate, switching to the virtual XP-mode only takes about two seconds to run a fully virtualised environment. Chrome and IE have no advantage to other browsers when used in XP, because low integrity level was introduced in Vista. So when you run admin, breaking out browser offers access to the virtual machine. The nice thing of SBIE on X is (as you also have found out) is that it removes all rights and runs the sandboxed proces as untrusted/anonymous user. So SBIE creates a container using OS-mechanisms and protects the virtua machine against the Chrome browser (using PPAPI flashplayer version). Again two complementary sandboxes.

 

Which proves this exploit that you desribed was contained inside SBIE4, exploit did not touch anything outside SBIE4.

 

If you're going to be using VM technology (as in XP mode), why not run Chrome/Chromium under Linux inside a VM, and revert to snapshot when done? I use Sandboxie with Chrome on my W7x64 host without many issues, but for normal browsing, I'm not using my host at all.

 

OK so you're trying to protect your virtual machines if I'm correct.

No, SBIE does not stop memory corruption, you have to use techniques like the ones EMET/HMPA/MBAE are using to defeat exploits. But if malware is able to run inside the sandbox, it will be limited in what it can do.

Yes good point, but protection against keyloggers should be standard inside the sandbox, this is something that can be improved in SBIE. But it's really a weird problem, if the testing tool is sandboxed, SSM can only stop it from reading keystrokes from other sandboxed processes, this does not make any sense.

 

I kind of disagree with you Rasheed about Sandboxie doing more than what it does now against keyloggers. Sandboxie is not an anti keylogger and I hope it doesn't become one. I like Sandboxie to remain being what it is now, the application sandbox per excellence. Nothing more.

By the way, I wrote my previous post so you know that SBIE does work very well in XP. Of my two computers, XP and W7, the XP is the one that I go hard at it. Other than the minor stuff that I mentioned, everything else is pretty much perfect. I recommend you keep using Sandboxie in your XP. If something dont work well along SBIE in your XP, then its probably a conflict. I agree about the "this does not make any sense comment." That smells to me as the result of a conflict.

When I tested the tool yesterday, 1. I ran the tool in a sandbox where programs running are blocked from having access to personal files and folders, 2. I opened two Word files out of the sandbox, one of those Word files is set as blocked and the other one is inside a folder that I have it blocked. The tool did not read nothing. To make sure the tool was working, I also wrote in another file that I have not set to be blocked, the tool was able to log what I wrote on that one. I tested the tool in W7.

Bo

 

Sorry, but no, you're so wrong in this case, by own words of Curt:
Sandboxie blocks exploits from affecting the host by containing them inside the sandbox.
Memory corruption that you talk about all the time is present inside SBIE4's sandbox environment/sandboxed/virtualized Windows system, memory corruption never gets out of SBIE4's sandbox environment/system, that's a key difference, there is no memory corruption of the real Windows system because it never gets out of sandbox, if memory corruption actually did truly happened outside SBIE4's sandboxed environment/sandboxed Windows system, anyone's computer's security/the security of any real Windows system would already be compromised, the damage of any exploit would already be done, before any form of malware tries to execute itself to do additional damage.

SBIE4 blocks keyloggers by using/configuring Internet access restrictions and start/run restrictions to block all sensitive files/documents/processes and etc., however, you have to manually configure it.

 

I do not see how it would be a bad thing if SBIE could protect against key-loggers out of the box. Remember BufferZone and SafeSpace? They both offered anti-logging features. But yes, with some extra configuration you can make SBIE block exploits/payloads and info stealers.

About the problems (I often get the "Cannot mount registry hive" error), it's a bit weird because SBIE is marked as "trusted" and my HIPS do not seem to block anything. It might also be because SBIE v4 is officially not compatible with WinXP SP2. I also do not understand why SSM can not stop key-logging, but perhaps it has something to do with the new SBIE design. But overall it does the job.

 

I think you're misunderstanding me. I actually agree with Curt from Invincea, but the point is that SBIE does not stop the exploit itself. It will however stop or contain the malware.

To make it more clear:

Exploit = memory corruption (stage 1)
Payload = malware (stage 2)

Only specialized anti-exploit tools (like EMET/MBAE/HMPA) can stop stage 1 attacks. Apps like SBIE, AppGuard and EXE Radar can only stop the attack in stage 2, which is good enough most of the time. But in theory it's better to stop the attack in stage 1:

https://blog.malwarebytes.org/exploits-2/2014/09/fileless-infections-from-exploit-kit-an-overview/

 

Version 4.02 Service Pack 3 is required for use on Windows XP.

Detecting Key Loggers

Note two caveats:

• The Internet access feature is neither a replacement for a proper firewall, nor was it designed
as a mechanism to counter or hinder key-loggers.

• Some key-loggers could possibly circumvent the Internet access restriction by hijacking the Web
browser to be used as a vehicle through which to send out the recorded information.

http://www.sandboxie.com/index.php?DetectingKeyLoggers

 

Sure, however the narrator even admits the Flash version is outdated. All in all, it looks like an advertisement for the merits of their Malwarebytes product. Maybe just keeping Flash and plugins/extensions up to date, use a browser other than IE, and using a javascript blocker is all that's needed. I'm not convinced apps like SBIE, AppGuard and EXE Radar are required to stop the advanced type of attack.

 

I like your concise summary of the difference between exploit prevention and containment.

I agree that stopping an attack at Stage 1 is preferable. The earlier an attack can be prevented, the less chance there is for damage, so focusing on Stage 1 prevention is clearly a smart thing to do. To be effective, Stage 1 relies on detection of an attack, so it is good to have Stage 2 in reserve in case Stage 1 misses.

Stage 2 aims at preventing a permanent infection of the system, either by isolation (virtualization) or by policy restriction. Stage 2 doesn't depend on detection, quite the opposite. The whole point of Stage 2 is to contain an already infected running process and prevent it from permanently infecting the system.

To my way of thinking, Stage 1 and Stage 2 are complementary approaches that are best used together (I use both). One of the great things about Sandboxie is that it has policy restriction features in addition to sandboxing for Stage 2 containment.

 

To add to the replies above, and trying to delineate what Sandboxie is and isn't, and how it fits in with a suite of defences, I worry about the data exfiltration/Cryptolocker-type problem, which, assuming there is an exploit (Stage 1 above), may render all your data visible to the user available to user-mode malware (no escalation necessarily required).

One of the really nice features of Sandboxie is the FileAccess controls, which allow substantial restrictions of what any malware could "see". So, for example, in a media player, there is no reason at all for anything running associated with that to be able to have access to anything but your media library and its own database and settings. Similarly for email readers and browsers, they do NOT need direct access to your scanned bank statements, even inside the sandbox! Combining this with applicable internet restrictions offers a useful set of controls on a per-application basis.

Sandboxie is the only tool available that I know about that offers this form of Disk Firewalling control on Windows on a per application configurable basis. I'd like to see more utilities which provided that form of MAC associated with an encrypted filesystem (as Dekart Private disk does, but not granularly). The problem with conventional disk encryption such as Truecrypt is that once you've mounted a drive, all the data is open all the time to any user-space program.

 

I agree. I don't know of any other application either that offers the degree of granularity in specifying file access restrictions on a per-application basis that Sandboxie has.

 

You know that despite Sandboxie not being an anti keylogger, the program offers excellent protection against keyloggers through the use of restrictions (Internet/Start/Run) and WriteFilePath and ClosedFilePath settings.

To do more than that, Sandboxie would have to become a detection tool. And then the program would become bloated and conflicts with other security programs would increase. Not good. The sandbox works great as it is now, I want it to stay that way.

Bo

 

Exactly, remember how returnil started out light and minimal resourse using, doing the one job and ended up heavy and bloated with a third rate AV onboard.

Regards Eck

 

The same was said for such exploits as well, but yet SBIE4 is able to contain them as well.

 

Yes of course it's an advertisement, but I don't see anything wrong with that. Fact of the matter is, they can stop this attack, while others can't. The question is how real this threat is to home user PC's. The thing about "memory-only" payloads is that they can easily be stopped by closing the browser (or other exploited app) or by system reboot.

But most malware wants to permanently infect the machine, and then you need a regular "disk based" payload. I'm not sure if ransomware and banking trojans can infect the machines directly from memory. But I wouldn't be surprised if "memory-only" malware is being used by skilled hackers who are trying to hack corporate PC's and governments.

 

Yes exactly, and that's why MBAE and HMPA have implemented both type of protections, this is something that EMET lacks. Actually, now that I think of it, there's even a "stage 3". In stage 1 you try to prevent the exploit, in stage 2 you try to block the payload from running, and in stage 3 you try to contain the malware that is running on the system. It's in stage 3 where HIPS/sandboxing comes into play, it will simply try to stop malware from performing dangerous activities.

 

Yes I know, that's why I'm glad that it's running just fine on Win XP SP2.

I have done a couple of tests, and virtualization is working just fine + all apps are stripped from admin privileges. However, the fact that keylog-testing tools can read keystrokes from apps OUTSIDE the sandbox is a bug I think. I'm not sure if the bug is inside SBIE, or if it's caused by some conflict. Perhaps some of you can try it on Win 7/8, you can use these testing tools (use only the "LowLevel" and "JournalRecord" hook test in AKLT).

http://www.snapfiles.com/get/antikeyloggertester.html
http://www.snapfiles.com/get/stt.html

 

My security approach is exactly what you wrote in the comment above. And I know it works for me. All I have been using for security for a long time is Sandboxie and NoScript. I started using both programs at about the same time about 6 years ago. I hardly ever get to see a SBIE message telling me that something that's not allowed to run or connect is trying to do so. The few rare occasions when that has happened is some very liitle used Windows exe that' tries to run. I cant recall at any time seeing an exe that tries to run that after searching Google about it, I suspect it was malware. I believe this is due to what you wrote, using as few plugins and addons as possible and most of the credit belonging to NoScript.

Bo

 

Yeah, you should be glad because Sandboxie latest versions should not be working in XP SP2.

If you block access to folders or files in sandbox settings, keyloggers should not read key strokes. I tested the tool that you posted a link to the other day and that's what I found in my W7. I ll test the tool in my XP SP3 in a few hours when I am using that computer.

Bo

 

Yes I know what you mean, but it depends on the design, it does not have to become bloated. It would also be smart from a marketing point of view, to offer some stuff "out of the box" which can also be turned off.

On the other hand it's not a big deal because most HIPS can actually monitor apps that are running "sandboxed" + with the "restrictions" and "resources access" feature you can already block most attacks. Perhaps an idea to offer a Sandboxie "Extreme" version which has some capabilities from Invincea FreeSpace, like the ability to see exactly how an app behaves inside the sandbox.

http://www.invincea.com/how-it-works/detection/
http://www.invincea.com/2014/08/fake-bbc-finance-site-delivers-proxy-crimeware-and-rootkit/