Sandboxie4 vs. Angler Exploit Kit...

[Lumberjack]

I just saw this on Wilder security forums...
Supposedly, according to ZeroVulnlabs, recently Angler Exploit Kit started using memory-only payloads which makes the whole anti-exe/HIPS/AV approach that focuses on the malicious binary moot from the exploit detection perspective.

http://www.wilderssecurity.com/threads/ ... st-2411698
http://malware.dontneedcoffee.com/2014/ ... eless.html

Does SBIE4 have any kind of mechanisms to block/protect against such exploits, or do I need something to back it up for protection against all of these so-called memory-only payloads?
Big thanks in advance.

[Lumberjack]

Also, does Sandboxie4 block/prevent these exploits as well:
http://malware.dontneedcoffee.com/2014/ ... /mbae.html

Curt said that no security software can protect against kernel-level exploits.
But what about: privilege escalation exploits, OS exploits, buffer overflow exploits, memory exploits and all other forms of exploits?

[Curt@invincea]

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.

[Lumberjack]

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.

Ok, thanks, but what about that Duqu malware, if I remember correctly it was using True type font vulnerability of win32k.sys and t2embed.dll.
Now you said that Sandboxie4, even when tightly configured to prevent/block win32k.sys, it will not protect against this exploit/vulnerability, but if you block with Sandboxie4 configuration t2embed.dll vulnerability/exploit will Sandboxie4 at least partially protect against this t2embed.dll vulnerability and prevent execution of Duqu malware (when SBIE4 is tightly configured to prevent/block this and everything else)?
Sorry, for asking this, again, but I don't know enough about t2embed.dll and win32k.sys-yes, I know with my Windows 8.1 system everything is patched, and the story is over, but I only want to clear this out once and for all what was true about Duqu malware and what is true about SBIE4 protection mechanism against these exploits and Duqu malware and its newer variants.

[Curt@invincea]

1) You can't block win32k.sys with Sandboxie.
2) MS did say that a workaround to prevent Duqu (and other True Type font vulnerabilities) was to remove access to t2embed.dll. So, you could have done the same with Sandboxie (by blocking t2embed.dll) -- if you had known to do it.

[Lumberjack]

1) You can't block win32k.sys with Sandboxie.
2) MS did say that a workaround to prevent Duqu (and other True Type font vulnerabilities) was to remove access to t2embed.dll. So, you could have done the same with Sandboxie (by blocking t2embed.dll) -- if you had known to do it.

To be honest I'm still looking one exploit that has bypassed SBIE4, so far I didn't see it, at least, not when it comes to real test, not some proof-of-concept.
I'm sure you will confirm that, to this day, there have not been any kind of exploits that have actually bypassed SBIE4's protection mechanisms/prevention/blocking, as someone who actually knows how SBIE4 works.

[Lumberjack]

1) You can't block win32k.sys with Sandboxie.
2) MS did say that a workaround to prevent Duqu (and other True Type font vulnerabilities) was to remove access to t2embed.dll. So, you could have done the same with Sandboxie (by blocking t2embed.dll) -- if you had known to do it.

Hi, Curt, I truly apologize for being so painful about these questions, but here is one question that still tortures me this post is a copy from an poster called FleishmannTV on malwaretips.com:
http://malwaretips.com/threads/sandboxi ... ost-219387

Here it is what he said about Sandboxie and exploits:
"For example, I think Sandboxie wouldn't have protected you against something like the FBI exploit for the Tor browser, because in that case start/run- and internet access restrictions/closed IPC paths/stopping code injection into other processes wouldn't have helped, as it was all happening inside the browser process."

Is this true, is it true that SBIE4 cannot protect against these forms of exploits?

So, SBIE4 does not prevent/block exploits, but does contain them all forms of exploits?
Does it mean that by "contain" means it actually isolates all forms of exploits from the real Windows system?

What about protection against installation of malicious add-ons?
Big thanks again.

[Lumberjack]

1) You can't block win32k.sys with Sandboxie.
2) MS did say that a workaround to prevent Duqu (and other True Type font vulnerabilities) was to remove access to t2embed.dll. So, you could have done the same with Sandboxie (by blocking t2embed.dll) -- if you had known to do it.

Is the following true about Sandboxie4?
The poster names Windows_Security/Kees1958 has written the following:
"On my Win7 ultimate I use Chrome locked down through GPO. With these templates I only allow the plug-ins and add-ons I explicitely allow (like the admin allowed plug-ins/add-ons in IE). Point is on Win7 the broker runs in Medium Integrity Level, while under SBIE4 itself runs in System/HIGH. When malware breaks out ol LOW-IL, I rather have it nibbling at a Medium Level processes than HIGH/System processes. But then again this "IL-level access" and "adding attack surface" is all theoretical talk."

So, are bold statements true or false?
Does Sandboxie4 itself truly run on system/high-integrity level, while Chrome runs on only medium integrity level, which means it's better and actually more secure to run Chrome outside Sandboxie4, than inside Sandboxie4, only because of these integrity levels, what do you think, Curt, what is true and what is false here?
Big, big thanks in advance, Curt.
After all, WS does admit these statements about integrity levels and "adding attack surface" is all theoretical talk, it's nothing proven in every day programming/practice.

[Curt@invincea]

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"),

"SBIE4 itself runs in System/HIGH. " doesn't make any sense. The service runs as System, but that is not Sbie "itself". What matters are sandboxed apps, and they all run at untrusted integrity under Anonymous Logon with almost zero rights in the host system. That's about as restricted as you can get and still execute.

So what does this user do to safely run any webmail attachments or other downloaded executables?

[Curt@invincea]

1) You can't block win32k.sys with Sandboxie.
2) MS did say that a workaround to prevent Duqu (and other True Type font vulnerabilities) was to remove access to t2embed.dll. So, you could have done the same with Sandboxie (by blocking t2embed.dll) -- if you had known to do it.

To be honest I'm still looking one exploit that has bypassed SBIE4, so far I didn't see it, at least, not when it comes to real test, not some proof-of-concept.
I'm sure you will confirm that, to this day, there have not been any kind of exploits that have actually bypassed SBIE4's protection mechanisms/prevention/blocking, as someone who actually knows how SBIE4 works.

AFAIK, Sandboxie has not had a successful bypass in the real world. There have been several bypasses discovered, discussed in this forum, and fixed. But, these were never successfully exploited in the wild.

[bo.elam]

What about protection against installation of malicious add-ons?

If you install a malicious addon while running sandboxed, the infection is gone when you delete the sandbox. If you install a malicious addon outside the sandbox, you are infected. I am extremely careful about the addons that I use. And install as few as possible.

Bo

[Lumberjack]

1) You can't block win32k.sys with Sandboxie.
2) MS did say that a workaround to prevent Duqu (and other True Type font vulnerabilities) was to remove access to t2embed.dll. So, you could have done the same with Sandboxie (by blocking t2embed.dll) -- if you had known to do it.

To be honest I'm still looking one exploit that has bypassed SBIE4, so far I didn't see it, at least, not when it comes to real test, not some proof-of-concept.
I'm sure you will confirm that, to this day, there have not been any kind of exploits that have actually bypassed SBIE4's protection mechanisms/prevention/blocking, as someone who actually knows how SBIE4 works.

AFAIK, Sandboxie has not had a successful bypass in the real world. There have been several bypasses discovered, discussed in this forum, and fixed. But, these were never successfully exploited in the wild.

Thanks for the info, but if I might ask what is the difference between blocking exploits and containing exploits: this guy on Wilders security forums claims this:
"The way that I see it is that SBIE is not designed to block exploits. So he probably means that if some sandboxed process is exploited by malware, it should be able to contain the malware. But it does not stop the exploit (memory corruption) itself."

Now, basically there is a huge difference between containing something and blocking something like memory corruption, than the other guy answered him the following:
"Sure, it does not block them but if they are contained inside SBIE than all that memory corruption is under SBIE4's supervision, and there is not a single harm on the real Windows system, and I'm not talking about just malware, but also memory corruption, the real system memory is untouched, that's the point of containing something, that's a key difference."

Now what is here true and what is here false?
That's all, big thanks in advance.

[Curt@invincea]

Sandboxie blocks exploits from affecting the host by containing them in the sandbox.

[Lumberjack]

Sandboxie blocks exploits from affecting the host by containing them in the sandbox.

OK, but does that mean that memory corruption caused by exploits is also 100% contained inside SBIE4, so that memory corruption never touches/can never touch the real Windows system?
Basically memory is corrupted only inside the SBIE4's sandbox, not outside the SBIE4's sandbox-that's a key difference.

[Lumberjack]

Sandboxie blocks exploits from affecting the host by containing them in the sandbox.

Quick question if Sandboxie 4.12/beta 4.13.5 Alpha can fully protect against the following on Sandboxie FAQ I read this:
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

Also, what about that test from snapfiles and spyshelter test tool:
http://www.snapfiles.com/get/antikeyloggertester.html
http://www.snapfiles.com/get/stt.html

Here is what Mr. Brian wrote here about these keyloggers that can and will bypass (supposedly) Sandboxie4:
"Consider this scenario. Your system is clean. You're using a sandboxed browser. You browse a website and Angler exploits a vulnerability. The malware is now running inside the sandboxed browser process itself (start/run restrictions won't stop this, right?). Let's suppose the malware is a keylogger. Now you type some stuff into a word processing document that's not sandboxed. The keylogger running in the browser process could potentially log the keystrokes you typed into the word processing document and exfiltrate that data via the browser process (internet access restrictions won't stop this, right?). Now you close the sandboxed browser and empty the sandbox. The malware is now gone, but the data exfiltration can't be undone."

Is all of this true?
Also, please take a look at this:
http://www.securityweek.com/malware-inj ... kit-attack
In this scenario, the keylogging malware is running within a browser process; Internet access restrictions and 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.
Is this true?

And also, against what form of keyloggers, even super-tightly configured SBIE4 cannot protect at all? Do I need an anti-keylogger, for extra security?

And what about shellcode attacks, and what about memory buffer overflow attacks, how and does Sandboxie 4.12/4.13.5 protect against these attacks and do I need an additional security option for protection against these attacks?

What about situations 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 - http://www.nologin.org/Downloads/Papers ... ection.pdf) and Reflective DLL Injection (paper - http://www.harmonysecurity.com/files/HS ... ection.pdf).

And here is the link to the keylogger test which supposedly proves that tightly configured Sandboxie 4.12 with Internet access restrictions and start/run restrictions will fail to protect against these forms of keyloggers:
http://www.wilderssecurity.com/threads/ ... st-2415096
What do you think, Curt?
Big thanks in advance.