Groups, .ghst files, precedence and malware

Something I haven't checked in terms of security...

• can the .ghst files be deleted while the program is running ?
• can they be overwritten with a *new* set of defaults ?

• what happens if malware writes a pre-created .ghst file into the groups directory that gives it permission to do its nasty business ?

• if there is a collision between definitions in 2 different groups which one takes precedence

- the allow or the deny ?
- or it is based on the group load ordering ?

​

 

The .ghst files can currently be overwritten. However RegDefend doesn't read the .ghst files except on load, so the malware wouldn't be able to get Regdefend to load them until next reboot, in which case the malware wouldn't be started anyhow due to it being blocked from autostarting.

There is a precedent to the .ghst files, the order you see the groups listed is the order in which the rules are checked.

 

Jason,
I can't say that I agree with your assessment of the risk, I am not arguing that there is malware out there today that uses the technique below, I am arguing that your security tool cannot afford to overlook the obvious. PrevX could always return the favour and write a regtest mark 2 that disables regdefend without very much effort

The simple scenario where your assumptions don't hold water is where a trojan'ed program installed on the computer by someone that wants to use the functionality. It doesn't need to survive reboots because the end user will be executing it... The first time around it replaces the .ghst files and takes a note of when the computer was last booted, once the computer has been booted again and regdefend disabled it then does its nasty work including persistence etc
I don't think it is reasonable to assume that malware writers are not intelligent, misdirected for sure but what I just described could be coded without needing very much skill

In terms of my questions, could you be a little more explicit please

• How is the ordering of the ghost file groups determined ?

• What happens if the same key is defined in more than one group ?
  • you say the order of the groups is the order that the rules are "checked"; does it stop checking after the first match or does it continue so that the last encountered permission(s) are valid
  • if it doesn't stop at the first rule found, are the permission changes cumulative from the defaults or does each rule apply its settings in full ?

And of course the enhancement requests

1. An option to specify that newly created .ghst files or .ghst files changed outside of the user interface should not be used by regdefend until some human interaction accepts them. This needs to be an option so that regdefend can be rolled out to multiple machines using a generic configuration and then have the option enabled afterwards...
2. Do something to stop the control files being hijacked or deleted

 

My PrevX vulnerablity test was just that, showing that their driver was vulnerable to a specific kind of DoS attack. I am sure they could most likely find a way to disable RD if they wanted, as could I their product. It takes time and skill to do this though. For a hacker the time taken to do something (if he is capable) has to be able to match the reward.

Any program which doesn't somehow validate all input from the user is vulnerable to attack. Last I checked, pretty much every security application doesn't do this. Hackers typically won't target any security system which isn't mainstream enough, and I doubt that RegDefend will ever be mainstream enough for a trojan author to want to target it, the same as for most security applications.

So why does this example malware need to be in the registry autostarts if the user executes it every reboot? There are many ways to defeat such things if they occur, but the hacker still needs to invest time to reverse engineer structures, etc, to do this.

RegDefend isn't an "all in one" security program like say PG or PREVX. It protects the registry, using minimal resources to do so. There are other vectors of attack that RD will never be covering that you do need other software for (if you want). In essence if you are paranoid about people attacking RD (and for that matter nearly every other security app you have) you need to invest in other software which performs the "protect other apps on my system" role. I will be bridging some of the gap in future products/releases as I do think there is room for optimization.

Groups are listed by alphabetical order. It does indeed stop checking after the first match is found. I do like the suggestions you made, I will probably add them in a future version (along with a few other things like encryption, etc).

 

Indeed they could, I just outlined a way to disable RegDefend using no more than a filesystem write, something that could easily be done in ActiveX

Indeed this is the problem for all applications and especially security ones, but what I have described is a simple method to effectively disable RD

Jason, as you well know my example was to illustrate the point, it was to show that the "traditional view" that you must have registry entries to persist across reboots isn't always true. All it would need is 2 executions to get the machine under control, and there are quite a few programs that ask for a reboot after installation at which point you will be running it the 2nd time...

I do hear what you are saying but in my opinion my example here doesn't fall into the category of needing an external nanny, obviously there is a middle ground from your comment below. I don't really consider PG an "all-in-one" security program, it is a building block (a really useful one that performs an important function).

If you truly do think that RD shouldn't need to protect its own files from modification then there is a market for a FileDefend product as well...

That is great to hear, all I am looking to do here is provide feedback so that your have more input as you consider the further development of your product (as that benefits everyone). And of course to stimulate further thought and discussion

 

Jason,
Having thought about this further, I think that my main objection is that currently RD makes no effort at all. The argument that you won't be targeted simply because you are not mainstream is an invitation to get targeted in and of itself (especially whilst it can be done trivially). PG did get some attention in the hacker community even though it wasn't mainstream and as the author it would be reasonable to expect that they might at least have a look at your latest offering

In terms of the type of protection I would consider minimal for a security application so that due dilligence has been observed, I would expect there to be at least some simple check/verify of your configuration files (even if it is infrequent) whilst the application is running

It would be a suprise to anyone that RD raises no alert if its definitions files are removed or changed outside of its control whilst it is running and that it could continue running for days/weeks without viable configuration files on disk in the event of a restart and that the valid configuration information that was in memory would then have been lost... when it could potentially have been written back to disk.

A periodic poll of the files (hourly?) could easily check that the files are still there and have the same size and timestamp, an even more infrequent poll (daily) could compute a checksum
If the filesystem was NTFS you could register to be notified on directory/file changes so you wouldn't even need to poll

Additional .ghst files being dropped in the directory is still a concern and if NTFS was being used then the registration for change notification on the directory would cover it, otherwise periodic polling would be required

It wouldn't be too hard to persist your checksums and file timestamp information in the registry so it could be checked on the next startup, doing a simple crypt of this information would make it a tiny bit harder to change when RD wasn't running (which shouldn't be very often anyhow)

Please note that I am *not* suggesting you do anything OTT like kernel level file locking or intercepting writes etc, just the basics that can be done easily and without adding much complexity or runtime overhead

 

gottadoit,
I second your opinion that Jason should do something to protect the RD configuration files. They should be locked whenever RD is running. I'm not sure if this can be done since I'm not a programmer.

In the meanwhile, another suggestion to protect these files: Give full access rights for the /groups folder solely to your admin account, but only read access to your user account. Thus, whenever you are logged in your user account (which should be a matter of course) no malware can alter or delete the RD *.ghst files.

Of course, any changes must be done with admin rights - but let's face it: That should not happen very often. And for the installation of new software that might change a registry entry covered in one of the *.ghst files you must be usually logged in as admin anyhow.

This idea came to my mind today, so I had no opportunity to test it for a long time. But I see no reason why this shouldn't work.

 

Hi Gottadoit,

Since I cannot run RegDefend (or ProcessGuard) on my far too old W98SE system, I am not the right person to make any comment.

But the mention of a FileDefend product triggered my interest
It ain't no secret that I have sometimes posted about file-integrity-checkers
Most file-integrity-checkers are on-demand checkers. But even in that case, if you run them frequently, they might inform you about changes.
So why not add those files about which you were talking about, in the database of such a file-integrity-checker. There are several file-integrity-checkers available, free and not free. To name a few: Adinf32 (recently I posted a thread about it), NISFileCheck, the CRC32 test in TDS-3, etc etc.
There are also file-integrity-checkers that run in real-time or near real-time.
For example FileChecker from Javacool.
As far as I understand they work not pro-active, but they will warn you quickly in case a file has changed; so you might add those files about which you were talking, to their database.
And now about a real strong pro-active FileDefend program.
There is hardly such a program (except very expensive one(s)).

Apologies for going too far off-topic !

 

FanJ, thanks for that hint - I will try these programs.

Well - I tried that one. I had a CPU load of 50% on my Pentium 4 3.4 GHz ...

Yes - but what do you think of the proposal I made in my posting above? It's perfectly clear that the crucial problem is in the fact that probably more than 95% of all Windows users ONLY use their admin account, and in these cases my proposal doesn't work, of course.

A great new business opportunity for Jason!

Not off-topic, IMHO. There is indeed no protection for the *.ghst files, and that's worth a discussion.

 

Hi,

I think that gattadoit's request has lots of merit. It seems far more reasonable for a security package to scan and verify its own files (which are few in number) every hour or so, as opposed to a user having to install yet another file verification package, and then have to determine which folders/files need to be verified, and how often they should be verified. In my opinion, a security package that cannot protect itself, would have difficultly claiming that it can protect others.

Rich

 

Hi Thomas,

I think that I'm not the right person to answer that simply because I run only W98SE


BTW, for those using RegRun alongside RegDefend, you might consider to let the File Protection option in RegRun watch the *.ghst files.

Cheers, Jan.