Sandboxie Acquired by Invincea

Please see Malware Injected Directly Into Processes in Angler Exploit Kit Attack. In the scenario that I gave, the keylogging malware is running within a browser process; start/run restrictions wouldn't have stopped that. The browser process needs internet access, so internet access restrictions wouldn't be applied to the browser process, I assume.

 

Running these tests I don't recall seeing any firewall alerts trying to connect.(calling home)
One could also in extreme cases block all network traffic if need be.
I also tried Spyshelter (AntiTest.exe) with Sandboxie with same results-recorded my keystrokes.
Maybe this is more a problem with Windows OS and/or web browser than with Sandboxie.

 

Yes, but in XP Untrusted is lower than Limited User (like a guest user), XP has no LOW rights (Intergity Level), Limited and Untrusted in XP bith are MEDIUM IL.

 

You probably missed my reply about this file-less Angler Exploit kit:
Curt said the following:
"Angler has not crossed our radar screen here. Sandboxie protects against these things because all sandboxed processes run at untrusted integrity under anonymous user login credentials. If they break out of Silverlight (or whatever), they will still be contained in Sandboxie."
This answer is on the very link you posted.
However, even super-tigthly configured SBIE4 fails all of the tests in Spyshelter security tool (I downloaded it and tested all the tests, SBIE4 failed everything/all the tests).
Interesting would be if I was tested AppGuard and DefenseWall, I wonder if they would pass these tests.

However, the keyloggers you're talking about cannot be contained if you mean by that protection against keystrokes inside the browser processes.

 

What about Windows Vista, Windows 7, Windows 8, Windows 8.1; do, in these Windows systems sandboxed applications (that are inside SBIE4), especially like Google Chrome/chrome.exe and all other Chrome's processes, truly run below the integrity level that chrome.exe is running unsandboxed (outside SBIE4's sandbox envinronment)?

 

I meant those cases where a "good" process such as a web browser, PDF reader, etc. has been exploited, and the shellcode has loaded a keylogger into the/a "good" process. In these cases, a "good" process is doing the keylogging. Here are some general methods to accomplish this: Remote DLL Injection (paper - hxxp://www.nologin.org/Downloads/Papers/remote-library-injection.pdf) and Reflective DLL Injection (paper - hxxp://www.harmonysecurity.com/files/HS-P005_ReflectiveDllInjection.pdf).

 

Mr Brian, the wise thing to do when doing sensitive browsing (like banking) is to do it on a fresh browsing session, then after your banking is done, you close the browser. That alone defeats angling kind of malware.

Regarding Sandboxie, you are always assuming something about Sandboxie. Sandboxie has a lot of features that can be used to restrict a sandbox. For example, Start/Run restrictions, Internet restrictions, blocking Resources (like your personal files and folders) and very importantly Drop Rights. Sandboxie doesn't even allow programs in the sandbox to install Services or drivers. All of this things together make it extremely hard for malware to do its thing in the sandbox. And that includes keyloggers.

Drop Rights in Sandboxie is a huge setting. That setting alone keeps malware from installing in the sandbox. You can test it, try to install something in a Sandbox with Drop Rights and you ll see that the installation fails. Most of the times when a potential vulnerability that could affect Sandboxie has been discovered, sandboxes with Drop Rights have been immune. Perhaps Angler exploit kits can be stopped by that setting alone.

This is what Curt said a few days ago about Angler and Sandboxie.

Safe practices are the key to remain clean, Mr Brian. Another safe practice that I follow is that of only installing in my systems plugins that I require in a regular basis. For example, in XP, I have one plugin and in W7, I got none. The chances of me ever shaking hands with angler exploit kits are about 0.

Bo

 

@bo elam: Sandboxie, as far as I know, can never block shellcode from executing; see Buffer overflow - would Sandboxie contain exploit? for example. Various Sandboxie features (as well as non-Sandboxie security features) might or might not block/mitigate/contain later stages after shellcode execution. Others in this thread have demonstrated that a sandboxed keylogger can potentially keylog from unsandboxed processes, if I am not mistaken. I've given a scenario in which a "good" sandboxed process can have a keylogger stuffed into it.

 

i would say that in common - malware can exploit data, keylogging, spying users behavior, sending passwords etc. the only advantage is that it stays in the box until it box is deleted. and in every option where data can be written from inside to outside, eg firefox or chrome profile,... you get it?

 

Mr Brian, a thread from 2010? Please, I thought you are talking about Angler exploit kits. That has nothing to do with that ancient thread. Now, I did not spend hours last night reading about Angler, I spend 20 minutes and as far as I can tell, you don't even need Sandboxie to defeat that thing. All you need is to follow the two safe and wise practices that I mentioned on my previous post while doing sensitive browsing. 1. Keep as few plugins as possible in your computer and 2. Open a fresh browsing session, do your banking and immediately close the browser after you are done. If you are going to bang on Sandboxie regarding Angler, find something related to it. By the way, in case you forgot, Sandboxie version 4 has very little to do with version 3.

Bo.

 

Did you read my earlier post? It's not a "problem", but Tzuk has simply chosen not to block global and window hooks (which is needed for reading keystrokes), because it might cause problems with some apps, so that's why SBIE is not able to stop these type of "anti-logger" tests. HIPS/Anti-logger can protect against this, so no problem.

 

Broma in my language (Spanish) means joke. I am a very serious person and hardly ever joke around or anything like that. But I ll make an exception today and make a serious joke out of the joke (Bromium).

Last month, I read this article about Donald Trump and the sale of the Buffalo Bills. For some reason, when I read the article, everything in the article about Trump just reminded me of Bromium, specially the sentence that goes like this "But if Donald Trump says he did, then Donald Trump did because Donald Trump said so." When I was reading the article, unconsciously, I changed that sentence to something like this "But if Bromium says it is, then it is because Bromium said so."
http://www.cbssports.com/nfl/eye-on...terry-pegula-overpaid-for-bills-because-of-me

Bo

 

Yes correct, but like I said earlier in the thread, it's unclear how dangerous these type of "memory-only" payloads are. But yes, if you want to stop them, you need MBAE/HMPA/EMET, because SBIE won't stop memory corruption.

I don't think Mr Brian is trying to be negative about SBIE, he's just saying that it can not protect against certain threats, at least not with standard settings.

 

As far as the Keylogger testing tools if somone knows the process integrity levels
they are running at and compare that level with your browser that might be helpful.

From what I've read if programs are running under the same integrity level for example
the keylogger tester and browser, then this may be why the keystrokes are being captured.
Windows doesn’t allow objects from a lower integrity level to access objects from a higher
level, thus if the Keylogger tools are set at lower integrity level than the other apps your testing then
keylogger tools are no longer able to capture the users keystrokes.

Curt@invincea (Sandboxie forum) posted:
SbieCtrl.exe runs at medium integrity.
SbieSvc.exe runs at system integrity.
Everything inside the sandbox runs at untrusted integrity (which is lower than "low")

 

Bo, sorry - I have not been following everything in this thread, so my question may have been answered before but just to clarify - are you saying that instead of doing banking in your separate sandbox, you should also ensure that the browser is fresh? I usually have chrome running (sandboxed) for my normal browsing activities. When I want to do some finance work, I open a new instance of chrome in a separate sandbox, finish my banking and then close this browsing session with all contents being deleted. All the while the other chrome session was still running. Is that a weakness?

 

Almost at the end of this webpage, Tzuk tells us ..."But it is still important to first stop all sandboxed activity in all sandboxes, for maximum protection."
http://www.sandboxie.com/index.php?DetectingKeyLoggers#defend

As I understand it, there should be no communication between sandboxes but as he says, for maximum protection, it is safer to only have open the sandbox that you are using for sensitive browsing when you are doing that.

Bo

 

bo, thanks for providing this info

 

True but the Integrity mechanism doesn't enforce read restrictions, or the flow of information in general.

 

@bo elam: The point of that thread is what Rasheed187 notes above. It's still relevant to today's Sandboxie as far as I know.

Rasheed187 is right about my motives. Some people reading this might even appreciate such information.

 

Well, all of this does not change the fact that SBIE4 is vulnerable and cannot protect to keyloggers (the one you mentioned and the ones Mr. Brian mentioned, exploits and malwares within browser processes, memory buffer overflows, shellcode attacks and etc.).
If you are paranoid about that, you should have additional protection mechanisms/software applications as well.

 

Although I'm a Sandboxie/VM/MBAE/HIPS user, for online banking I use the following:

A Puppy Slacko pendrive distribution, fresh and booted on a laptop. Once the OS and browser has loaded into memory, I take the pendrive out. I then browse, only to the bank's website, checking the certificate. Job over, I just shutdown and watch the IO errors as it fails to save the persistent image. I think this only has vulnerabilities in the distribution integrity (which I assume are handled by the repository mechanisms), and in the dns or bank's systems.

If I need to update the pendrive distribution or software, I do so and save back to the pendrive without having done any browsing.

 

Good point, normally the keylogger will run with "medium rights", but in the sandbox it must run with "untrusted rights", so why is it still able to log the whole system? The only thing I can think of is that these restrictions do not apply to "low level hooks", the ones that are used to read keystrokes.

 

I think this approach is good enough to protect against malware. I'm also planning to use a separate sandbox for banking and online shopping. In theory, malware will not be able to infect the browser that is sandboxed, because of the restrictions. For example, no code injection and other interprocess communication is allowed, between apps inside the sandbox and the ones that are outside.

 

Not recommending, but going to extreme measures one can prevent read and write permissions of users through
Security tab of the keylogger test app. Even though Sandboxie allows the Keylogger to write keystrokes through
the browser I'm not totally convinced the info is getting out over the Internet if your browser is set as having "Internet Access" only in Sandboxie. Unless someone can prove otherwise.