Sandboxie technical tests and other technical topics discussion thread

I did this:

Opened Command Prompt sandboxed
In sandboxed Command Prompt, typed:
copy con: c:\windows\system32\drivers\etc\hosts <enter>
127.0.0.1 www.facebook.com <CTRL+Z> <enter>
Answered 'y' to the file overwrite prompt.

Then tried browsing www.facebook.com in sandboxed (same sandbox) Internet Explorer.
www.facebook.com was available. So the changed hosts file was not used.

 

Yes, but for outbound access and execution control, I prefer third party apps. It's too much fine tuning for me, to restrict sandboxes when it comes to this. Of course I do use SBIE's file access protection.

 

I recommend testing to be sure that access control restrictions that you care about are enforced within a sandbox.

Example: unsandboxed, in Windows 7 an attempt to delete c:\windows\regedit.exe in Windows Explorer fails ("You require permission from TrustedInstaller to make changes to this file"). Sandboxed, the same file can be virtually deleted.

 

Again you have to allow command prompt Start/Run Access in Sandboxie (that's controlled)

Went through with the test anyway and allowed sandboxed command prompt.
Results:
Access is denied, 0 file(s) copied

 

I think the differences are because I am using default Sandboxie settings. Also, some people do run dodgy programs sandboxed intentionally.

 

Hardly ever use default settings on any security software I use. If it's available I rachet it up and though I've
tested malware in Sandboxie I don't recommend using it for that purpose. IIRC even the Sandboxie devs don't
recommend doing that.

 

I'm testing it in VirtualBox.

I'm not sure why you see "Access is denied, 0 file(s) copied" but I do not.

 

@Compu KTed: What happens when you delete the hosts file in a sandboxed Windows Explorer?

 

Most malware wont run in a sandbox. Even with default settings. Malware writers are not dumb, if sbie.dll is detected (easy to do), malware goes dormant to fool users into believing their malicious program is safe to be installed out of the sandbox.

Bo

 

I'll get back to you on more testing and using default settings. Right now I'm not setup to do the necessary tests.
Also remember some malware behaves differently in a virtual machine.

 

If you run sandboxed explorer (default settings) and yes you can delete the hosts file,
but again this is within the isolated sandbox environment. The hosts file in real system
is still intact. When you delete entire contents of the sandbox and run sandboxed explorer
again the hosts file will be listed.

Also did same previous test again with a created sandbox (default settings) and ran cmd.exe sandboxed.

Results:
Access is denied, 0 file(s) copied.

 

Woops, I had to think twice before speak. Surely, it is obvious after think about how exactly SBIE work and I was wrong in this respect.

Okay, this is for me new possibility which is so far not discussed enough. First of all, note SBIE automatically block some vital system parameter change. This is officially documented here.
But we don't know what exact things are blocked and what not, so it will be worth digging as this thread is "Sandboxie technical tests and other technical topics discussion thread", right? We might find possible problem which somehow escaped dev's eye or might not.
Anyway, thanks for testing MrBrian & Compu KTed. I tested by myself, and confirmed that I can edit hosts w/out elevation (and I login as LUA; default sandbox setting), and actually this modified hosts take effect! I made my hosts only include 127.0.0.1 a.com and when I accessed a.com via sandboxed IE, I redirected to 127.0.0.1.

BTW, colon after "copy con" is not needed. So,
copy con c:\windows\system32\drivers\etc\hosts<enter>
<type directly via keyboard>127.0.0.1 www.facebook.com<CTRL+Z><enter>

 

You're welcome, and thank you for your test also .

Browsing a.com gives a "Server not found" message in Firefox. Are you (or anyone else reading this) able to achieve hosts file redirection for a functioning website?

 

Another post #792-related test: I tested whether Software Restriction Policies can be turned off for sandboxed processes.

Type this in a sandboxed Command Prompt: reg.exe delete "HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\Safer\CodeIdentifiers" <enter>
Answer "y" to the confirmation prompt.

Result: Software Restriction Policies are removed for any new process in the same sandbox after the above command has been issued.

 

Add that reg key to (ClosedKeyPath) in Sandboxie
Result: Error: Access is denied

Place a SRP for Command Prompt in Windows registry. Run a sandboxed command prompt
(default settings)
Result: Prevented from running by SRP.

 

142395, what you said above appears to be applicable to Software Restriction Policies, and perhaps some other anti-exes. However, for some other anti-exes like AppLocker (on SBIE v3.44), post #845's first paragraph appears to be correct.

 

Since there are many post #792-related tests that could be done, should a separate thread be created for those?

 

Actually, if you look at here:
http://labs.bromium.com/2013/07/23/application-sandboxes-a-pen-testers-perspective/
Bromium Labs mention user mode exploits as well as all other tests mentioned on how much each sandbox is tough against all of those mentioned types of attacks.

Since I already knew they tested SBIE against all types of attacks on default level, I asked Bromium Labs to test Sandboxie with tight restriction that I gave them, and the result was that Sandboxie with proper restrictions was as good as Chrome was-and that was your point in one you posts in long-running debate, you specifically said that properly configured Sandboxie is equally good as Chrome and its sandbox (even when it's tightly configured, I think)-that's all.

The key difference is that Sandboxie also covers protection against all types of malwares as well, against all dlls (dll protection), all exes, inside memory (actually like you said Chrome also has some form of memory protection as well) and similar-again, this all is true, but only when Sandboxie is properly configured-these were the points of my post here.

The only thing I did not understand in that Bromium Labs report is what does N/A for Google Chrome and Adobe Reader X mean, when it comes to testing against all types of attacks shown in that table?

Does N/A mean that Google Chrome and Adobe Reader X have not been tested at all against other types of attacks mentioned in that table (keylogging, remote webcam/MIC access, Clipboard hijack, screen scraping, steal files, network shares access, user-mode exploits, off the shelf exploits)?

N/A means "not applicable", "not available", which means that both Google Chrome and Adobe Reader do not protect against keylogging, remote webcam/MIC access, Clipboard hijack, screen scraping, steal files, network shares access at all-now Sandboxie on default level may not protect at all against all of these forms of attacks (except steal files), but if it is properly configured, Sandboxie than does actually fully protect against all of those mentioned forms of attacks-that's a key difference that Bromium Labs did not mention in their own tests, so I needed to ask them to test Sandboxie with tightest possible configuration, to prove my point, what I was actually saying all the time in all other previous threads as well.
Cheers.

 

Run in both Admin and LUA using a default settings sandbox

Result: Access is denied, 0 file(s) copied

 

Re-reading post #792, I can see how it could be construed as standard vs. admin account, which wasn't my intention.

So I'll restate it:
Whatever type of account (whether it's UAC-protected admin, UAC-less admin, or a standard account) you're using, file and registry write permissions inside a sandbox are more loose than compared to outside the sandbox.

If using a UAC-protected admin account, unsandboxed writes to folders such as c:\, c:\program files, and c:\windows either fail or require a UAC prompt to succeed (absent a UAC bypass method). Using a UAC-protected admin account, sandboxed writes to these same folders succeed without a UAC prompt.

If using a standard account, unsandboxed writes to folders such as c:\, c:\program files, and c:\windows either fail or require a UAC prompt (with admin password). Using a standard account, sandboxed writes to these same folders succeed without a UAC prompt.

 

Exactly. All tests done so far have no effect on the real system. Everything contained within the sandbox and
deleted when session is closed. Default sandbox settings are good, but prefer better/tighter control especially
the browser sandbox since that get's most Internet access. That sandbox would be most restricted.

 

The sandboxed writes are virtualized, unless they are to a file which is later recovered from the sandbox.

There is a confidentiality aspect. Consider this as an example: Suppose you're using default Sandboxie settings, and using either a UAC-protected admin account or a standard account. You view a pdf that exploits a vulnerability. The shellcode running within the pdf viewer tries to download a malware executable and write it to c:\windows and then execute it. Suppose the malware executable sends some information over the internet (i.e. there is a violation of confidentiality). If this pdf is viewed unsandboxed, the exploit will be stopped when it tries to write the malware executable to c:\windows (unless there is a UAC prompt and the user approves it); thus there is no loss of confidentiality. However, if this pdf is viewed sandboxed, the malware executable is written to c:\windows (unless antivirus etc. stops it), the malware executable runs, and thus your confidentiality is violated (unless outbound firewall etc. stops it).