Appdefend integration with Regdefend

Some ppl like the way all conponment are integrated in a single program. Other prefered to have separate conponment. While is was thinking about how regdefend work, I realise there is many situation where it's a wining situation to have both integrated and maybe interdependant.

For example the new behavior of next beta is appdefend warn when you launch a program if it's changed, no matter if you normally warn about execution.

On the other hand, regdefend use plain relative file path + command line.
But what if the program is changed with our rogue program ?
One of the example i have found is the application exeption in tonny ruleset
Both Rstrui.exe and msiexec can play with autostart application.
If hips becore more common, they will be likely to get overwritten (bypassing sfc) to grant access to registry.

However at the same time appdefend have a clever hash algorithm and a nice maintenance tab. So it would be very usefull and not to hard to integrate a checkbox in RD that tell to verify hash for this application rule.

Inversely, applications that have special rules in appdefend are most likely to be the one that have special registry need. So for example by rigth clicking on a appdefend application you can add a rd rule.

Unfortunately i guess this is from the gui enchancement that will be done last before non beta release

 

f3x wrote:

AD does this now. I upgrade an app and the next time it is executed an AD warning window appears telling me the apps checksum has changed.

I do not see where this would be an enhancement for RD, since its purpose is to watch the registry for any additions, subtractions, changes. When combined with the protection of AD, RD only has to make sure said modifications are allowed or ask you what do you want to do. It is up to you to make sure the app is safe to run.

I think the only time I need to make an RD app rule is when an app is upgraded very frequently and I do not want to disable AD/RD each time. Most of the time I disable both for installs and upgrades and updates, which does include the Microsoft updates and patches. But then I download software, including updates and patches, from the vendors web site only!! Call me funny or anything else, that is just one of my security precautions. About the only thing I don't disable AD/RD for is the updates to Eric Howes IE-SPYAD.

 

Well not really. If you set the default to alwais allow execute, then another program with the same path but not the same hash will have the same rigth with no warning. What is supossed to be changed is to warn whatever the state of the default option when the program change hash. The whole point of the thread is that "warn on change" will only happen on program that are on the list of program to be monitored and i wanted a quick way to put RD program on that AD list.

If you see ruleset like the new tony one wich will be close to the next default rulset, you'll see some application rules by default.

For example windows restore (rstrui.exe is able to set program to execute at bootup) If you substitute rstrui.exe with your own program, the new program will inherit the rigths from the legit one wich is the whole point of why hash is more important than path. In that sens it's from the best of RD to (optionally) check for hases.

Then someone may ask what happen if the file is legitly updated by microsoft.
In that directlion i beleive that MS is counting more and more about digital signature. So an option to check if the file is signed and to verify signature should be usefull.

In understand your situation, if you use AD in withe-list mode where you only allow the same 30 known secure program to run, those feature migth be useless (as it will not run anyway). But this kind of whitelisting isn't realisable ouside an entreprise-like environment. My machine is a "table tournante" of software constaly being installed / tested and uninstalled. If i go in whitelist mode i'll soon have a long list of software who was only run one time.

This is exactly the negative point of GSS software and i'll never stress enougth that it should be changed. Half of my feature request in the others thread does with finding softer transition. It makes no sens of disabling a security software just because it's noisy at some time. Better design should allow more granular control that on/off. (Ref: Installation mode in RD feature request )

 

That's incorrect. I often install updates for specific software and I always get a warning by AD that the application has changed.

 

In AD:
Select .Default
Set Execution to allow.

you will have no alert whatsoever if it changes or not
Ref: This thread bu suave
https://www.wilderssecurity.com/showthread.php?t=110365


Jason:

 

Well, maybe in this case. But for .Default in my GSS the permission for all actions (except "Self Terminate") is "Ask User/Allow". I don't know why it is different for you - you must have changed it. The permission to Execute for a specific application is of course "Allow" - and AD reacts to any change as mentioned in my previous posting.

 

As i said, i do not use ad in whitelist mode.
If i want to open something, i want to open something.
I do not want to have to allow every execution i make
Or even wort to build a long list of program i have run only once.

There are way to have a tigth security without being invasive.
With too invasive solution you end up alwais disabling GSS when you install/update etc. At the end, a less invasive, alwais on solution is a better bet.

Ghost security offers "transparent solution". It should not be only a matter of ressource but also of user interaction.

 

Neither do I! If the .Default rule is configured as mentioned and you start an application for the first time you will be asked by AD if you want to allow it once or always. If you choose always you won't be bothered by AD any more as long as the application isn't changed. If an application is updated or somehow altered AD informs you that the application has changed and you have to allow it once again. Isn't that what you want?

 

All of my trusted apps are given Always Allow permission, and as I said before when one is updated I get the warning about the hash being different. Looking at the files in the GSS folder, RD and AD are integrated into the one GSS.exe which does appear on my AD programs list.

As I have stated in another thread, possibly on the RD board, default application rules may/may not be of benefit to me. All of my security programs are installed to a different target folder from the default, defeat malware that targets specific security app by their default install path. Even though that is not seen as much today, it means malware writers have to code not only app checking in to their ilk but some type of path checking as well. Which in turn makes the malware bigger and a bit more difficult to deliver.

I can agree with you on this, if my computing habits and security point of view is similar to yours but they are not.
If something were able to replace an app that is trusted in AD/RD, then you have a bigger problem than whether RD checks a files hash. Like I said above, whenever a trusted app is updated/upgraded I always receive an AD warning the the program/hash has changed.

I may be wrong, but i believe digital signatures can be faked. Thus the reasoning behind my comment about only downloading software from trusted sources.

No enterprise environment here, just a home LAN and user who beta tests for several vendors. Which like you I am constantly installing/uninstalling software, and sometimes doing the same to installed software because something caused it to break. I will periodically go through AD and the Programs list in ZoneAlarm SS and remove the "useless" entries. A bit of a hassle but well worth the effort.

I understand about the long list of software, but mine comes from one app and its inherent behavior, Rundll32.exe. I have an AD entry for each unique instance of it. Hopefully this will be corrected in a later release, since this was one of the first things I noticed about AD and talked to Jason about.

If you trust the vendor of software you are installing/uninstalling then disabling give the added benefit of not getting all of the one time runs of install/uninstall files from the temp folder, which more and more vendors are doing, added to AD/RD. An installation mode would be a good feature for GSS, I think even a global disable/enable would work here.

I think what we are talking about is our personal computing styles and how they differ in relation to how you or I expect, in this case, AD/RD to behave and interact. On that premise, there will never be a program written that is a perfect fit for everyone.

 

Then why do you run AD? The time taken to initially give your trusted apps an Allow Always click on a warning is minimal. Once done you will not be bothered by that app again, well except for the changed hash warning.

Sure there is, do not connect to a LAN or the Internet and lock it up in something like a gun safe when you are away from it (to prevent anyone else from having access to the computer). That way your computer is a microcosm unto its self, and only you will have access to it.

Agreed. It does require some input from the user, and once that is done you will not be bothered until something changes that may be a threat to your computers security and health.

 

When someone double click on an app they surely want it to run 99% of the time. This is enougth for *general public* to develop an habbit of alwais cliking
allow alwais on execution dialog. Even worst, this is enougth to click allow alwais on ALL dialog. And this is the reason HIPS aren't yet really mainstream.

As you stated if you want peace about a program, you simply have to allow alwais. Then you have a HUGE list of program in appdefend list. You are not sure why those program are there ... do they need special network access ? do they have special driver privilege ? or they are just their because you wanted to run them once ?

Having an unmanageable list as well as too many log entry as well has haiving to confirm when you first want to run a program sort off null out any point of being protected.

You run on what i call white list mode. You say you do not.. maybee it's a divergernce of definition. For me withelist mode is to run without prompt or problem only what you have on your application list.



The problem with current implementation is that there is no difference between "main application" and "helper application" if i run only main application then the current setup would not bother me. However it's all those side by application, eg: specific freeware tool you run only once in a while, setup/uninstall application, external exe config wizard, external gui for a cmd line application. Having to log and manage those passby application can really get an hell. For that reason the execution and start application is set to alwais allow.


In my view, i would not mind to start a virus / malware if i'm sure that any attempt for it to be recursive (install driver / autostart registry / Ie plugin ) is blocked. I also beleive it's a good tradeoff to let it run but block when doing something bad. In that way you don't get pissed off by protection unless it really need an attention. The feature I proposed was usefull in the context of this trade off.

I understand your poitn of view also. Whitelisting is the more powerfull way to be sure everything is clean. However what happen if you innavertly press run alwais ? In those situation it's really the part two (prevent it from being recursive) that matter so you just reboot and then do a bit of cleanup.

This may be because I have a modern(?) view of malware ...
IT's isnt worth anything to just rippoff every file on a computer.
It's really more worth if you can make a cluster of slave infected zoombie computer to do what you need.

Maybee the next generation of virus will be designed to only be executed once, gather commercially usefull information and just fade out to infect another computer. In that optic, i assume my setup is definitively useless
but i take other mesure to be sure i don't keep information i dont want shared on my computer.

 

We missunderstood each other
What I said is "if you set the default to alwais allow execute"
Meaning the state of the .Default, not alwais allow on individual application
Sorry for not being clear enougth

From my understanding those application rule are there to make tougther security by blocking them at global stage, then allowing only the legitimate way to do it. Ref: wallpaper and rundll.

I may also be wrong but i am in the impression that this involve very strong assymetrical cryptography à la PGP
with public/ private key. They also need an external online server to host one key. This let very few information in the hand of the hacker who want to crack it, and it would surely take an enourmous computation power to fake those.

Well for rundll32, you should consider each instance as a new one.
as the name imply this is used to run a dll as a executable and thus what is really important is the command line and not the fact it's rundll per se.

It's not a matter of do i trust the software. What i would want is the equivalent of disabling but only for that software: Just in case something else slip when you have your AD/RD turned off. The problem is that when you turn AD/RD off you turn it off for all software, not only what you have installed

YOu are definitively rigth it'a all about personal computing style. All i ask about is optional feature built in GSS that let the user choose what style he is more confortabl with. Withe list on program execution or concentrate on what happen once the program is run.

I run AD because it block driver install
because it block one program killing the other
because it block physical memory access
beacause it block dll injection

All of those feature are needed in order to keep existing antivirus/registry protection active.
Ad is used more or less as an anti rootkit protection.

This isnt really what i call not being invasive. But really, antivirus make a good work of not being that invasive. Virtualisation software such as shadow user aren't invasive at all, however i'm not confortable with the idea of possibly loosing a file because it's in a alwais rewrite zone. PrevX1 isnt that bad as a mix between protection and invasiveness however i do not like the constant phone home habbit.

 

You're saying that one shouldn't switch off one's brain. Well, I couldn't agree more - but I'm still happy to have GSS that gives control over what happens on my PC.

Not necessarily. I always set allow once for those applications mentioned by you so my list of applications doesn't become too excessive. Again: Using GSS doesn't mean that you can switch off your brain. Some discipline is necessary and GSS is an excellent assistance for achieving this.

This is done by RD even if you allow an application to be executed by AD. This means that you have effectively TWO warnings.

See my remarks above. And - what's your alternative?

You may be right. But I still don't understand why GSS shouldn't defend against this new type of malware. Of course, it will be still YOU who has to make decisions about which applications to execute and which to block. No HIPS can make this decisons for you - they can only provide you with all necessary information to make a well-founded decision. That's exactly what GSS is doing for you - and it's doing that in an excellent way.

 

Do not get me wrong.
I absolutely love what GSS does and am in accord of 90% of the way it work, otherless i wouln't have buy unlimited licence and spend that much time in this forum.

I also beleive you have the rigth to your own style of protection, yet i should have the rigth and the tools to accomplish mine too. All i wanted is to suggest a better interation between the two product. How this can go against your will ?

What I hopped is that sooner or latter GSS can be used even by ppl who do not understand why is it bad to have 5 different IE *searchbar*. "They can move it out of the way and close popup if they found it too anoying".

As you said no one should turn their brain off, yet you'll reconise that somone is less willing to learn about something if it only anoy he more than what he was preventing. Spyware are anoying because of popup, HIPS can be anoying for the same reason. Replace a bad thing by a less bad thing isnt really the best one can hope.

THe ammount of information you need to know depend of each person.
For me i have found that program A starting / executing program b .... etc is more an hassle than a real source of information.

My first line of defense would be some knowlege, a brain, sysinternal's freeware such as autorun/process explorer (and if thing goes really bad regmon/filemon), different anti-spyware tools such as cwsshreeder winsockfix , etc

Then i have a router and good Av for confirmed thread. Then come GSS: In my setup, the main purpose of AD is not to warn about application XYZ but to be sure i will not get stuck with hard to remove driver / rootkit and also to spot suspect application trying to kill antivirus etc. RD limit the damage to registry and prevent program to autostart.

As you see one can survive even while disabling what i consider the most invasive part of AD. All i wanted is to keep that setup and maybee implement hashcheck (it's alreadin in the exe) to RD

 

f3x,
Just to clarify on this feature request about the hash check, at what point(s) would you consider it necessary for the hash to be calculated (or re-calculated) and checked if it were being used in the RegDefend context ?

You may wish to consider that some registry operations happen very frequently so adding a hash check on the running executable for every "hit" against a rule could be quite expensive in terms of CPU

To illustrate this using an extreme example, consider what might happen if an application rule for the executable '*' was created for "Allow" on "Read Value" and "Read Key" for the key HKEY_CURRENT_USER\** and the value *.

This rule would have the effect of logging all HKCU Read operations in the GSS Log tab whilst it was left enabled (which probably wouldn't be too long...), now in this instance you would have to consider quite carefully exactly when the expense of a hash compute and check would happen.

The other thing to consider regarding the frequency of the checking is would you be wanting the on-disk executable checked each time or some/all of the executable code sections that have been loaded into memory for each process ?

The idea of "verifying" that the application is still the one that you intended is certainly desirable but translating the simple english request into a rough picture of how you might think it could be implemented reveals that it is not quite so straightforward as it sounds...