Kerio 2.1.5 blocks disable attempt

See my post in this thread:

https://www.wilderssecurity.com/showthread.php?t=82897


-rich

 

Interesting. So which of these is stopped by an Kerio 2x admin password?
http://www.diamondcs.com.au/index.php?page=process-termination-methods
(Try the APT tool).

 

I don't know - I'd have to learn more about that before testing. Right now, I'm looking at the Process Guard attacks.

Anyway, all Kerio did here was prevent something from trying to disable the Firewall in Windows Services - a rather simple exploit attempt that triggered the password prompt.

Attempting to terminate a process would seem to be working at a lower level and I think you would need something else in place to prevent that, and not just Kerio's password prompt. For instance, PG code modification protection blocks attempts to change the rules of a firewall by altering code.

But, ghost, you know more about the inner workings of Kerio than I do - what do you think??!

-rich

 

One more plus for Kerio, I would also think that the Always Secure reg hack would make it even more secure as even if the worm manages to disable Kerio, it would block all traffic.

 

My limited testing has reached the following conclusions:

- Kill #7 (sending Close messages (called WM_CLOSE) to all windows in the target process) brings up a password dialog if one is set. If no password is set termination proceeds as normal.

- Kill #8 (like #7, except sends SC_CLOSE system messages) fails to terminate the Kerio2x process without any password prompts if a password is set. If no password is set termination proceeds as normal.

- Who knows (and really who cares) what happens when the almost unheard of WinStationKillProcess function is performed on Kerio2x.

All other termination techniques listed in APT are successful regardless of whether a password is set.

However, I encountered something rather strange:

#7 and #8 only work if 1) the target process has at least one window, and 2) the target process doesn't handle the WM_CLOSE message (see the DiamondCS link above)

During my limited testing, (which may have been because the firewall was not loaded properly) there was a time when APT reported that Kerio2x did not have a least one window open - hence regardless of whether a password was set the termination technique (#7 or # failed. This doesn't make sense to me - I would have expected at least one window to be open. The best explanation I can give for this is that I tried to terminate the wrong application, as I have been unable to reproduce this rather weird situation.