Does PG prevent abuse of Kerio Firewall's DLL vulnerability?

in the middle of this Kerio review, http://www.pcflank.com/review_kerio2.htm, it says that Kerio lacks dll protection.

"The software has one big security flaw, however. Let's suppose a Trojan or spyware agent is acting as a component (DLL) of a trusted application (i.e. Internet Explorer). As far as I can see Kerio has no DLL-controlling features, so the malicious agent can bypass Kerio's protection. "

I would like to use Kerio but this is a big concern. Will ProcessGuard protect against this for Kerio?

 

No. It does not.

 

Frequently, it does.

It depends on the way HOW a dll component becomes a part of a trusted application.

Usually, it is dynamically injected via CreateRemoteThread (that's what most trojans do). PG will block this.

However, if the DLL is not dynamically injected but loaded by the application itself (e.g., because of a registry entry or because the DLL was patched into the application (loadlibrary or IAT patch -- so called static injection)) PG will usually fail. PG blocks only one method of "injecting" a DLL via a registry entry (APPINIT_DLL). But there are several other methods.

 

Hi o-o,

It would seem that in order for IE to be modified (either statically or dynamically), there must be some initial dll injection that ProcessGuard would catch as a modification to the IE or as some unauthorized process - because how else could it have been modified? So it would seem that PG does offer protection?

Is it possible to describe the scenario where IE would be compromised and PG would not catch it? All comments are appreciated. Thanks.

Rich

 

No. The idea is simple, in the case of dlls loaded by the application, another running process simply physically replaces the normally required dll file with a malicious dll.

This would not be caught by ProcessGuard since it does not keep hashes of dlls. Modifications of Iexplore.exe would be caught though.

On the other hand, attempts to dynamically injection dlls into the running processes by another process will be caught by PG yes.

In both cases, these actions will be done by running processes that you have already allowed to run.

In theory, if the user _NEVER_ ever whitelists the wrong processes (or better yet, he never tries to run it in the first place) he shuld be very safe, but in practise no one can ever be sure that a whitelisted process isn't doing something sneaky.

That is why PG is more than just whitelisting of unauthorised processes. And it tells you when whitelisted processes carry out 'dangerous' actions.

 

Hi Anon,


"In theory, if the user _NEVER_ ever whitelists the wrong processes (or better yet, he never tries to run it in the first place) he shuld be very safe, but in practise no one can ever be sure that a whitelisted process isn't doing something sneaky."

Yes, this is the key idea. As I understand it, and if I understand you correctly, you are agreeing: The user would have to errantly authorize a malicious process (that PG alerted on) at some point. So PG does give an alert - though the protection is based upon the judgement of the user - as it would in any such "behavioral setup". This is why I am very careful about which processes I authorize - even those coming from seemingly trusted sites - e.g. security sites.

If I am incorrect, please feel free to correct me. I think we are saying the same thing.

Thanks,
Rich

 

If you don't run a process it cannot hurt you. That is obvious and hardly rocket science. I would caution against overconfidence in this feature though since by my reckoning, for a properly setup system, most malware (if any) get throughs via user's permission.

The dll injection and it's cousins in general almost always involve a process already running hijacking -another- so if you don't run the first process it can't hurt you.

I do not however want to give an impression that there is no way for a process to start without being caught by PG's execution protection.

There are ways and means some of which have being mentioned in the past.

That is a totally different kind matter as compared to hijacking processes via dll injection.

 

ITW scenario?

Imagine you download a .msi file from a filesharing network which replaces (after the next reboot) a file called countryflag.dll (used by emule) with a patched version ...

PG won't catch it because it does not hash dlls. Signature-based AV/AT scanners are useless anyway if you are the victim of someone who knows how they work. Firewall? Well, emule requires full access (otherwise you get a low ID). If you use a firewall with component control there may be an alert. However, there will be so many useless alerts because of changed (harmless) components that 99% of non-paranoid users won't recognize what's going on. In addition, there are tricks to outfox component control (but I do not want to disclose them in this forum ... otherwise Gavin will continue to believe that I am a mass infector ;-)

 

Hi o-0,

I think I understand the scenario that you are presenting.

The premise that I am operating under is that ProcessGuard can alert a user whenever an unauthorized program (i.e. not whitelisted) is trying to execute. This is the "anti-executable" protection that PG is offering. If a user decides to download program, and PG gives an alert when it is being executed, and then the user decides to go ahead and execute the program, which in turn does malicious things ... well nothing can be doen about this. It is up to each user whether they want to execute pograms which originate from untrusted sources.

What I am trying to understand is whether the scenario you describe allows the downloaded program to execute and replace the .dll in question without ProcessGuard ever alerting the user in any form from the point in time that the file is being downloaded up until the point the .dll has replaced. This would be a hole, which only a program that tracks file hashing could detect, in which case a good file hashing monitor would be very useful.

Without going too much off track, are there any programs that people use to track file hashes. Thanks for the additional comments and info.

Cya,

Rich

 

@ritchrf

"This is the "anti-executable" protection that PG is offering"

This is the least important feature of PG. There are hundreds of applications (including Kerio firewall) which offer the same feature. Many of them are freeware. If this feature is important to you I would no pay a penny for PG.

PG comes into play IF you allow the execution of a malicious application. Then it allows you to prevent the typical bad behaviour of such malicous apps (e.g., process termination, code injections, dynamic dll injections, disabling of WFP, installation of drivers, etc.).

Anti-execution protection is more or less redundant if you are a disciplined user. Just make sure that your fingers are not double clicking ;-)

 

Hi o-o,

I am not trying to rate the importance of different features. Rather I am trying to determine whether PG will alert whenever a new program seeks to execute on the system. Actually, accidently clicking on a file (maybe not realizing that it is an executable), is not as uncommon as you might believe, but that is not really relevent to my question. If ProcessGuard alerts, then I am satisfied. What I thought you were saying was that somehow an executable can sneak through and do something without me knowing it.

As far as I can tell, there is absolutely no protection that can be provided when someone decides to go ahead and execute programs from untrusted sources. At that point, the untrusted program can do almost anything - and as you suggest, it is rather easy to defeat AVs, ATs, anti-spyware in this respect. (It is like allowing a stranger into a house. Once that is done, all bets are off). My primary concern is to have some "say" in the matter concerning which programs can execute on my system (which person can enter into my house), and which cannot. I just don't want anything (or anyone) sneaking through a backdoor.

Cya,

Rich

 

Well ... depending on your PG settings/rules PG may NOT alert you if you double click a .msi file. Try it out on your computer ...

;-)

 

Yes, as I understand it msiexec.dll should be given "Permit Once" authorization. I wish that DiamondCS augments its own help files with additional information concerning processes such as rundll, msiexec, etc. This type of special information could be really useful to users of the product.

 

For the die-hard Kerio user, this question has been laid to rest ages ago: Kerio does not have dll injection protection, never was intended to have it,- - the philosophy being that a firewall should be left to do it's original job: filter packets - - and other products should provide protection for the newer threats. Search these forums for "Kerio" for fuller discussion, and also here:

http://www.dslreports.com/forum/kerio

In looking at the various tests on the attacks page on the DiamondCS site,

http://diamondcs.com.au/processguard/index.php?page=attacks

it appears that PG does not block the unpacking of the dll, rather, blocks the dll's attempt to create a hook. So, depending on what the dll does after being loaded, PG may or may not block its execution.

Anti-Executable from Faronics includes dll files in its whitelist. I showed in another thread how, if trojans were somehow permitted to download and be updated into the whitelist, that those that unpacked drivers and dlls would be blocked from completing the install. These tests included a keylogger.exe, several dll injection tests, and one rootkit.exe.

-rich
________________
~~Be ALERT!!! ~~

 

Hi rich,

Thanks for the additional info. I took a look at Anti-Executable, but it appears that they are selling only to institutions and in multiples of ten. If there are single user licenses available, could you provide me with the link. I might want to read more about it and try it out, if it is applicable to my situation. Thanks.

Rich

 

Hi Rich,

First a little side-note.
I cannot run PG on my W98SE box, so I leave that to others.

Now about your question.
(I call those programs file integrity checkers.)
It depends on what you want:

1. on demand scanning.
1-a. Only a few files (I mean you don't want all the files on your system checked): the CRC32-test in TDS-3.
1-b. All the files on your system (and I do mean all):
ADinf32 (see review https://www.wilderssecurity.com/showthread.php?t=72131 ).
Inspector in KAV Pers Pro.
1-c. NIS File Check (no longer maintained; archived forum at the bottom of this board).
Your choice what you want to be checked.
1-d. Others. For example, I know that Bellgamin used another one.

2. near-real time checking.
File Checker from Javacool; it's polling every x seconds.
Your choice what you want to be checked.

3. real time checking.
File Change Alarm. Brother of NIS File Check from Albert. (no longer maintained; archived forum at the bottom of this board). Not for older systems like 98-ME.
Your choice what you want to be checked.

4. real time checking with protection.
A very very expensive program from Alfa Corp.

5. others.
There are others too.
Somewhere RegRun for example also fits in the list.


Well, I wrote that several times in the past
And it is up to the user to decide whether a change is legit or not.
And years ago I wrote a little theoretical essay about maybe possible vulnerability with respect to safe storing of hashes; first posted at the DCS private board; it's too old now, and I'm repeating myself too much.


Back to the topic

 

Anyone tried this freeware out?

http://www.toast442.org/md5/

 

Hi FanJ,

Thanks a heap for the list. I will check out the programs you mentioned.

Regards,
Rich

 

"I took a look at Anti-Executable, but it appears that they are selling only to institutions and in multiples of ten."

Integrity checkers may be used on computers with a fixed setup (e.g., corporate environment). An ordinary desktop user, who has other objectives than wasting 99.8% of his/her time with security software and related forum discussions, will probably not use an integrity checker which monitors each and every DLL. This is simply because you will get constantly bugged if you install a new application or an update of an existing application (which may use dozens of new DLLs). Moreover, if you install a new application, you will not know whether one or more of the DLLs which come with the new application are trojanized or not.

It's quite simple ...

Either you do not change your system and do not run software which does not stem from absolutely trustworthy sources: in such case you do not need an AV/AT, firewall or an integrity checker (a system firewall still makes sense because it will partially protect you from browser exploits).

Or you act like a normal desktop user in which case an AV/AT, a personal firewall and a system firewall will protect you much better than a DLL integrity checker.

 

Just for the record :
I never said that it is better to use a file integrity checker in stead of ProcessGuard.
If I could afford me a newer system, I would immediately get ProcessGuard.
(I probably would still use an on-demand file integrity checker; but hey, it's just me ).
I hope that I could have avoid any misunderstandings with this.
I'd better stay out of this thread further

PS:
Beetlejuice69, I haven't tried that one.
Rich, you're welcome.

 

Thanks for the reply.

 

Thanks alot for the responses everyone. I can understand now why Kerio doesn't have dll protection. As Rmus said, a firewall's job is just to filter packets. I just started using Kerio and like it alot. The "System Security" feature is a welcomed addition that I suspect more firewalls will have in the future.

 

@FanJ

"I'd better stay out of this thread further"

Sorry. This was not meant as an attack. I just spoke my mind (as I always do ;-). You are certaintly entitled to a different opinion.