A detailed discussion paper on ProcessGuard by Andreas

[Pilli]

I have added this thread as Andreas is a DCS beta tester has spent much time writing this excellent paper which can be viewed here:
http://www.commontology.de/andreas/win_secure_pg3.html

Andreas still has a few additions to make regarding version 3.050 but the paper is still very valid, this paper is a useful read to both new and old ProcessGuard users.

I am sure that Andreas would welcome any constructive comments :)

Thanks Andreas and to those that contribute. Pilli

[Andreas1]

-{ Quote: "I am sure that Andreas would welcome any constructive comments :)" }-

Definitely yes. Just mail or IM me via my profile.

Thanks for sticking the site here, Pilli ;D

Cheers,
Andreas

[Starrob]

Thanks for the article. It helped me learn a few more things. Keep up the good work.



Starrob

[Stefan12]

Thanks for the fine piece of documentation work!

The paper says that PG checks "signatures" for programs, but not for DLLs. Is this still the case in the current PG version?

Thanks,

Stefan

[Jason_DiamondCS]

Good work Andreas, it is a good read. :)

[Pilli]

Hi Stefan12. -{ Quote: "The paper says that PG checks "signatures" for programs, but not for DLLs. Is this still the case in the current PG version?
" }- That is correct ProcessGuard ony checks executables at the moment, the overhead for checking every .dll would be horrendous, also ProcessGuard protects one from .dll injection, physical memory space, blocks global hooks and stops driver/service installation, so it is all a matter of balance.
Having said that an option to be able to do some sort of .dll checking may be possibility in a future versions providing DCS deem it desirable & or feasible.

Pilli

[Starrob]

I don't know how DCS can make it possible but I hope DCS can one day provide some type of solution for protecting against changes of DLL on the disk or static DLL injection.

Right now, this appears to be a difficult area for trojan authors to attack because of the complexity and for security companies to defend against because it appears .dll checking might not be feasible (at this point in time)

I hope DCS can innovate in this area. There may not be such a thing as 100% security but that does not mean you don't continue to strive for it and accept the status quo.

Continue the good work on ProcessGuard too. I believe you guys are breaking new ground. This I like. I dislike the old solutions that are not providing real security against new threats.


Starrob


-{ Quote: "Hi Stefan12. That is correct ProcessGuard ony checks executables at the moment, the overhead for checking every .dll would be horrendous, also ProcessGuard protects one from .dll injection, physical memory space, blocks global hooks and stops driver/service installation, so it is all a matter of balance.
Having said that an option to be able to do some sort of .dll checking may be possibility in a future versions providing DCS deem it desirable & or feasible.

Pilli" }-

[Andreas1]

As an aside:
for dll checking you could combine PG with some file change monitor like filechecker NISFileCheck and the like. It won't (AFAIU) give you real-time protection, but at least try to cover the issue.
Andreas

[rdsu]

Thanks for this great work Andreas ;)

[Stefan12]

Hi Pilli and other responders,

-{ Quote: " ... ProcessGuard ony checks executables at the moment ... also ProcessGuard protects one from .dll injection, ... etc.
Having said that an option to be able to do some sort of .dll checking may be possibility in a future versions providing DCS deem it desirable & or feasible.
Pilli" }-
I appreciate your details and recommendations.

DLL checking would seem, at least in theory, to desirably strengthen the intrusion control. No? I hadn't realized that usable/effective DLL checking was a tough nut to crack.

The bright folks on the DiamondCS team have a powerful piece of software in PG. Working on getting my chops down with PG ...

Thnx,

Stefan

[gottadoit]

Andreas1,
How about adding some information about WFP and how PG blocks the attacks quite nicely (with winlogon.exe read protected) and that there is still an open avenue of attack via the API's that are used by Windows Update and that additional software would be useful to alert if files are being replaced in that way

There are a couple of threads discussing it, but its really a very simple issue
See here in other anti-trojan software (http://www.wilderssecurity.com/showthread.php?p=323695#post323695) and here on bo.funpic.de (http://boardadmin.bo.funpic.de/viewtopic.php?t=53&sid=a9cdacec4cf874748474e36577274915) as well as here (http://www.wilderssecurity.com/showthread.php?t=20998) and here (http://www.wilderssecurity.com/showthread.php?t=57384) in the PG forum

Thanks

[Andreas1]

gottadoit,
I think this is an interesting thing to investigate/write about, so I will try to cover it. But it will surely take some time - I don't want to write about what I don't understand, so I will have to do lots of reading first. Early next year, probably.
Thanks for pointing out the issue for the website (and for insisting on it being an important one).

Andreas

[^Ale]

Thanks Andreas for your good work (and to Pilli for the link)

[Whynot]

Excellent article Andreas - greatly appreciated. Fancy doing similar for TDS3 :D

[gottadoit]

Andreas1,
Another thing that might be worthy of mention is that if you are being paranoid, then rundll32 is a good thing to have set to "Permit Once" and not to grant runddl32 any extra privileges if at all possible

Having it set to Permit Once will only be effective if you are the type of person that actually reads the popup dialog prior to clicking Allow and are interested enough to learn about what the various options are

The reason for doing this is that rundll32 is just a mechanism for invoking functions inside dll's, this basically means that it allows code to be run under the guise of rundll32

There are some threads discussing this already, see here (http://www.wilderssecurity.com/showthread.php?t=59185&highlight=rundll32) and here (http://www.wilderssecurity.com/showthread.php?t=53023&highlight=rundll32)

In the second thread above Jason said
-{ Quote: "RunDLL is sort of a small risk because some things can use it to load their DLL, however typically there needs to be another malicious EXE already running to do this (which sort of makes the point of calling RUNDLL invalid). I would put RunDLL on "Permit Once" and just allow it each time so I could monitor the COMMAND LINE parameters sent to it (which basically tell you what it is doing). It is sort of annoying if you need to do it every reboot, but for me it isn't that big a deal.

I sort of prefer getting the execution protection prompt before running most things now, I only permit always my startup applications." }-

Edit :

If Block New and Changed Executables is enabled then "Permit Once" items will be denied in addition to anything new and changed (teach me not to read the help file to find the non-obvious things).

If you make rundll32 permit once and also enable the "lockdown" option you won't be able to run control panel applets and a few other things that you might normally want to do from time to time (until you turn the option off again) ....

[Andreas1]

Okay, thanks for all your feedback.
I've updated the page and included many of your suggestions.

Have a good year ;)

Andreas

[JerryM]

I read much of Andreas' paper. I had downloaded the free version of PG but not installed it. I am not at all sure I can figure out what to do with it or how to do it. It looks very complicated for an average user like me.

What does it mean that the free version is only able to guard one process? What is a process in that context, and if only one which one should it be?

See my ignorance?

I was considering installing Spyware Guard, and PG. Maybe not a good idea considering my state of understanding. I am not sure how SG and PG differ.

Jerry

Jerry

[Pilli]

Hi Jerry, They are completely different.
ProcessGuard has a learning mode which does most of the work for you.
If you open Task Manager you will see all the "Processes" that are running, these can be terminated or changed by some types of malware so protecting them helps create a very strong defence aginst the nasties.
Also ProcessGuard lists every executable file and will notify you of any change, so is a nastie changes say, outlook express, then ProcessGuard will tell you and ask if you wish to allow such a change.

In the full version of PG you have extra options for protecting processes from all currently known termination exploits such as those used by rootkits.

HTH Pilli

[JerryM]

Thanks again for your help.
I know if I get in trouble I can get help here. That gives me confidence to do some things that I would not otherwise attempt.
Jerry

[gottadoit]

Andreas1,
Have a read of this thread (http://www.wilderssecurity.com/showthread.php?t=72350) about some more variations on the permit once theme (regsrv32 and cmd)

It might be worth considering including a little on the suggestions in the thread

Earth1 pointed out the usefulness of having a copy of cmd.exe with permit always for trusted batch jobs and I've been applying the same principles for other trusted batch jobs (with cmd and regedit etc)

[Pilli]

Hi gottadoit, Andreas is completing his Phd ATM so is not around much but I am sure he will update his report when he gets some time back :)

[Trooper]

Is Andreas's site down? I can't seem to connect to it and I wanted to print it out prior to installing PG. :'(

[richrf]

Hi Jag,

I was just able to access it. Are you having trouble with just this site, or other sites as well?

Rich

[iNsuRRecTioN]

Hey,

any updates here?

Hopefully Andreas1 can update his report for PG 3.3 :D

thx and best regards,

iNsuRRecTiON