Sandboxie technical tests and other technical topics discussion thread

Discussion in 'sandboxing & virtualization' started by MrBrian, Oct 17, 2014.

  1. MrBrian

    MrBrian Registered Member

    Joined:
    Feb 24, 2008
    Posts:
    6,032
    Location:
    USA
    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.
     
    Last edited: Oct 17, 2014
  2. MrBrian

    MrBrian Registered Member

    Joined:
    Feb 24, 2008
    Posts:
    6,032
    Location:
    USA
    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.
     
    Last edited: Oct 17, 2014
  3. CoolWebSearch

    CoolWebSearch Registered Member

    Joined:
    Sep 30, 2007
    Posts:
    1,217
    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
     
  4. deBoetie

    deBoetie Registered Member

    Joined:
    Aug 7, 2013
    Posts:
    1,150
    Location:
    UK
    Thank you so much for doing this work, and the separate thread is a great idea.
     
  5. MrBrian

    MrBrian Registered Member

    Joined:
    Feb 24, 2008
    Posts:
    6,032
    Location:
    USA
    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 :).
     
  6. MrBrian

    MrBrian Registered Member

    Joined:
    Feb 24, 2008
    Posts:
    6,032
    Location:
    USA
  7. Rasheed187

    Rasheed187 Registered Member

    Joined:
    Jul 10, 2004
    Posts:
    8,046
    Location:
    The Netherlands
    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.
     
  8. MrBrian

    MrBrian Registered Member

    Joined:
    Feb 24, 2008
    Posts:
    6,032
    Location:
    USA
    If it did, legitimate uses would also be blocked.
     
  9. Rasheed187

    Rasheed187 Registered Member

    Joined:
    Jul 10, 2004
    Posts:
    8,046
    Location:
    The Netherlands
    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.
     
  10. MrBrian

    MrBrian Registered Member

    Joined:
    Feb 24, 2008
    Posts:
    6,032
    Location:
    USA
    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.
     
    Last edited: Oct 17, 2014
  11. CoolWebSearch

    CoolWebSearch Registered Member

    Joined:
    Sep 30, 2007
    Posts:
    1,217
    Not in some cases, in all cases. Tzuk and Curt know this better than you (yes, it's called containment), obviously.
     
  12. MrBrian

    MrBrian Registered Member

    Joined:
    Feb 24, 2008
    Posts:
    6,032
    Location:
    USA
    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):
     
  13. CoolWebSearch

    CoolWebSearch Registered Member

    Joined:
    Sep 30, 2007
    Posts:
    1,217
    Start/run restrictions and internet access restrictions take care of that.
     
  14. MrBrian

    MrBrian Registered Member

    Joined:
    Feb 24, 2008
    Posts:
    6,032
    Location:
    USA
    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?).
     
  15. CoolWebSearch

    CoolWebSearch Registered Member

    Joined:
    Sep 30, 2007
    Posts:
    1,217
    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?
     
  16. MrBrian

    MrBrian Registered Member

    Joined:
    Feb 24, 2008
    Posts:
    6,032
    Location:
    USA
    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.
     
  17. CoolWebSearch

    CoolWebSearch Registered Member

    Joined:
    Sep 30, 2007
    Posts:
    1,217
    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.
     
    Last edited: Oct 17, 2014
  18. MrBrian

    MrBrian Registered Member

    Joined:
    Feb 24, 2008
    Posts:
    6,032
    Location:
    USA
    I agree. That's why I used the word "some" instead of "all."
     
  19. MrBrian

    MrBrian Registered Member

    Joined:
    Feb 24, 2008
    Posts:
    6,032
    Location:
    USA
    As an example, here is an analysis of an in-memory exploit of a goodware process.
     
  20. MrBrian

    MrBrian Registered Member

    Joined:
    Feb 24, 2008
    Posts:
    6,032
    Location:
    USA
    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.
     
  21. MrBrian

    MrBrian Registered Member

    Joined:
    Feb 24, 2008
    Posts:
    6,032
    Location:
    USA
    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?
     
  22. CoolWebSearch

    CoolWebSearch Registered Member

    Joined:
    Sep 30, 2007
    Posts:
    1,217
    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?
     
  23. bo elam

    bo elam Registered Member

    Joined:
    Jun 15, 2010
    Posts:
    3,770
    Location:
    Nicaragua
    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
     
  24. MrBrian

    MrBrian Registered Member

    Joined:
    Feb 24, 2008
    Posts:
    6,032
    Location:
    USA
    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.
     
  25. MrBrian

    MrBrian Registered Member

    Joined:
    Feb 24, 2008
    Posts:
    6,032
    Location:
    USA
    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?
     
Loading...