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

[Guest]

[Endymion]

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.

I guess you totally missed the point: Using a driver Proces hacker was able to kill OSS2009 core process and its gui.

Whenever acs.exe core process came "back to life" is irrelevant as this provides no 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.

Using a driver to test termination would be not much different to use a driver to terminate and prevent the restart of those processes using another driver function.

FYI since I found your replies confusing, I tested this myself hours ago. I was able to confirm that acs.exe  core process  was terminated and thereafter restarted with a different PID.

OSS2009 failed miserably to prevent the termination and it would a also fail miserably to restart if the driver included a corresponding restart/loading prevention function (like for terminate & block feature available in View active process list) or, for what it matters fail the resurrection, if the driver would  continually kill  acs.exe to let it RIP (rest in peace) without any intervention whatsoever.


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

So the ability to terminate OSS2009 core processes comes at no surprise nor it would be surprising to eventually confirm that the the degree of control a driver has would also allow to thwart the automated restarting.

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/protection ought to be carried by denying those drivers to be installed/loaded.


Whereas a kernel driver was actually involved,"back to life" restarting would be a red herring.

Moreover it is pointless to allow a kernel driver to test "self protection" because the "protection" in itself mean to prevent such drivers in the first place.


A malicious driver could not only be able to terminate any security but also prevent the restart and carry additional malicious actions with high privileges (unlike the Ghost regtest ring3 usermode PoC previously mentioned)


That's why  in order to use D+ properly, members should be advised to be aware that driver install should not be overlooked.

It should be obvious that, like for a termination driver, it would unreasonable to allow the installation of a kernel rootkit driver and expect the system to be protected and this is the reason HIPSes focus on preventing these installation attempts...

...and there is no joke or mayday that could possibly provide a different notion and drift away from the big picture. 




The realtime protection carried by security softwares is meant to watch over usermode unprivileged applications actions and not drivers. this is why there could be alerts when an usermode application attempt to install a driver  but not when a driver carry some action.

Self Protection tests ought to be carried using unprivileged (without kernel drivers) applications in order to verify that security software do make use of high privileged code (using drivers) to protect the system or else usermode PoCs could be able to thwart the protection without using any driver.



Peace?

[Jaki]

Thanks for all the information that you have provided; however, once again you've got it wrong. The only way I knew that OSS 2009 core process was not killed was because I tested it just like I did for CIS and OA free. I went to PCFlank and also performed the regtest from ghost security. The results were that all my ports were still stealth and regtest could not perform any registry modifications, to me that's success.

OSS 2009 core process protected my system just like CIS did when CIS loaded in kernel. OA free did not protect me though once its processes were killed. In the end my intention and my goals were and still are to improve CIS by reporting what could be a major flaw. To me it is critical to fix this; CIS must be able to protect its processes better. That is all.

PS: Nothing is impossible in life, you just have not thought of a way to accomplish something. I guessed the prehistoric man was saying to himself that it is impossible to go to the moon. And now men are thinking to go to Mars and beyond. Impossible? Of course not.

Peace.

[Endymion]

Once again you've got it wrong. The only way I knew that OSS 2009 core process was not killed was because I tested it just like I did for CIS and OA. I went to PCFlank and also performed the regtest from ghost security. The results were that all my ports were still stealth and regtest could not perform any registry modifications, to me that's success.

OSS 2009 core process protected my system just like CIS did when CIS loaded in kernel. OA did not protect me though once its processes were killed. In the end my intention and my goals were and still are to improve CIS by reporting what could be a major flaw. To me it is critical to fix this; CIS must be able to protect its processes better. That is all.

Once again you missed the point. It doesn't matter how many "lives" OSS core process got as using a driver based approach it would be possible to disable it for good and have it fail whatsoever test.

I'm not sure how anybody could argue about better protection either considering that Killing OSS 2009 core process could be continually repeated to prevent it from running using a similar driver based approach.

In the end the only flaw would seemingly be the way you approached Process hacker driver based termination and regarded it as any usermode termination test.

It is a moot point to argue about a termination carried using a kernel driver because assuming a scenario in which a kernel driver is abused for malicious purposes the only reasonable way to address this would be to prevent the driver.

PS: Nothing is impossible in life, you just have not thought of a way to accomplish something. I guessed the prehistoric man was saying to himself that it is impossible to go to the moon. And now men are thinking to go to Mars and beyond. Impossible? Of course not.

More over nothing is apparently impossible by words alone...

Feel free to let anybody know whenever OSS2009 will be able to prevent the termination carried using a kernel driver without actually needing to come "back to life".

[Jaki]

Once again you missed the point. It doesn't matter how many "lives" OSS core process got as using a similar driver approach it would be possible to disable it for good and have it fail whatsoever test.

I'm not sure how anybody could argue about better protection considering that Killing OSS 2009 core process could be continually repeated to prevent it from running using a similar driver based approach.

In the end the only flaw would seemingly be the way you approached Process hacker driver based termination and regarded it as any usermode termination test.

It is a moot point to argue about a termination carried using a kernel driver because assuming a scenario in which a kernel driver is abused for malicious purpose the only reasonable way to address this would be to prevent the driver.

More over nothing is apparently impossible by words alone...

Feel free to let anybody know whenever OSS2009 will be able to prevent the termination carried using a kernel driver.

Let us agree to disagree on this one. The only thing that I can tell you are my findings. I tested a few security software and I published the results, that's all.

[Jaki]

Feel free to let anybody know whenever OSS2009 will be able to prevent the termination carried using a kernel driver without actually needing to come "back to life".

I already did.

[Endymion]

Let us agree to disagree on this one. The only thing that I can tell you are my findings. I tested a few security software and I published the results, that's all.

Obviously we disagree. Whenever it the methodology and the comments added to the results.

I already did.

OSS 2009 is vulnerable to termination carried by means of kernel drivers and if it is terminated it can be prevented to come back to life by means of the same technique as well.

Having a driver to continually repeat the termination wouldn't be something more  unreasonable than assuming it would be appropriate to carry some tests using kernel drivers, wouldn't it?

If OSS 2009 was actually able to block the termination in the first place coming "back to life" wouldn't be needed at all.

Is it as simple as this.

[Jaki]

Obviously we disagree. Whenever it the methodology and the comments added to the results.

OSS 2009 is vulnerable to termination carried by means of kernel drivers and if it is terminated it can be prevented to come back to life.

If was able to block the termination in the first place coming "back to life" wouldn't be needed at all.

Is it simple as this.

The FACT was and still is OSS 2009 core process was not prevented to come back to life. It is certain that it was the intention of Process Hacker to prevent OSS 2009 core process to come back to life, but OSS 2009 defended itself. Termination, to me, is synonymous to kill. If a process is killed or terminated, if I have to stay true to the meaning of the the words kill or terminate, that process cannot come back to life. My understanding of the situation is that Process Hacker attempted to kill or terminate OSS 2009 core process and was not able to do even after repeated attempts. Isn't that success to you? It is to me.

[Endymion]

The FACT was and still is OSS 2009 core process was not prevented to come back to life. It is certain that it was the intention of Process Hacker to prevent OSS 2009 core process to come back to life, but OSS 2009 defended itself. Termination, to me, is synonymous to kill. If a process is killed or terminated, if I have to stay true to the meaning of the the words kill or terminate, that process cannot come back to life. My understanding of the situation is that Process Hacker attempted to kill or terminate OSS 2009 core process and was not able to do even after repeated attempts. Isn't that success to you? It is to me.

It looks like your understanding of the situation rely on semantic but neglect to properly address the kernel driver approaches involved.

It was your call to use an application that rely on a kernel driver and please be aware that, like with View active process list "terminate and block", some other application+driver could also prevent in one shot the "back to life" you wish to held in account.

Though if you wish to simulate what would happen with a similar driver that endlessly carry the termination then use Process Hacker to continually terminate acs.exe but be aware that applications/drivers can carry termination way more faster than it happens when using mouse clicks or keyboard shortcuts on PH (even faster than an application could possibly display a list of running processes).

It would be plenty possible to thwart OSS 2009 using a variant of the same driver based termination approach in order to endlessly kill any OSS core process and it would be obviously inappropriate for the OP to neglect that so easily whenever PH was not meant to fulfill that purpose.

In the end there is no way to pass a false sense of security for a success...


As it would be possible to bypass any security using kernel drivers, prevention/protection ought to be carried by denying those drivers to be installed/loaded in the first place.

Hopefully nobody will carelessly allow a driver because some process is claimed to come "back to life" because drivers can do way more than terminating something "once".

[Jaki]

Your understanding on the situation rely on semantic but neglect to properly address the kernel driver approaches involved.

Once more you've got it wrong. My understanding is not based upon semantic; it is based on a test that I performed. And based on the result of such a test I've got to conclude that OSS 2009 core process was not killed nor terminated. Semantic or kidding aside, do you at least agree with that statement?


Peace.

[Endymion]

Once more you've got it wrong. My understanding is not based upon semantic; it is based on a test that I performed. And based on the result of such a test I've got to conclude that OSS 2009 core process was not killed nor terminated. Semantic or kidding aside, do you at least agree with that statement?

Jaki you might have overlooked that acs.exe PID changed. This obviously happened because it was terminated/killed whenever you could be willing to create a definition for you individual use this might cause unnecessary confusion.

The result of your test prove that it would be possible to thwart OSS 2009 and even prevent the "back to life" you mentioned by endlessly repeating the termination in an automated way through a similar kernel driver based approach.

It is also unlikely that between a termination and a "back to life" the system would be protected. Nor that it matters since a kernel drivers could not be limited to termination...

[Jaki]

Jaki you might have overlooked that acs.exe PID changed. This obviously happened because it was terminated/killed whenever you could be willing to create a definition for you individual use this might cause unnecessary confusion.

The result of your test prove that it would be possible to thwart OSS 2009 and even prevent the "back to life" you mentioned by endlessly repeating the termination in an automated way through a similar kernel driver based approach.

It is also unlikely that between termination and "back to life" the system would be protected.

I think we can agree on something beside disagreeing  . Do you agree, at least, that OSS protected the system?

Peace.

[Jaki]

By the way, I forgot to ask you. Did you perform your own test with OSS 2009 and Process Hacker? I'm guessing, because you told me that the PID changed and I did not realize that. Thank you for bringing that fact up.

Peace.

[Endymion]

I think we can agree on something beside disagreeing  . Do you agree, at least, that OSS protected the system?

I would be inclined to agree with anybody who noticed you are convinced that that the "back to life" was a meaningful protection against a kernel driver and that could be the reason you are inclined to praise OSS 2009

By the way I forgot to ask you. Did you perform your own test with OSS 2009 and Process Hacker?

Yes I tested OSS 2009 though I came to a completely different understanding from the one you represented so far.

[Jaki]

I would be inclined to agree with anybody who noticed you are convinced that that the "back to life" was a meaningful protection against a kernel driver and that could be the reason you are inclined to praise OSS 2009

Yes I tested OSS 2009 though I come to a completely different understanding.

It is great that you tested it. Now could you give me a full compte rendu of your testing.

Peace.

[Endymion]

It is great that you tested it. Now could you give me a full compte rendu of your testing.

I guess it would be more interesting to understand why you wasn't aware that acs.exe PID changed.

You should be aware that termination tests usually confirm termination using PIDs.

I also disabled permanently acs.exe "back to life" using a reg file but obviously a driver could do it better, few milliseconds after the termination and before the "back to life"

Code:

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\acs.exe]
"Debugger"="notepad.exe"

Would an installed driver trigger any alert? nope, it won't need regedit nor any similar usermode app at all.

Besides it doesn't really matters in how many ways OSS2009 could be thwarted as long kernel drivers are involved...

[Tags:]