Cybergenic Shade-sandbox tool

No sorry but there is nothing to check, have you seen the linked articles, a process can always write into its own address space hence it can always bypass any user mode hooks.


They have implemented it this way because there is simply no way to reliably protect those resources in 64 bit windows, except through using a restricted process token. The caveat with using a restricted process token like sandboxie does is that it breaks pretty much everything so almost no regular application can successfully run under such conditions.
What sandboxie does to cope with this situation is it implements a butt load of workarounds and call proxies and emulated API implementations, plus it uses unexported kernel functions and is messing with undocumented kernel structures to do its process token wizardry.




Look sure one can try to mitigate this issue, but nothing that can be done to protect a user mode hook is really robust.
The problem is not just that you can't to protect a given memory page from being altered by the offending process. If it would be just that one could may be think of something. But the problem is bigger, you see what these hooks ultimately do is to place themselves some ware between a API call of a system library and a syscall invocation to the kernel. Such a syscall is no magic and is nothing special any application can completely bypass system libraries and issue syscalls directly to the kernel. Now normally this is not done because MSFT is changing syscall numbers between larger builds so if an application wants to do its own syscalls it must check the kernel version and have a list of indexes, also it wont be able to operate on any newer/unknown version of the system, but that's a practical limitation not a fundamental one, you just need to keep your malware up to date.
So if we want to protect memory pages which contains our user mode hooks we would use for the NtProtectVirtualMemory syscall and of cause hook that function in the ntdll to. So that a process when it attempts to change memory protection on some memory, will first go through our hook that will deny access to pages we have hooks on.
But than the malware author will just implement an own MyProtectVirtualMemory function (or MyVirtualAllocEx) independent from the ntdll which issues a syscall to the kernel directly requesting the change in protection and the kernel will oblige, there are no callbacks in the kernel to my knowledge which would allow a driver to filter such requests.

Now at this point the magnitude of the issue becomes really apparent, protecting our hooks is not the primary issue at hand, preventing an application from executing own rogue syscall's directly is. And that's if not entirely impossible pretty much entirely impractical. You see a syscall is just a CPU instruction, so we can not hook it. If we really want to block it we need to ensure there will never be a sequence of bytes in executable memory of a given process which is a syscall.

To not go to much into details here, in the end it boils down to if we can ensure any application that runs within the supervision of the product will never have memory pages marked as executable and writable at the same time, which admittedly would be good practice but often is not the case. So eider we opt to break any application that requires this like possibly many script engines which generate machine code for better performance, various copy protection and obfuscation schemes, and others...
Or we could in theory go with never making memory executable and writable at the same time, even if that's being requested, attach a debugger to the application to catch all memory access violations and than eider set the memory writable and remove the executable flag, or vice versa first scanning it for syscall code and resume execution each time such a situation arises. This is quite impractical, plus it will still break many copy protection schemes as they don't like running under a debugger.



Its simply more and more afford for a diminishing return security wise, given that a lot of malware is not that advanced, in the end these companies are selling a product, it just has to be good enough, cheep to maintain and sound great in the marketing materials.
So it does not have to be flawless, and there is the possibility of some windows 0 day vulnerability through some unprivileged API that would still make the malware escape the isolation.

 

I didn't understand everything that you wrote, but are you saying that Sandboxie is the only sandbox that has implemented it in a secure way? That's kind of hard to believe, but you may be right. Perhaps you can test your sandbox escape tool also against Cybergenic, Avast and 360 TS, that's all I'm saying.

Also, if you look at the graphic from Comodo, you will see that stuff like file system, registry, kernel object, service, DCOM and RPC virtualization is always done in user mode. But I'm probably not smart enough to understand this in full detail.

 

yes

That would be pointless, just use a tool like process hacker or task explorer and look if the sandboxed processes are runnign with a unrestricted user token. If so than the sandbox will be vulnerable to bypassing RPC isolation.

You may ask @diversenok to report on his experiments with sandboxing software, he took a look into quite a few of them.


Virtualization does not nececerly include isolation, for example sandboxie is structured such that the driver does the isolation, managing what locations can be accessed by the sandboxed process, while the SbieDll in user mode Virtualizes the file-system and registry i.e. mangles the data from the unsandboxed read only locations with the sandboxed copies together to create a consistent view where original files and sandboxed files appear to the application together, as if there would be no sandboxing.
This is done in user mode and if a rogue application wants it can bypass this, getting a view of the readable (not set as ClosedFilePath) part of the real file system as well as access the sandbox redirection location. But this is not anything useful as when run in a clean box the view on the real file-system and the Virtualized view will mostly look the same anyways, so there is not much point in doing that. There is nothing to be gained from this.

 

I don't see how this would be pointless. You say that you bypassed Comodo, then your tool should also be tested against other sandboxes, unless it will take too much time of course. But from what I understood, it's mostly about the unrestricted vs untrusted user token, didn't know it was that simple.

 

Yes exactly if the process has a unrestricted user token my tool will work if it has a untrusted user token it will not.

 

BTW, can you take a look at this if you have the time.

https://www.wilderssecurity.com/thr...tion-featuer-please-test.439066/#post-3022043

 

BTW, these are some interesting interesting articles about usermode sandboxing, this is what AppContainer is based upon and it should be pretty secure. From what I understood you want to make a new Sandboxie option where it only provides virtualization and the sandboxing will be done by the app itself, like Chrome and Firefox for example.

BTW, I know that you're busy but I still haven't heard anything about you making Sandboxie compatible with tools like SpyShelter and GhostPress. Somehow you seem to keep ignoring this request, isn't this important to you? Or perhaps you could integrate an anti-keylogging feature for sandboxed processes, but the thing is that keystroke encryption is the most effective against keyloggers.

https://www.malwaretech.com/2014/10/usermode-sandboxing.html
https://www.malwaretech.com/2015/09/advanced-desktop-application-sandboxing.html