MD5 for dlls

I don't fully undrestand Jason, so please let us discuss this in more details.

Usually PG is refered to as a protection layer for software which you continuosly run, such as firewalls, and on-access AV. But other threads, and my own experience shows that it could be also very good to protect software which is not running continuously such as TDS, Ad-aware, on-demand AV, browsers, regedit, etc. Some of these software don't need any Allow privileges, but let's talk about the others.

You will most probably have a freely readable list of privileged software some of which is not running. A troyan could possibly (temporarily) overwrite one of the privileged executable files and execute it with all the privileges you provided to the original. The coming MD5 for executables is intended to stop this privilege stealing. But I see an other way of privilege stealing, namely (temporarily) overwriting dlls of not-running privileged sofware. Note that the troyan dll don't need to provide the original features of the overwritten dll, it is enough to provide some initialization method which does the troyans job - it kills all security software including itself. Then the original troyan process could have fun.

Although each executable could probably defend from non-authorized dlls, 99% of them is not doing it. They simply load and execute whatever they found in the dll files. This is the very reason why all modern personal firewalls (look 'n' stop, tiny, outpost, kerio) all check the dll checksums before assigning the privileges to an application.

Is this a hint to some new feature in the new PG? Will PG intercept an executable which does nothing else but overwrite a non-loaded dll file, and then execute a privileged application?

-hojtsy-

 

What I am saying is that an EXE needs to run first which overwrites a DLL file on your hard disk to perform this sort of thing you are talking about. So when this malicious EXE tries to run you have the option to stop it with PG blocking EXE's. If you are talking about when an EXE gets past that protection due to the user letting it through for some reason, then yes it is a possibility it could overwrite an existing DLL. If the new DLL which deleted an existing one doesn't include all the original functions the DLL had there is a good chance the process might close or crash, depending on how the EXE linked to the DLL's.

So basically you either have to write a DLL which includes as much functionality as the one you are replacing and then add your malicious code to it, or write a DLL which is accepted by an application, ie plugins. You can for instance write DLL's which Internet Explorer uses and will load in certain circumstances. I don't think we have seen any trojans overwrite an existing DLL and not have an EXE present afterwards, most inject their DLL's using methods that PG blocks.

These sort of attacks are possible but are extremely rare, and given the fact that PG can stop the HOST process from dropping the file in the first place, you already have good protection I think with the next version.

Hope that explains it a bit better.

-Jason-

 

I always though of PG as a protective measure against software which you already choosen to execute: of course you don't need protection from software which you don't execute. Instead I considered PG to guard that running un-privileged software is unable to kill/stop running privileged software, which is exactly what could possibly happen here.

I disagree. Let's put examples:
Ad-aware uses aawhelper.dll, which exports 10 functions. TDS uses advscan.dll, which exports 3 functions. I can also provide the function ordinals and names, the list is readable with freely available software. The troyan replacement dll needs to replicate the ordinal and name of those functions, and nothing else, the functionality is not needed. Upon call of any of those fake functions, the troyan dll kills all security software including the host process.

I already heard on this forum that we don't need MD5 for executables because there has never been a trojan which kills security software after faking to be a legitimate privileged software. I like the preventive thinking of DCS: it considered executable MD5 important. But checking only part of the exetable code (namely the exe file), and not checking the second half of the exectable code (the dlls), is like making an MD5 from only the first 1000 bytes of each executable and then argue that it is complex to tamper with the other part of it. It only gives false feeling of security.
Jason, what is your opinion of the dll authenitcation of look 'n' stop, outpost and other firewalls? Is it completely unnecessary even in those software? Was it wasted effort? Would you prefer a firewall which assigns privileges only after checking dlls too?


FanJ,
Could you please point me to a resident file-integrity checker which also checks dlls?

-hojtsy-

 

Hi hojtsy,

Yes I can, but it depends on which version of Windows you are running.
If you are running NT, 2000, XP, then there is the free FileChangeAlarm from Albjan (formerly mod here at Wilders for the formerly NISFileCheck forum section; see the archive).
Site:
http://www.capimonitor.nl/File%20Change%20Alarm/_loadurl.php?filename=filechangealarm.php
Alas, NISFileCheck and FileChangeAlarm are no longer maintained.

I myself don't have experience with FileChangeAlarm from Albert: I cannot run it because I only have W 98 SE (for that same reason I cannot use PG).

Almost all, if not all, resident (REAL-time) file-integrity-checkers need NT-2000-XP.

FileChecker from Javacool is a near-real-time file-integrity-checker.

I myself use three on-demand file-integrity-checkers, plus RegRun for the registry.

See also for example these threads:

1.
http://www.wilderssecurity.com/showthread.php?t=22247

2.
http://www.wilderssecurity.com/showthread.php?t=22318

 

I have Win2000. That selection of software seems somewhat, hmm, poor.

Filechecker and FileChangeAlarm seems to be no value against an intentionally malicious software. Filechecker alerts a few seconds after the file change succeeded, and FileChangeAlarm immediately after the file change succeeded, but none of them stop the changed file from execution. In fact the changed file could already be executed before FileChecker even notices, and it could easily kill FileChecker before it could send an alert.
These protection software is only usefull agains lame trojans from years back.

Isn't there a decent integrity checker which stops changed exe/dll files from loading until the user confirms the change? This theoretical software would act like a helping layer to other (privilege based) security software, just like PG.

-hojtsy-

 

I partly agree and partly disagree.

Maybe indeed, yes, they cannot stop it !
So the nasty could have done its thing...

But there comes your backup-imaging program peeping around the corner.
At least you know now that some file has been changed; so, if you like, return to a previous backup-image.

Eh, are you sure?
Doesn't PG have the possibility to protect FileChecker?

What about InCtrl ?

What about to pay several thousands of dollars for a program from Alfa-corp?

 

Gee, hojtsy - no "Thank you, Jan for trying to help"?

Try Google - at least when you tell them that their selection is "poor", you won't won't seem so damned insensitive and ungrateful. Pete

 

FanJ, and Spy,
I respect your intentions, and not intended to blame the bringer of bad news. Sorry if it seemed so. I could say that thanks for pointing out the lack of sufficiently secure integrity checkers. But that doesn't change that this is bad news.

No it does not. That is exactly what this thread is about. A trojan could replace a privileged exe or a dll of a privileged exe, start it, and the dropped trojan component will get all privileges to kill FileChecker and others.

I don't know InCtrl, but I will investigate.

 

Hojtsy, Jan does at least deserve a thank you for his efforts, although the software might not meet your specific requirements

Regarding your other comments: There is always a problem with any application monitor or sandbox with regards to user knowledge.
When a user is asked whether an application is asked for an allow privilege, how would a none savvy user react? Probably say "Allow" without further thought or "Not Allow" and stop an important update. Now think of adding .dlls into the equation - I can imagine this causing many problems not just for users but the software company's support staff.
Automating this task is difficult, although I believe Abtrusion Protector does have an initial automatically created database of .exe's and .dlls but this still relies on the fact the computer must be "clean" before the process is started.
After installation the user must decide - I see this as a high risk problem.

At least MD5 checking greatly reduces the risk of a none running .exe from being hijacked or changed albeit the novice user can still allow malware but hidden changes to an exe will be seen.

If a running process is protected by Process Guard then .dll injection and many other exploits are not so much of a problem.

There is no such thing as 100% security, IMHO all we can do is try and reduce the risk.

 

Hi hojtsy

i understand your concerns, but try to understand mines.
I want the maximum of security, not just an AV and a FW, but if my computer's ressources are totally used to protect itself (same pb as "to eat for live, and not to live for eat") it's even better to not have a computer at all.

So i think you get my point, and as said Pilli, we want to increase our security as much as possible without however locks up our system, we have to even things, not to load everything and afterwards to check if our computer is usable or not.

To check MD5 checksum of executables wanting to start is a strong security layer. If you are a "power user" regarding security and have a bare security skill, you won't allow something which shoudln't be allowed, so no problem.
If however you allow mistakenly something to run, most threats (In The Wild) simply try to terminate security apps, that PG with his process protection prevents. Some other use globals hooks or even try to inject threads or DLL, PG once again, prevents all of that.

But ok, let's assume it wouldn't take so much ressources, and let's take a look at it :

The fact that you are requesting DDL checksum is that PG is so strong that the only left way is to attack not running DDL on the HardDrive.
This, however, is not as simple as you have said.
DLL are evolving between software updates, and a trojan or a worm using such method would be broken as soon as the next update, which is not a good tactic, trojans need to be able to sleep months if needed, and strike only when the author needs them.
To modify common DDLs isn't so easy too, they could crash standard apps and give clues to the user that something is wrong.
Moreover, if you aim a particular DLL version and that the user has an old version of his software, it won't work too.

I think DLL modification is not a reliable way to stay alive as long as whished, even a simple windows update could break your trojan.
A DLL injection thought will always works, until PG is there of course

The most interesting software to aim are security softwares, which are anyway constantly running on my comp so NOT vulnerable to that.

Theorically it is possible, so I understand your concerns, and if it was existing a reliable and light way to add this feature i would be for it, as a *bonus*.
But for now i rely on many security layer as possible to increase my security to tend to 100% without however to be 100%.

I have replied as you, not to blame anyone or start a personal war, just to give you my point of view, after i have read yours.

regards,

gkweb.

 

Thank you all for your efforts.

Now can we go on to business? I understand that there are certain problems with both the implementation and the usage of dll authentication. But interestingly several personal firewalls already succeeded to implement this feature, and also present in a way sufficient for the user (and software vendors if you like). This feature is already demonstrated to be both neccessary and possible to implement, in these firewalls. Do they hog your resources unacceptably? Gkweb, aren't you using look 'n' stop?? That piece does dll authentication on each privileged software!

I don't care about users who press Yes without reading dialogs. There is no possibility to protect them, so let's not waste time trying. Executable MD5 is quite usefull feature, but it does not protect you from specific attacks agains PG, as a specific attack would use the weakness of PG: dll authentication.

I still think PG is a masterpiece and a valueable tool in my security arsenal. That is exactly why I purchased it. But as with all tools in my arsenal: I always challange it, try to defeat it. I am a middle-class programmer: if I can find a way to defeat it, hundreds of malware writers can. Should I keep quiet on it? Do you think they would not find it out by themselfs? Now they do dll injection, soon they will scan for PG and do dll hijacking.

-hojtsy-

 

Hojtsy wrote:

If you did find a way to defeat PG, the accepted method of dealing with such an event would be to make a submission to the programme developer so that it could be tested and corrected (if possible) before stating such a problem in public.
As far as I am aware no one has defeated PG's protection so far but if someone did manage to I am sure DCS would correct the problem as soon as feasibly possible

 

About firewalls, i use sometimes both Look'n'Stop and Outpost, i even tried NPF 2004 (not all at once of course).

Look'n'Stop uses a basic DLL verification, regarding DLL which connect directly to the internet, it does not check all DLL loaded into the executable, this is why too it fails leaktests such as PCAUdit last version, because the DDL injected does not seems to do the connection itself.

However, Outpost, regarding DLL, checks all modules loaded when an application ask a network access, and warns the user of new components.
I agree that this method _for network accesses_ doesn't consume too much ressources and is reliable, so at this point i would agree with you

But the problem is that we are not talking about network access, but about ANY executable launching on our system
There is not so 300 DLL max to check, but a LOT more, and not at a particular moment (network access) but at every executable launch, i think it would lead to a big slowdown at startup (just imagine how much DLLs are loaded).

Abtrusion Protector already tries to do it, but from AP users experience, there is constant HDD activity even when the user does nothing, because there is a lot of DLL involved in the normal Windows running, AP _is_ slowing down the computer. May be you could accept it, but not everyone would do.

As the exploit is possible, the protection would be possible too, but does it worth to add it regarding all the issues it can have ?

IF there is a light and reliable way to do it, as i said, i would be for it.
But with methods we know, this seems a bit difficult, if moreover not everyone has a 2Ghz computer

But if you have ideas, it cost nothing to explain, it could anyway be interesting or usefull.


regards,

gkweb.

 

GKWEB has hit the nail right on the head. The reason there is constant Hard Drive activity with something like Abtrustion protector which does check DLL's is because some programs LOAD and UNLOAD dll's many times a second, requiring you to continually checksum and read files from the hard-drive.

So yes DLL loading is a possible threat, but PG can block it from happening. As I have stated an EXE needs to drop/replace the file and that will already be taken care of by PG's application checksumming feature. What you are asking for is another layer on top which isn't really necessary as long as you don't just run every EXE without precaution. Whilst DLL's contain executable code they are 100% worthless without an EXE, the reverse is not the same, EXE's can be dangerous without any added DLL's. So the main aim is to block the things which load DLL's, which are EXE's.

Until there is a way to checksum DLL's without a massive performance and useabliity issues, we probably will not be adding DLL loading checksumming.

With the next version of Process Guard, even on a vulnerable system, you wouldn't of been able to get the Blaster worm, and many worms like it, which execute silently without the user intervention.

-Jason-

 

Couldn't agree more, Pilli. That's precisely why I'm sticking to my guns on the "Minimalist" approach to PG use - unless a program that you absolutely must have or use on your computer will not run correctly without granting it some kind of "Allow" privilege in ProcessGuard, do NOT grant it ANY "Allows" simply to get rid of log entries!.

Furthermore, all four "Protection Options" must remain checked at all times and not defeated by putting checkmarks in anything in the "Options" section for any individual app unless the same criteria above apply!

Not following this advice will - somewhere down the road - result in you defeating PG's main purpose yourself.

Amazingly enough, I quite agree with you there (with the proviso that the entire thrust of this forum is to teach people how to go about learning to protect themselves, as well as keeping both experienced and inexperienced up-to-date on new threats).

However - having said that - I'd like to ask you this:

If you're wanting to talk about, or assume that we're dealing here strictly with people that know what they're doing, protection-wise, then how do you envision this dll hijacking ever getting a chance to take place (delivered to the experienced ones' computer) to start with?

We're NOT going to kindly open an email attachment while un-protected that contains it, we're NOT snarfing up bootleg software on the Internet that could contain it and we're SURE not going to d/l and install it ourselves willingly because someone decides to call it a "leaktest" or a "security scan" of some sort!

Without a guaranteed brand-spanking new, undetectable-by-any-means-currently-available delivery mechanism, the entire "threat" of dll hijacking is a non-issue to start with.

Well, they haven't, yet , now have they? If nothing else, this thread was both useful (and FUN), because at least you did make everyone think about such a scenario!

But I don't really think they should drop everything else and concentrate solely on this (as of now) imaginary scenario.

Have a great night, everyone! Pete

 

You are right, my scenario needs the user to manually start a single malicious exe.

As far as I know each and every protection layer of PG 1.3 comes into picture after a malicious executable is actually started. It may be started somehow automatically or the user is tricked into belive that it is a present for the great an glorious people of Troj city, and so the user intentionally start it. He will click yes if he is asked: "are you really want to start this unkown application"?
But the half-trusted software will only run with limited privileges, firewall should stop communication, PG should stop process killing.
You talk about two kind of users: one opens every mail attachment, the other only starts executables which was purchased or securely downloaded from a proven trustable source. I see a whole transition between these two extremes: I may open a mail attachment which is sent by my friend, or a freeware executable which was downloaded from abcdefg.com. Have you never done that? Then you don't need PG, you just need some simple tool which intercepts files executed for the first time, to avoid tricky automatic execution.

In particular: Do you need to protect you completely trustable softwares from each other?

best regards,
hojtsy

 

@hojtsy

I believe you are right to assume that a malicious executable WILL get executed. (If you never execute applications from non-trustworthy sources you may not need security software at all.)

However, I do not believe that your scenario (malicious.exe replaces DLL with process-killing custom version ) is likely to occur. A hacker will not make the effort to code a custom DLL and then do something stupid like process-termination which will alert the victim. In a real world szenario the following may happen:

1.
Malicious executable creates an additional trojan DLL plus a registry entry which will make an application like Internet Explorer to load the DLL each time it is started.

2.
Malicious executable creates an additional trojan DLL and patches an existing application (like a browser or a file sharing client) so that the DLL will be loaded by the program.

-- You can protect yourself against 1. with a good registry monitor. Looking forward to the upcoming program from DCS. You will be protected against 2. by a firewall's MD5 check.--

3.
Malicious executable replaces an existing DLL with a customized trojan DLL (this is a scenario similar to your termination scenario).

You can protect yourself against 3. and your process-killing scenario by using a full-featured system firewall like Tiny Personal Firewall. But is it worth the hassle? Just try it out ...

Moreover, a firewall with MD5 checking for DLLs will protect you against 3. Sometimes, Windows SFP will protect you (try to replace wsock32.dll).

If there is anything that Process Guard should do (apart from getting stable) it may be considered to create a "white list" concept for internet applications:

Applications that are marked as internet apps within process guard will trigger an alert (not a block!) if they load DLLs (via LoadLibrary, the registry, IAT etc.) which are not on a customizable white list (with MD5 checking).

 

How about this different approach:

Let's imagine a standalone software called File Guard. It intercepts write access to protected files (which will mainly be exe and dll), and only allows write access to listed privileged apps, or after Human Identification. It could also restrict direct access to disk surface to privileged apps. A kernel mode driver could possibly implement this! The newest Tiny firewall already implements something similar.
I would pay for a software like this. Would you?

-hojtsy-

 

I might try it if it had a "trial", anyway - but I certainly don't think I'd need it.

Already have layers upon layers upon layers here - eventually, either something's going "break" the system sweetness I've got going on here, or it'll use too many resources or it'll actually conflict with something I already have.

There comes a point (GASP!) where you're "protecting" yourself against something that the odds of getting affected/infected'attacked by are so miniscule that it's not even worth the effort to deploy something against it - if you keep loading up stuff anyway, at that point, you're WAY into "over-kill" territory (and tip-toeing into "problems" territory - for no good reason).

I'm outta this one, guys - all these mutiple quotes and point-by-point answers are killing me, time-wise.

Bye now! Pete

 

You believe? But, of course, you're not sure because you haven't seen it happen - and everyone from DCS is assuring us (repeatedly) that it won't happen.

(Let's see, I'm going to either believe people who don't really know, can't put forward any evidence of such a thing being possible and are just theorizing [some of whom post anonymously] - or the people who made the program itself, have tested it and who should know what they're talking about. (I'll take "b").

Really? Great! I'll dump all my security software immediately after finishing this post! (Hmm, I might need to keep those parts of it that - constantly updated at all times - I use to scan everything which I d/l - and scan - and install - and re-scan - with.

And, wait! I might also need to keep the programs that keep bad things from happening even if something gets by those other pesky programs! Like SpywareGuard and IE-SPYAD and AGNIS f/OutPost
[to keep me away from places where I can pick up weird stuff like that to start with], WormGuard (although that's one of the ones I scan with), DSOstop2, HTAstop, socketlock [GRC's], socklock exe [PSC's], etc., ETC., ETC.).

Common ground! Amen!

Wait! Are we talking about experienced - in-experienced people again? I don't know of anyone with any security background that doesn't (a) use some sort of registry monitor and a firewall (or aren't you classifying a firewall as "security software).

(Which works in the background, too, helping prevent this threat we're theorizing about!).

That's funny - PG is rock solid, here. Perhaps your check-summing application is tying up too much processor/interfering?

Not without scanning them first - regardless of source (which could be faked) - I haven't.

Yes, you do - as a matter of fact, I think it's one of the prime (yet un-appreciated) advantages of having PG on-board. The "trusted nest" concept falls apart when any one of the applications involved (if you've given it allows over any/everything else in PG) either has a major, un-intentional program flaw during a def or version update - or if it goes flat-out rogue (intentionally bad/malicious).

Giving all programs that you put in PG "Allows" over each other is just as risky as "Allow"'ing anything else (unless you're absolutely forced to and accept the risks involved with full knowledge that it could very well back-fire - majorly - on you at some point). Pete

*See? That was all supposed to have been one post! Later! Pete

 

@Spy

Err ... what's wrong with you?

1.
"But, of course, you're not sure because you haven't seen it happen - and everyone from DCS is assuring us (repeatedly) that it won't happen."

You statement is simply wrong. I have already seen this happening. I can make it happen to you. And DCS will certainly not dispute the fact that you cannot entirely rule out that malware bypasses your virus/trojan scanner and, therefore, gets executed.

I seems to me that you are somehow "off track". Possibly, you have something else in mind? At least, I cannot follow you. Perhaps it would help if you could provide us a cite from DCS. They have probably made their statement in a different context.

2.
"Really? Great! I'll dump all my security software immediately after finishing this post! ... "

Again. I do not understand your irony or what you are trying to tell me. Probably, you DO download and execute software from non-trustworthy sources. And that's exactly why you need your arsenal of security apps.

3.
"Wait! Are we talking about experienced - in-experienced people again? I don't know of anyone with any security background that doesn't (a) use some sort of registry monitor and a firewall (or aren't you classifying a firewall as "security software)."

I do classify a firewall as security soft. Moreover, I know people who do not like (personal) firewalls (e.g., some moderators @ wilders).

Again ... what are you trying to tell me?

4.
"(Which works in the background, too, helping prevent this threat we're theorizing about!)."

Well ... I mentioned SFP because it helps to prevent certain threats. What's wrong with this?

5.
"That's funny - PG is rock solid, here. Perhaps your check-summing application is tying up too much processor/interfering?"

I do not have any problems with PG. What I said is that DCS should first concentrate on the problems which some users have and then think about additional gadgets which may be hard to implement. And it seems to me that they indeed trying to fix any remaining bugs first.

___

@hojitsy

"How about this different approach:

Let's imagine a standalone software called File Guard. It intercepts write access to protected files (which will mainly be exe and dll), and only allows write access to listed privileged apps, or after Human Identification. It could also restrict direct access to disk surface to privileged apps. A kernel mode driver could possibly implement this! The newest Tiny firewall already implements something similar.
I would pay for a software like this. Would you?"

Your suggestion sounds interesting to me because there is generally no need to modify, patch, replace or overwrite exe or dll files (exception: installation scenario). If it were easy to implement such kind of protection it would probably be nice.

In the meantime, an integrity checker will suffice since it will tell you if anything is going wrong. (I believe that a simple alert will suffice because I am mainly concerned about things happening behind my back.)

 

on that note, wouldn't
"generically block/alert on any attempt to gain write(/delete) access to an *.exe or *.dll file"
rather be a task for ...

.
.
.

WormGuard4 ?

(or possibly even TDS-4's Exec Protection )

Andreas

PS. What I mean to say is: I'm sure DCS by now have dll protection on their ToDo lists and it will show up somewhere sooner or later. Sufficient for me.

 

Hi Andreas,

Check out the latest beta..

 

This is the reason why Process Guard does not by default give programs you add Allow access. If one program becomes vulnerable or out of control you don't want it to have control on your other processes. So I agree with Pete on this point, if you can live with the logging that things like this generate, as long as it causes no problem with the program, I see no issue with not giving it allow priviliges.

What most people need to understand is most of the time people who code malicious software hit the easiest targets, why would a coder want to spend so much time trying to get around Process Guard using totally obscure methods which wouldn't work 100% of the time, such as overwriting a DLL file after the user allowed the EXE to run. Unless they managed to find a process to get into somehow which had full allow privileges, global hooking allowed, etc, it would generate a lot of log entries alerting the user.

Process Guard is more than just a tool for the end user, it is a major headache for any malicious software writers. A headache 99.999% of them will never deal with simply because they lack the ability, time or cannot deal with the fact that their software will be extremely buggy under a Process Guard protected system if they manage to get their payload on it. This doesn't mean Process Guard will never include more protection features, as it will. I am just pointing out something that a lot of users don't seem to realize.

-Jason-