Sandboxie technical tests and other technical topics discussion thread

This thread is intended for a discussion of technical Sandboxie topics, including technical tests. The thread for Sandboxie updates and other Sandboxie topics is here.

This first post discusses a test of code injection within a sandboxed program.

One can test some proofs of concept that mimic real malware (but aren't malware) on Windows XP with the code from book "Practical Malware Analysis" at hxxp://practicalmalwareanalysis.com/labs/.

Here's a test I did of one of the "Practical Malware Analysis" files on a Windows XP SP3 virtual machine with Sandboxie 4.12 (all default settings):
1. Ran TCPView unsandboxed.
2. Ran sandboxed file Lab19-02.exe. (This mimics what could happen if you got hit by an exploit).

Lab19-02.exe launches two instances of Internet Explorer (iexplore.exe) sandboxed and injects code into one (or both?) of the instances. Network activity for the sandboxed iexplore.exe is shown in TCPView. iexplore.exe attempts to connect to local network IP address 192.168.200.2 on TCP port 13330. If it connects, a remote shell is established. I used Hercules on a different virtual machine with IP address 192.168.200.2 to listen to port 13330. A remote shell was indeed established. I used some commands like "dir" in Hercules which were sent to the "victimized" virtual machine and executed in a sandboxed cmd.exe; the command results from the "victimized" virtual machine were sent back to Hercules for display.

 

A question from Rasheed187: "Isn't SBIE supposed to block code-injection, even if both apps are running inside the sandbox?"

I could be mistaken, but I believe that Sandboxie blocks code injection into unsandboxed processes, but (with default settings) not sandboxed processes within the same sandbox. Another of the files from "Practical Malware Analysis" tests code injection into an unsandboxed process; I forgot which file tests this, but I will check if anyone wants me to.

 

Invincea vs. Emet 5.0 (against exploits):
http://www.invincea.com/why-invincea/microsoft-emet-comparison/
http://www.invincea.com/wp-content/...ech-Comparison-vs-Microsoft-EMET_Sept2014.pdf

 

Thank you so much for doing this work, and the separate thread is a great idea.

 

I tested code injection from a sandboxed process into an existing unsandboxed process using file Lab12-01.exe from the book mentioned in post #1. Sandboxie 4.12 with default settings was used in a Windows XP x86 SP3 virtual machine.

If run unsandboxed, Lab12-01.exe injects code into explorer.exe that causes explorer.exe to display a message box every minute.

If Lab12-01.exe is run sandboxed, there are no message boxes displayed, so I assume that code injection failed from the sandboxed Lab12-01.exe into the existing unsandboxed explorer.exe.

-----------

@deBoetie: you're welcome .

 

Some keylogging-related links:

Keylogging test of Anti-Keylogger Tester 3.0 vs. typing into Notepad

Detecting Key Loggers

tzuk's view on testing keyloggers with Sandboxie: see post #11 in this thread.

----------

Some exploit-related links:

Buffer Overflow Protection?

Test of a memory corruption exploit

DLL & Script Execution blocking

Fileless Infections from Exploit Kit: An Overview

 

Good idea to open a new thread. It would be surprising to me if SBIE does not block code injection inside the sandbox, because there's always some risk involved with it.

Thanks for posting. I would really like to see some of the stuff from Invincea FreeSpace implemented in SBIE.

 

If it did, legitimate uses would also be blocked.

 

Yes might be another design choice, just like SBIE not blocking "low level keyboard hooks". The good news is that there is always HIPS who can give you extra control over sandboxed apps.

 

Also, Sandboxie doesn't use anti-exploit methods like those of EMET to try to prevent shellcode execution in an exploited goodware process, although various Sandboxie non-default restrictions in some cases can block execution or behavior.

 

Not in some cases, in all cases. Tzuk and Curt know this better than you (yes, it's called containment), obviously.

 

Containment isn't the same as data leakage blockage. Containment means malware acquired in a sandbox isn't there anymore when sandboxed activity is stopped and a sandbox is emptied. From http://www.sandboxie.com/index.php?DetectingKeyLoggers (my bolding):

 

Start/run restrictions and internet access restrictions take care of that.

 

Yes, in some but not all cases. Consider this scenario. Your system is clean. You're using a sandboxed browser, which presumably you won't be restricting with internet access restrictions (right?). While browsing, your browser is exploited with a fileless keylogger. The keylogger is now running inside the sandboxed browser process itself (start/run restrictions won't stop this, right?).

 

How sure are you that fileless keylogger won't be stopped by start/run restrictions (hopefully, these are not some bald statements without irrfeutable real-world evidences)?
And even if this is the case, than what is there any protection against this?

 

If the sandboxed shellcode starts a new process, start/run restrictions could block that. If the sandboxed shellcode loads more malware within the exploited goodware process, start/run restrictions by itself won't stop that. If the sandboxed shellcode tries to insert code into an existing unsandboxed process, I believe Sandboxie should block that.

 

But, than you cannot say that SBIE4 would be just powerless, there is a plenty what it can do, plus it can block dll injections as well, but you have to configure it manually, which dlls you want to block!
Maybe it wouldn't be able to block malware inside exploited goodware process, but these fileless memory-based malwares won't be able to much anything further, since it has to coomunicate with applications/processes inside and outside the sandbox/insert codes sooner or later on the applications, processes, executables and etc. inside SBIE4's sandbox environment and the very moment these fileless, memory malwares try to insert codes into anything inside or outside sandbox it will be completely stopped by internet access restrictions and start/run restrictions!
The problem is which dlls are simply unblockable in the operating system?
kernel32.dll comes to my mind, since it is a driver-I'm not sure, however, maybe, I'm not sure about this.

 

I agree. That's why I used the word "some" instead of "all."

 

As an example, here is an analysis of an in-memory exploit of a goodware process.

 

a) Anti-exploit software like EMET can stop some (but not all) exploits.
b) Stop all sandboxed processes, empty all sandboxes would normally get rid of malware acquired in a sandbox.

 

It's the goodware process itself that has the shellcode running; it's not a separate .exe. If the goodware process needs internet access to function, you wouldn't have used internet access restrictions on that program, right?

 

Basically, I would have to terminate firefox.exe or iexplore.exe or chrome.exe to completely shut down exploited browser/goodware process, right-if I understood it right?

 

Lets say your scenario above takes place, And one of my plugins get exploited.

The problem with your scenario regarding Sandboxie is that you forgot something:

You can allow plugins to run in the sandbox and at the same time keep them from phoning home. Thats the beauty about Sandboxie and you keep ignoring it. In my personal case, the only plugin that I use is Flash and Flash is not allowed internet access. That takes care of that little problem that you wrote above. No big deal for Sandboxie.

Bo

 

Right. In general, I believe this is sufficient (assuming you didn't run into something more exotic like a kernel-mode exploit) to stop any sandboxed keyloggers:
1. Stop all processes running inside of all sandboxes. (A keylogger has to run to keylog.)
2. For any sandboxes that have processes that might start sandboxed while you're doing your sensitive activities, those sandboxes should be emptied to get rid of acquired malware.

 

If the exploited plugin doesn't need internet access and runs in a separate process from the browser, then internet access restrictions can be used for the plugin process.

If processes that need internet access are exploited, then you wouldn't have been restricting those processes with internet access restrictions, right?

P.S. Your Adobe Flash doesn't need internet access?