The author @Loyisa of this PoC had reported to Comodo weeks ago, but no response.
Melih answered me about this… The guy in the video disabled the shellcode injection protection, then the sandbox is really weak. Now, what about this installation bug?
@stnert Nothing you can do before Comodo shoots a new release with the certification issue fixed.
OMG … I hope the new release is coming soon!
I guess we need to wait another three years to fix this issue
What is there to fix when shellcode detection setting was disabled which tells cis to not inject the guard32.dll and guard64.dll into launched applications. This reduces the hips and containment protection effectiveness, so this poc should be tested without disabling that setting and if it still fails then comodo would then need to fix the flaw.
The sample has been sent, looking forward to your test results @DecimaTech
@Loyisa I guess this PoC also works when the shellcode detection is enabled.
correct, even with untrusted restricted mode
@Loyisa Great, waiting for @DecimaTech 's test results. .
BTW, Melih @Melih always doesn’t believe their Containment technology can be bypassed.
He will never allow that.
O_O
OMG! Really???
I only took a quick look at the source code and I can tell what the issue is. By default cis does not protect access to the service control manager defined as *\RPC Control\ntsvcs so you would need to add that path to the protected COM interfaces section. The source code also contains code that attempts to access the SCM via a named pipe so you can also add *\Device\NamedPipe\ntsvcs to the protected files section to cover the named pipe access.
With that said, there is a compatability issue with windows UAC that prevents containment restriction levels being set to the desired restriction level for applications that require administrator rights. This means if you set the containment rule to use a restriction level higher than partially limited e.g. limited, restricted, or untrusted and you run an application that requests admin rights/elevation, then cis will lower the restriction level to partially limited. So you don’t get the protection provided by the higher restriction levels.
Therefore you need to completely disable UAC by setting the enableLUA registry value to 0. This is important to note as using SCM requires admin rights and setting UAC to never notify, doesn’t actually disable UAC itself as it just won’t pop up an UAC alert and will auto grant elevation to admin.
Edit: oh and there is yet another bug that affects cis on windows 11 with regards to using restriction levels. Whenever an application is executed by windows explorer, which happens when you use your mouse to run apps, the restrictions that are supposed to be applied don’t get set so you get tricked into a false sense of security.
it won’t works, Comodo does not properly handle direct access to pipes via the WriteFile API
I also tried *\Device\NamedPipe\*, not working
Yeah I don’t think named pipe access is controlled when running apps as fully virtualized, it should show alerts when using HIPS though because they use a ntcreatefile hook to monitor named pipes.
There might be a way by using protected data, just add a random file then edit the path to the namedpipe path.
Are you sure???
I only believe with CERTAINTY. Not with guesswork.
In simple or other terms, you mean Comodo will not detect shellcode injections in the PoC or programs with the setting enabled for effective HIPS and containment protection?