Protecting WFP

Starrob: I don't know if PG protects against static dll injection specifically, but it's checksumming feature would pick up that the executable has changed. Your firewall should pick that up, too, along with any integrity checker (RegRun's would offer to restore a backup of the file, and I believe offer an option to scan it for infection if you have the AV coordinator set up.) Of course Prevx would intercept the attempt and prompt you to allow or deny. I'm sure there are plenty of other apps that would detect these things, too, in varying ways.

It would still probably need to execute something to do the static injection in the first place, in which case you would have to allow it with PG. With everything that something like that is going to do (including all the other actions not mentioned here), you would have to make a lot of allows with PG and/or Prevx. These may not stop every action taken, but they should stop enough to keep you from getting infected.

 

Yes, it would pick up that the executable changed but not that a dll changed. The firewall may or may not pick that up but even if it does the not too savvy might let it through anyway since it would just look like (let's say for example it was a trojanized dll of internet explorer) that it was simply internet explorer asking for access again. If access was blocked then the page would come up blank. People might not investigate this further.

The only defense then would be a file integrity checker that checked the system dll's (and not just the executables) and/or the execution protection of PG.

Just how many people have a file integrity checker or know of the need for one. Even if people have one just how often do the check their system with a file integrity checker. Their credit card info or personal info would long be gone before most people check.

The point is that PG defenses are somewhat thin here and other programs have to be utilized to protect against this. The problem is not so much that PG is thin in this area but that most users do not know it is thin in this area.

......even though it is not as big a issue as of yet because it would most likely require very good skills to write a program like this that would be effective but I imagine at some point someone would give it a effort.




Starrob

 

I guess it depends on whether it does the check before or after it's loaded it's DLLs.

I think my case stands, though, that to cover all these different "vectors" of attack, you'll need a good layered defense. I don't know about you, but I DON'T WANT PG to become an all-in-one security tool with full on registry, file system, and system setting watcher. I have other, more specialized, tools for those functions and don't want the bloat that those would bring to PG. The case you are making is for convenience, not security.

PG was meant to be an important part of a LAYERED security setup, not an overall security suite. If you want an app to watch against file based attacks then I recommend Prevx, it ultimately covers a lot of bases that PG never will, it has a free (and an inexpensive paid) version, and I have found it to play well with PG. There are also plenty of good registry monitors out there, some free and some paid. You can take your pick.

I think I'm starting to see where you're going with this, and I will not continue to split hairs. Best luck to you with your endeavors, starrob.

 

PG does not have to be a full on registry, file system, and system setting watcher. The solution provided by gottadoit would probably work.

Solution by Gottadoit:

"That is one of the key reasons it would be really good if PG could offer some checksum protection on at least the key handful of system DLL's that provide file, disk and memory access."

located here:https://www.wilderssecurity.com/showthread.php?t=57384&page=2


The point is mute, though, because DCS has already stated their position on this. Which is OK. There are more than a few solutions to this and there are other vendors already building protections against this into their products.

This is not a easy attack to pull off anyway but I feel that over time as Microsoft and security companies closes more and more holes someone might resort to this type of attack.

Well, I got my answers here....I am off to new concerns. Like shopping for Christmas. I hope everyone is having a wonderful holiday season.


Starrob

 

HI

After reading this I am confused. Starrob? are you saying the XP built in
File checker is not good enough? sfc.exe
I don't see how it couldn't be. All you have is a cashed folder and an exe.
How can it be disabled if you always have a good copy of both the exe and the cash folder?
Even if a file is dll injected, and you replace it daily, won't that be enough?

Maybe the catch is you have to be logged as ADMIN?

I also have at times visited those dark sites such as rootkit dot com
and yes there is a ton of good info at some of them.

I think a link to MS's site on WFP is a good starter point for some of the guests here that don't know much about WFP such as me. lol

http://support.microsoft.com/default.aspx?scid=kb;en-us;222193

Bruce

 

Starrob,
I do agree with Notok in that I don't want to see PG become bloatware
I was looking at PG with the view that it is my inner layer of defence for System Call interception (at least for the critical/security related areas).
That is why I was suggesting that they also intercept the calls used by Windows Update and why I was asking about some verification on use or load of certain key dll's

I would (and do) have other products in the "other/outer layers" and if something got past the other products (some of which probably don't hook system calls or do so in a manner that can be bypassed) then a PG alert would trigger

After thinking about this for a while I have realised that its a silly idea to think of PG in this way, its just another app thrown into the mix. I'd still like to see PG grow some configurability again so that a global mouse hook could be enabled for a program without having to also allow the same program access to other types of global hooks but that is a bit off topic for here

NB: You are certainly giving the tree a good shake on this one...

 

No, it appears that Windows built in file checker was not built to be a security tool. A virus has already been developed in 2003 called WinXP.Che (See http://www.virusbtn.com/magazine/issues/pdf/2003/200306.pdf) that utilizes the techniques that could possibly be used to replace dll's.


Starrob

 

Well, it has been a good topic and gave more than a few people something to think about. I prefer these type of discussions rather than "Is product A better than Product B"

Thanks for teaching me a few things Gottadoit and Notok. I was not aware of certain things until you called my attention to them.



Starrob

 

Ok but even if the DLL's are replaced, does it matter if you have a back of up the cashed folder? You could keep replaceing them all day if you wanted to for continious protection.

Bruce

 

I guess the extremely paranoid could keep replacing their system dll's all day but since there are so few threats that currently try to attack this way, my guess is few would bother.

The biggest threat from this is someone figuring out a way to use the basic concept in a zero day attack and catch people with their pants down because everyone is thinking of the threat as in the far distant future.

The way I look at things is I see people like Microsoft doing things like buying Giant. Microsoft and other software vendors focusing more and more on security.....doing things to render current malware obselete. If you were a malware writer then what would you do? I would be looking at exploiting things that people aren't thinking about. I started this thread mostly so people will at least think about it and be aware some type of attack this way might be possible.


Starrob

 

Bruce,
I think the issue is simply that any program running with administrative privileges can potentially use the same API's that are used by Windows Update and replace system dll's in a way that won't cause any issues from a standard OS point of view ....

If this hypothetical backup of the cached folder were to exist, what would be checking that it is the same as the "real" cached folder and how often ?
Once a trojan'ed dll is loaded it could easily intercept calls to read the file from disk and return the original contents to stealth itself

It is our own fault if we continue to login as administrators and make it easy for malware writers to attack us...
On the other hand the "shatter" attack can be used when you are a non-admin user to get code running in an administrative context so its still not a foolproof environment

Maybe a linux/*bsd desktop running WINE is the answer or even better a vmware copy of your favourite 'doze O/S in a read-only vmware partition with datafiles being stored outside the vmware container. That way you could get exploited until the cows come home and it would be hard to make it persist across sessions

Hopefully I haven't misunderstood the point you were making

 

This is a point that I share with Notok. And in all the examples I have read so far, it still seems like there would be an opportunity to stop/prevent the execution from the very beginning. In which event all the effects of the replaced program/system dlls become null and void. So perhaps a more important question is if the user stops execution how else can program/system dlls be replaced?

While this is not an answer to the above question, I think the most likely event of any type of infection occurring with behavior based security software in place is more often than not the fault of the user.

Security programs and user decisions are going to be flawed. Either one can not be expected to do everything right. But a good balance of both can prevent a lot of infections.

Thinking of the more "advanced" means of infection keeps most of us on our toes. But reality shows that if we are alert, informed, and have security measures in place we are much less likely to be infected. Yet alone by some of these "advanced methods" that we talk about here.

 

I hope everyone was given things to think about in this thread.

"A mind is like a parachute. It doesn't work if it's not open." Frank Zappa

 

Yes hypothetical backup of the cached folder is in your System 32 folder.


Bruce

 

Can not the WFP be restored from the Windows set up disk also?


Starrob

 

Bruce,
I'm not sure I understand you, that is the (standard) location of the backup made by WFP (assuming you are referring to system32\dllcache)

I thought that my comments were about using API's to replace files in that location with "nasty" ones, which would disqualify it from being a reference area

 

Whilst the argument is sound, my point is that it would be good to be able to execute arbitrary programs from publicallly available sources and think that they don't have a way of infiltrating themselves into the guts of the O/S

Try and explain to the average user that they should never download any programs from tucows or download.com to try because you aren't sure of their origins...
I don't think I'd even buy into that argument myself, let alone be able to sell it to people that I help and/or support

 

Just as an aside, I ran across another program that appears like it might offer more granular control than PG...

I haven't tried it out yet, so it might not be anything special
If anyone is interested have a look at AntiHook at http://www.infoprocess.biz/antihook.aspx

 

Was having a bit of a browse around and found this old article on how to make the WFP hashing a bit more secure by changing it from the default of using dynamic hashing to fixed hashing

Have a read of http://archives.neohapsis.com/archives/vulndiscuss/2002-q4/0051.html

This could potentially be used to avoid the issues discussed so far by stopping arbitrary programs replacing DLL's using an O/S supplied method on XP Pro

It might be painful every month when service packs or patches come out, but it seems to have some potential.

Without putting in the effort to actually find out how the Windows Update executable works it is hard to say if the static hash approach would simply be updated during the service pack application or if the static hash would block the changes

 

I found this part interesting:

"There is no reason to
automatically trust any Root CA when it comes to code signing. Windows File
Protection should never have been designed to trust digital signatures on
software based on certificate chains, WFP should trust only specific
certificates the way that WinTrust operates. "

 

When using winxp sp2, we noticed that it has a new functionality about "software restriction policy" which can help wxp2 users manually setup to protect the integrity of DLLs relate to an program. Is this revelant to wfp?
I am not sure I understand how to use this new protection feature properly when set it up; appreciate much any instructions.
Thanks.

 

Quoting a small section of Using Software Restriction Policies to Protect Against Unauthorized Software:

Software Restriction Policy Options

This section discusses the various options that influence the behavior of a software restriction policy. These options alter the scope of enforcement behavior or the Authenticode trust settings for digitally signed files.

Enforcement Options

There are two enforcement options: DLL checking and Skip Administrators.

DLL Checking

A program, such as Internet Explorer consists of an executable file, iexplore.exe, and many supporting dynamic link libraries (DLL). By default, software restriction policy rules are not enforced against DLLs. This is the recommended option for most customers for three reasons.

-Disallowing the main executable file prevents the program from running, so there is no need to disallow all of the constituent dynamic link libraries.

-DLL checking results in performance degradation. If a user runs 10 programs during a logon session, the software restriction policy is evaluated 10 times. If DLL checking is turned on, the software restriction policy is evaluated for each DLL load within each program. If each program uses 20 DLLs, this results in 10 executable program checks plus 200 DLL checks, so the software restriction policy is evaluated 210 times.

-If the default security level is set to Disallowed, then not only does the main executable file have to be identified to allow it to run, but all of its constituent DLLs also must be identified, which can be burdensome.

DLL checking is provided as an option for environments that want the highest assurance possible when running programs. While viruses primarily target executables for infection, some target DLLs. To ensure that a program has not been infected by a virus, you can use a set of hash rules that identify the executable and all of its required DLLs...."

Nick

 

Here's another quote from the same link:

Scope of Software Restriction Policies

Software restriction policies do not apply to the following:

-Drivers or other kernel mode software.

-Any program run by the SYSTEM account.

-Macros inside of Microsoft Office 2000 or Office XP documents.

-Programs written for the common language runtime. (These programs use the Code Access Security Policy.)

Nick

 

Wow. long thread... good reading...
But let me add a new tool to the mix...
Tiny Personal firewall - a powerful application sandbox and a decent network firewall
www.tinysoftware.com
It protects system services, registry, the file system among other things