Mayday, Mayday. This is NOT a Joke: CIS Processes shutdown

[Guest]

[Budda]

This is an old thread previously discussed.

http://forums.comodo.com/leak_testingattacksvulnerability_research/process_hacker_can_terminate_cis_processes_a_concern-t38772.0.html

[Jaki]

This is an old thread previously discussed.

http://forums.comodo.com/leak_testingattacksvulnerability_research/process_hacker_can_terminate_cis_processes_a_concern-t38772.0.html

I was unaware of this thread until last night, consequently, it is not old to me . However, I still have the same question what is being done about it? Are the engineers of Comodo still working on a solution?

Peace.

[OmeletGuy]

I was unaware of this thread until last night, consequently, it is not old to me . However, I still have the same question what is being done about it? Are the engineers of Comodo still working on a solution?

Peace.

Maybe V4 will have a fix, since it got the Behavior Blocker.

[Jaki]

Maybe V4 will have a fix, since it got the Behavior Blocker.

I hope so. I'm keeping my fingers crossed while praying to God. 

Peace.

[Endymion]

You probably forgot that Process Hacker is not a rogue application. It is an application that allows someone to test his or her security apparatus. How can you really test a security apparatus if you do not allow the testing application to be fully loaded.

Whenever  not a rogue  Process Hacker rely on a system driver to carry the termination.


The reason that security app can protect the user is the use of such drivers which have more privileges that any unknown usermode (ring 3) application.

Allowing a driver to be loaded mean that the driver will be able to obtain the same privileges/rights of the security software drivers.

More generally, it's impossible to stop kernel-code from doing whatever it wants, so the best way to stop it is by preventing it from loading.

As Process hacker developer noted, it would be possible to bypass any security using kernel drivers thus prevention ought to be carried by denying those drivers to be installed/loaded.

Whenever some other app may attempt to restart itself it is likely that a driver might be used to prevent this backup mechanism from occurring.

Though adding \Device\KprocessHacker to My protected files will provide a way to prevent termination, in order to use D+ properly it is important to be aware that driver install/loading should not be overlooked.

Indeed like for a termination driver it would unreasonable to allow a kernel rootkit and expect the system to be protected and this is the reason HIPSes focus on preventing these attempts...

[Jaki]

Whenever  not a rogue  Process Hacker rely on a system driver to carry the termination.


The reason that security app can protect the user is the use of such kernel drivers which have more privileges that any unknown usermode application.

Allowing a driver to be loaded mean that the driver will be able to obtain the same privileges/rights of the security software drivers.

As Process hacker developer noted, it would be possible to bypass any security using kernel drivers thus prevention ought to be carried by denying those drivers to be installed/loaded.

Whenever some other app may attempt to restart itself it is likely that a driver may prevent this backup mechanism from occurring.

Though adding \Device\KprocessHacker to My protected files will provide a way to prevent termination, in order to use D+ properly it is important to be aware that driver install/loading should not be overlooked.

Indeed like for a termination driver it would unreasonable to allow a kernel rootkit and expect the system to be protected and this is the reason HIPSes focus on preventing these attempts...

It is not always true. While Hacker Process Kernel was fully loaded OSS 2009 did protect its core process. Howe could you explain that?

[evil_religion]

It's not important. I guess with little modifying of Process Hackers driver it could also kill OSS.

The weakness of CIS lies rather in its warning pop ups than in theoretically passing almost all leaktest like dangers. A pop up like services.exe or processhacker.exe wants to create registry keys bla bla is totally wrong for novice users. Kaspersky IS does it how it should be with red warning pop ups that explain what exactly happens and that KIS can't control the application's activity anymore once the driver is loaded.

[Endymion]

It is not always true. While Hacker Process Kernel was fully loaded OSS 2009 did protect its core process. Howe could you explain that?

AFAIK you claimed the core process "went back up right away". Does protect mean restarting that process?

[Endymion]

Kaspersky IS does it how it should be with red warning pop ups that explain what exactly happens and that KIS can't control the application's activity anymore once the driver is loaded.

CIS provide a red warning alert too and can also be configured to control the application activity once the driver is loaded. Eventually changing the description would be trivial.

[Jaki]

It's not important. I guess with little modifying of Process Hackers driver it could also kill OSS.

The weakness of CIS lies rather in its warning pop ups than in theoretically passing almost all leaktest like dangers. A pop up like services.exe or processhacker.exe wants to create registry keys bla bla is totally wrong for novice users. Kaspersky IS does it how it should be with red warning pop ups that explain what exactly happens and that KIS can't control the application's activity anymore once the driver is loaded.

I will test KIS 2010 tonight or tomorrow along with NIS 2010 and see how they will handle Process Hacker. Stay tune

[Jaki]

AFAIK you claimed the core process "went back up right away". Does it mean that the protection was the restart of that process?

Yes indeed and it is not only that, when I Tried Process Hacker Terminator OSS core process did prevail. Also in order for me to make sure, I used regtest from Ghost Security. The first test was trying to modify some registry keys and I couldn't just like CIS in default deny mode, OSS did successfully defended the system. The only exception was that OSS core process was still alive.

Peace.

[Jaki]

Thus far here are the applications that I have tested with Hacker Process:

CIS 3.10
OA Free 3.5
OSS 2009

Results:

CIS 3.10

All CIS processes were killed; However, CIS went to a default deny mode and successfully defended the system. I went to PCflank in order to test my ports and all of them were still stealth and I also perfromed regtest from Ghost security and I was not even able to run it. CIS successfully defended the system.

OA Free 3.5

OA free did put up a fight. Nonetheless, all its proccesses succombed to Process Hacker. My ports were not stealth anymore once OA processes were killed. I ran as well regtest and I was able to successfully modify some registry entries. But at the booting process OA caught the regtest and asked to delete it, and I did.

OSS 2009

OSS 2009 successfuly defended at least its core process, not the gui. In the end OSS 2009 core process prevailed and all my ports were still stealth and I was not able to run regtest.


OSS 2009 was the only security software that I have tested thus far to successfully defended its core process without my system being compromised.


Peace.

[Endymion]

Yes indeed and it is not only that, when I Tried Process Hacker Terminator OSS core process did prevail. Also in order for me to make sure, I used regtest from Ghost Security. The first test was trying to modify some registry keys and I couldn't just like CIS in default deny mode, OSS did successfully defended the system. The only exception was that OSS core process was still alive.

Though restarting acs.exe to keep it alive would be pointless since that OSS 2009 core process was killed (and thereafter restarted unlike the OSS gui), wasn't it?

In the end restarting a killed core component is by no mean a protection against what a Kernel driver could do.

[Jaki]

Though restarting acs.exe to keep it alive would be pointless since that OSS 2009 core process was killed (and thereafter restarted unlike the OSS gui), wasn't it?

In the end restarting a killed core component is by no mean a protection against what a Kernel driver could do.

No you've got it wrong. I did not restart it nor was the computer rebooted, the process itself restarted immediately and brought itself back to life on its own with no intervention whatsoever from me. As a matter of fact the point the test was to terminate all of OSS 2009 processes. The gui went dead while the core process was alive and well.

Peace

[Jaki]

Though restarting acs.exe to keep it alive would be pointless since that OSS 2009 core process was killed (and thereafter restarted unlike the OSS gui), wasn't it?

In the end restarting a killed core component is by no mean a protection against what a Kernel driver could do.

My very first post on this thread was to eventually ask for help. So in order to see what I'm talking about, please download virtualbox and perform the test yourself with OSS 2009 in order to verify my findings. That's what I wanted to do in the first place, to compare my results with someone else, whether they could be similar or different.

Peace.

[Tags:]