ZA PRO 4.5.530 against CopyCat leaktest

--------------------
yes = passed
no = failed
--------------------

Hi there,

for those who don't know i'm the author of www.firewallleaktester.fr.st which is now firewallleaktester.webhop.net (since today )
I asked my question on DSL report forum but don't have many answers.
As i said there, i'm not here to discuss of my website, some doesn't like it, others like it.

I'm updating my leaktest against firewall results currently, and of course when results are quite simple, i just add "failed" or "passed".

But this time i have a problem to say if Zone Alarm Pro passes Copycat or not.
Indeed, at highest settings, ZA failed it.
But, if i enable the "OpenProcess" API detection feature, ZA said me that copycat.exe try to "openprocess" iexplore.exe
At this time, no clue if it's a software hijacking or not, it could be legitimate, and no clue if it's for a network use or not.

So does really the "outbound software filtering" detected copycat ?

It's more like an application monitoring which detect that an executable is accessing an other one (like System Safety Monitor), which isn't that i'm testing.


I discussed of that with other people, and the important point seems to be that if there are no way to detect copycat when it does his internet access throught his hijacked software, then, and only then to catch earlier such exploit with "application monitoring feature like" would be the only solution, and so could be seen as a part of the outbound software filtering.

I want to show real results, and in front of such dilema i want to be as fair as possible with every firewall i'm testing, it's the first time i can't decide by myself, this is why i'm requesting your opinion on the subject.

Thanks in advance for your input.

regards,

gkweb.

 

In my experience, it recognizes Copycat and doesn't let it run, so I certainly think it passes.

 

i hope it doesn't "recognize" copycat leaktest in itself, it would be unfair

but i understood what you mean, and no, ZA network application filtering doesn't see it, as it is also the case for all other firewall.

A feature of ZA enable you to see when a process try to gain access on another process, legitimaly or not, for internet connection or not.
This feature is a part of another kind of protection different than the network application filtering, it's application monitoring, exactly like System Safety Monitor does (but at a more basic level).
So ZA provides you features to increase your security and let you choose what to do, but they are nothing to see with application filtering at network level.

As you can see i discussed about it more with friends since last time, and i have my opinion.
If i would do leaktest with such feature, i would have to do the same for Kerio wich also has incorporated application monitoring feature, and to be fair, i should run SSM with other firewall which doesn't have such feature... But remember i only test on my website outbound software filtering (at network level).

I have finnished to write a page to explain this, normally you could only be able to click on it to read it when the next results will be published, but if you feel to need more information i can copy/past here the text.

At the end, if you disagree, it isn't a big problem, leaktests are available on my site and you can test them all on your system
The worst thing than can happen is that you badly understand results meanning, passing ALL the leaktest is possible without pb with a great software security suite, it's like people who are proud to block leaktest with SSM

But i'm sure it's not your case

 

Well, I followed it like you want, and I believe you should count the extra feature. ZA recognizes and stops the test - that's what matters to me. I highly disagree with you, but it's your site..

 

i understand you, but just consider that point :

you download something you think it's a game (ok may be not you, whatever) then you launch it.
It tries to "launch" or "access" an other process, you trust it, after all, it's a game ? So you allow it.

But in fact it's a trojan that now try throught his hijacked process to access the Internet, the network application filtering is your last shield !
(so application monitoring != network application filtering)

do you see the point i'm trying to explain?

And last point, it's not because "its my site" that i do what i want, i'm trying to be as fair as possible, which new firewall feature makes more difficult than never.

That's not what matters for my site, since i'm evaluating "outbound software filtering at network level", not application monitoring like SSM.
leaktests are "proof of concept", they demonstrate an "idea".

Copycat proof of concept is to use an existing thread within the process, to modify it (not to create one and to add it) and to access the Internet throught it.
To pass a leaktest, you have to win against his proof of concept.
What does ZA ? it blocks the "OpenProcess" API call when Copycat try to access a process, that's all.
Is doing an "OpenProcess" is the concept of Copycat ? no.

So ZA doesn't win at network level against the concept of copycat, it just block an executable accessing another one (even if not for an internet access, OpenProcess != internet acess).
ZA blocks Copycat ? well, fine, what if a trojan find a way to not use the Open Process API or at least to not be seen while doing this ? It will go trought your firewall which can't see and block it with his network application filtering, the proof of concept is still the same, it's still Copycat, but sudently ZA failed it...



So, to sume up my two ideas that i explained here : that you mistakenly allowed an malicious executable to access another one (no concept of network at this earlier stage) or that this malicious executable find a way to access another process without to be seen, your only chance is that your network software filtering can see it and block it, that isn't the case for ZA.

i quote again your sentence since it's often said :

ZA recognize an "OpenProcess" API call, nothing more.

What is an API call for you ? is it necessarely illegitimate? is it always for internet acess?
When ZA tell you that, you can't know if it's legitimate or not, you can't know if it's for internet access or not, and if you take the wrong decision (because you don't know it will be a malicious internet acess) you will have problems.

Last argue for this post : i create a firewall, i include application monitoring feature that _just_ check the launch of any executable (once allowed they can do that they want), like SSM would do.
So if i understood you rightly, this firewall would pass ALL leaktests because it can prevent them simply to launch ?
(so we don't care of network application filtering )



At the end, unlike you seems to think, i'm not against to believe the contrary if you can convince me, i just provide you my argues, and as of now i'm not convinced of the contrary.

 

The "OpenProcess" API process is much too early to actually definite it’ll be using Client Environments, and is something sandbox would support. That cannot be defined a part of Application Filtering Layer.

If he gives Pass status for that type of exploit, then his entire site is impropriate and misleading, Entire Re-write needs to be done.

gkweb I’m curious if you renamed copycat and packed it and executed it, does ZoneAlarm still pick it up? Hmmm

 

i think it will, since in fact ZA seems to have put a hook on OpenProcess API call.
(But i will do the test just in case)

 

Possible...

 

I plan on using common sense when it comes to trusting apps. For what I want, ZAPro does the job with Copycat. I am satisfied.

Your site says NPF doesn't pass PCAudit, yet I can deny access and there's no leak. Now in this case, it didn't recognize the app., but Outpost also doesn't recognize it, yet it's listed as passing it. This is why I always do my own testing from your links.

 

i understand your point of view, but i'm not sure you read my post 2 post above.

ZA block a process access, but Copycat isn't a process access, it's a proof of concept and ZA didn't deal with the idea that Copycat wants to demonstrate, it just prevent it to run in fact.

I know ZA make you able to pass Copycat, but does his outbound application filtering passes Copycat ?
(which i am evaluating on my site).

All the problem is here.

The feature involved to pass Copycat isn't a matter of "firewalling", but application monitoring.

this for what mainly the site is make, for make you able to test yourself.
(BTW, if you obtain such result, pls send me a screenshot at gkweb@wanadoo.fr of the popup with details shown.)

pls stay focus on ZA or at least on the problem about "application monitoring" against "outbound applicating filtering" (network layer)

 

I made RealPlayer a trusted app., and now it might be allowing it OpenProcess calls. I see what you mean. Maybe you should leave it as failing for your purposes, but I find it more useful if the overall picture is given.

I want to stay on ZAP, but that had been on my mind for a while and I wanted to bring it to your attention.

 

You had given a good example too with RealPlayer.

The same problem with ZA exists also with Kerio.
Kerio failed WallBreaker, if you activate only his menu tab "Network Security".
But if you activate his "System Security", another menu, then it behaves like SSM and blocks WB trying to access IE, not because it's an internet access, just because it's an acess.

Like you mentioned it, there is a difference between outbound software filtering strenght, and overall firewall strenght, depending of the point of view, a result could be failed or passed.

Since i always evaluated outbound software filtering at network layer (which is that leaktests asks me), i will probably count it failed, and i will add a link on the result page talking about this problem, and will say that results are different than the overall firewall feature could have, indeed, firewalls could have extra features to overcome their outbound software filtering vulnerabilities (that is the case at least for ZA and Kerio).

In fact, this thread will help me to write a better "results details/explanation" page
(until someone convince me of the contrary)

At the end, as i said, the most important purpose of my site is to help users, that they can do themselves leak tests, the results page is just a quick overview of vulnerabilities at network layer, you shouldn't take it as a Bible (i don't know if it's the right word, i mean the holy book).


If you have another input to add, or anything else, i'm still open

 

Yes, I think that's a good idea - put an asterisk next to ZA Pro, and then say it can pass copycat if the program is not given access.

 

in my current tests page ( on my comp ), i added a new column "AM" with an icon "+" for firewall which has AM (Application Monitoring) and an icon "-" for those which doesn't have.

This icon is explained, and in the "results details/explained" page i explain that such AM feature overcome outbound software filtering vulnerabilities and allow you to pass more leaktests.
(ZA and Kerio are concerned).

I think that way, both information are available

 

Sounds good - I'm satisfied now. Look into that other thing I told you about , too.

 

If someone else has any other suggestion about how to deal with "application monitoring" against "outbound software filtering" (and what results should counts), feel free to give your input here, even if i think that with mvdu and Phant0m we found what we were looking for :

"application monitoring" different than "outbound software filtering".

You can agree too, not necessarely disagree

 

gkweb,

Okay, you're now being confronted with an issue that I thought would eventually come up (even in the context of the leaktests on which you concentrate).


The personal software firewalls (PSFs), in particular are evolving (and not always in a straight-forward fashion).

Just for purposes of exposition, let's start with a far older set of examples with which many posters here may be familiar.

At one point, the end-user could select between whether closed ports could be reported as 'closed' or 'stealthed'. (A user-selectable option, at least for a short time.) Then, we started getting to PSFs that automatically stealthed these ports and the user had no choice whatsoever. And, of course, today I'm not personally aware of any PSFs that still gives the end-user the option; it seems they all get stealthed, whether the end-user would choose to do this or not.

At another point, PSFs started doing 'file authentication' (well, at least on the main executables and with differing levels of comprehensiveness). Most used (and still do) MD5 authentication; others used SHA1 authentication. Today (and finally after almost three years of incessant bitching -- at least on my part ), some of the PSFs are starting to do a bit more comprehensive file authentication, including on root processes, DLLs, etc. But still, sometimes this is by default (and it may not even be possible for the end-user to change the default) and sometimes as a configuration option offered to the end-user.

Now, I know that neither of the above is really the focus of your leaktest results on your website, but -- still -- let's consider what would happen if it were and you hit on the transition period.

You'd confront three (or four) options and have exactly the same problem you confront here:

• Some of the PSFs would not provide this feature at all.
• Some of these PSFs would have this an an embedded 'feature' which the end-user could not modify at all.
• Some of these firewalls would have this as a user-selectable "on/off" , i.e., "enabled/disabled" feature, (possibly with different 'default' settings) and
• Some of these PSFs would go a bit further and provide a capability for the end-user to further configure these options.

Now, the problem that you've always faced (even in the very limited set of comparative evaluations you are trying to provide) is how would you equitably compare these features? As I hope you see (and think you are beginning to realize) this is not at all an easy question to answer. If anything, it's further complicated by the PSF vendors offering a spectrum of PSFs (and usually having multiple releases to support) on various OSs (and sometimes the PSF that might get installed on, say, Win XP is considerably different from what might get installed on Win 9.

And you are confronted with precisely the same issues involving leaktests on (various releases of) the various PSFs on various OSs.

I don't have a simple answer for you in this instance. Some of the PSF vendors are 'embedding' the solution to various leaktests in the code of their most recent releases. Others are leaving it as an 'option' (and not necessarily a well-specified one, in my estimation). Furthermore, where the 'option' exists, it may (or may not) be configurable to some extent. I don't know what to tell you in this instance, but I think it's a subject that is worthy of more exploration and I hope to see more discussion of this from others.

A lot of the PSFs are now turning into "security suites", as was recently discussed on the DSLR Security Forum. Sometimes, the 'feature' relevant to a particular leaktest vulnerability is innate to the package; other times it's hidden away in the 'extensions' involved with the "suite". (Indeed, I think you ran into this a long time before you got around to the Copycat/ZAP issue.)

I think it's time to stand back and take a bit more comprehensive look at precisely how you need to address these kinds of issues.

 

The problems i am now facing was well described by you

This is why i'm still trying to stay on the network outbound application filtering to respect leaktests ideas, but now more than ever, new firewall features make my tests criteria more difficult to define.

This is why i like to say that after all, my results are just a quick overall of firewall vulnerabilities (all are tested fairly with same criteria) and that the main site purpose is to make you able to test by yourself following your own criteria.

Yes i take in count firewall evolution, this is why i will modify the leaktest page results (in addition to update results), and this si why testing criteria will be explained more than it be actually on the site, the main idea is, as said above, that leaktests are proff of concept, ideas, and blocking their execution is not passing the idea.

I will add just as an example, Look'n'Stop 2.04p2 with lastest driver blocks with his outbound application filtering (network layer) the leaktest "Thermite". So i think there is no reason to count "unfair" feature like application monitoring (which is the easy way) until leaktests becomes so much sophisticated that application monitoring will be the only solution.
When this time will come, firewall no more will win against leaktests "ideas", so i will have to remove the results page, but we aren't there as of now

For me, for now, Application Monitoring has nothing to do with "firewall".
Vendors can add it, but it still different than outbound software filtering that leaktests bypass (leaktest was never meant to bypass application monitoring).

regards,

gkweb.

 

From "Morgott" on another thread:
--------------------------------------------

gkweb said :

O, but I already read it, hehe

The point is, open process protection is a necessary layer in the defense against trojans that hijack other apps by directly inject themselves in these (open) apps instead of just calling them. Now upon running Copycat, which (unlike Thermite) allows U to choose the target process, there are 2 possibilities:

1) The target app is NOT allowed access to internet. Take notepad, for example. In that case, firewall will intervene both on open-process protection AND app-filtering levels: first, it will ask U if you wish Copycat to access Notepad.
If you answer 'No', then the test stops there.
But if you answer 'Yes', then notepad will be "patched in memory" and thus turned into an app which can now access the Net. But then firewall will step in again, ASKING YOU IF YOU WISH TO LET NOTEPAD ACCESS INTERNET, to which you can still answer 'No'. This is an example of "double-shielding" at work (sorry for the expression, couldn't help it I'm a Trekkie ): first open-process protection, then application filtering. So in this case, the test is passed.

2) Now there's the controversial & most interesting part - the target app IS allowed internet access, take Iexplore for example. Again, ZA will step in to complain about copycat trying to access the browser. Once again, answering 'No' closes the case.
But if the user answers 'Yes', then indeed Copycat will access the Net (or rather, the modified "Iexplore/Copycat hybrid" will). BUT ISN'T THAT NORMAL? After all, as I said the browser IS allowed internet access! The fact that it was modified in memory is a process protection issue only, and has nothing to do with 'application filtering' since the user chose to give the browser application Net access, and also explicitly allowed Copycat to modify the open browser process!!
So seen in this light, the firewall again passes the test..

Sure, as U said in the other thread, some trusted applications can be required to (and must be allowed to) use other internet-accessing apps to connect to the Net. But then again, there is a difference between a program calling another app such as Iexplore and making it access the Net, and a program that injects itself directly into another app, ie. Iexplore, and thus modifies it, rather than simply call iexplore. Take explorer.exe, 4 example: it must be granted the right to use (call) other programs to access the Net (otherwise apps such as P2P, ... won't be able to connect to the Net). BUT WHAT KIND OF TRUSTED PROGRAM WOULD HAVE THE NEED TO INJECT ITSELF INTO ANOTHER?
A program that tries to patch another trusted program instead of just calling it can only be a trojan, and thus denotes malicious intent (someone correct me if I'm wrong ).

BUT even then: suppose a program does require such "open process" privileges, in addition to having the right to use other apps to access the net. Suppose this prog is called 'Good.exe'. Now good.exe can call, for example, Iexplore, AS WELL AS patch it by injecting itself into it. OK. So? No problem! Recent firewalls (not only ZA) all have application & component control using MD5 signature authentification. Thus if the 'Good.exe' file is modified, then the firewall will pop in to advise the user that a MODIFED version of Good.exe is either trying to use Iexplore to access the Net, or trying to inject itself into Iexplore, depending on the context. In both cases, the system remains protected, and the shields hold (oops I did it again ).

So there U go comrade, that's my take on the situation. Application filtering (by its very definition) and application/component authentification are NOT enough to avert threats such as self-injecting hijacking. Open process protection is the necessary "third layer" to complete the protection, and ZA seems to have taken the first step. Other firewalls such as LnS and Outpost will have no choice but to implement it if they are to protect against these techniques.

Nevertheless, I must admit that your thread got me thinking 4 some time...

BTW, I checked about a leak test being possibly blacklisted by ZA (a dirty trick that the makers of BlackIce have already carried out in the past, cf. the grc.com 'Shields Up' site - shame on 'em!). So I renamed Copycat.exe, changed it modification date and even altered its content by changing some text within using a hex editor, thus changing its MD5 signature. ZA still passed the test...

Besides, I've so far tried about 5 different firewalls. Though ZA may be my favorite for the moment because of its new features, CPU load still is an important criterion that Zonelabs (and others) doesn't seem to have really dealt with up 2 now.
Zonealarm wallops a load of RAM over time, who knows why (from 7 Mb at startup, 'vsmon' bloats up to over 30Mb).
LnS seems to have the edge in that matter - it uses few resources, from what I've read. On the other hand, Both LnS and Outpost fail some AWFT tests, unless Explorer is given certain restrictions... LnS is also difficult to configure and sometimes leaves port 135 open by default!!!

Man, why does every software have to have its flaws? Can't someone just design a firewall that comprises the benefits of all the other firewalls WITHOUT their drawbacks

From "Morgott" on another thread:

 

@Morgott

I think (no offense!) you didn't fully understand how leaktests concept works.

The most understandable is an example
The target process is fully trusted and has full access over the internet (let's say IE).
We allow the malicious executable (without knowing it is malicious) to access IE, and at this point you said that the hijacked software couldn't be blocked, which si wrong.
Indeed, let's take "Thermite" leaktest, it first do an "OpenProcess" before injecting thread and hijacking the browser.
With any application monitoring software/feature, you allow it to access IE, and even with this, Look'n'Stop block his internet access when it wants to access the internet.
So the bypass of the first shield (application monitoring) doesn't mean at all that the second shield is necessarely bypassed too.

A more simple example may be is Tooleaky that many firewall blocks, first shield is passed, and even with IE having full access Tooleaky is blocked.

It could be legitimate.
So far, i can tell you that XP services need to WRITE into another processes, there is "lsass.exe", "svchost.exe", many software (i know norton doing it).
For example, System Safety Monitor does DLL injection into running processes, Process Guard "Close message handling" feature inject threads into processes if i remember right, i know few port to process mappers are doing DLL injection/thread injection and code modification, and so more...
You would be surprised to see how many AV/AT/FW software accessing and modifying other processes.

I never said current firewall can, or ever will be able to handle all by themselves, i just notice outbound software filtering vulnerabilities (at network layer), and yes, i totally agree that additional layers of securitty are really _needed_ to handle all trojans/leaktest, if you take a look at my site, you will see it in the "advices" page, and "software" page, we totally agree on this point

That i'm trying to say, is that i'm only testing one firewall feature, application monitoring is another feature which could _should_ (to my eyes) be handled by dedicated software, and as i answer to the excellent
points from JV Morris, leaktest was never meant to bypass application monitoring, so of course, if you use such feature you will pass everything...

interisting subject, isn't it ?

 

Bah, first of all, no offence at all, comrade - I'm more or less new to this stuff (closer to 'new' in fact). All Jedis were apprentices some time

But then again, I fear I didn't quite understand your example.

First of all, when U say 'Application Monitoring', I suppose U mean 'Process Protection', right?
I also gather that U used the beta version 2 of LnS 4 - which is supposed to block Thermite, still right?

Second, how can LnS possibly block IE (Iexplorer) only when it is being hijacked by Thermite WITHOUT being able to handle thread injection? That seems contradictory indeed, for that would mean that
1) It does not know that IE has been modified in RAM (since it has no process protection)
2) Yet it DOES know that IE has been modified in RAM since it blocks it only when Thermite hijacks it !?!! How can it do that without protecting (monitoring) IE ?

Third, another detail irks me: have U tried LnS 4 beta 2 against Copycat by choosing IE as the target process (as for thermite)? From what I've heard, it fails at on that test ... even though it passes the Thermite test, when BOTH leak tests try to hijack the SAME target (IE) in the SAME manner !?!!

I'm not stating anything for sure, but if I may suggest a possible explanation to this result:

The beta 2 patch for LnS 4 has been specifically tailored to the Thermite test (perhaps an MD5 signature recognition - try modifying Thermite with a Hexeditor ). In a way, that could be considered "cheating"! Sounds far-fetched, but it's the only explanation I can think of as to why LnS4b2 blocks Thermite, and yet not Copycat on IE...

A most interesting topic indeed. Awaiting feedback...

 

I mean all methods involved to control/allow/block from the simply _launch_ of any executable to most adavanced process _access_ (DLL injection, thread injection, process memory modification request), all that is a request to the OS from an executable that can be hooked.
A full Application Monitoring software, for understand what i mean, is System Safety Monitor.
If you take the OSI model, application monitoring occurs on the 3 higher layer (session, presentation, application), whereas outbound software filtering occurs on the 3 layer before (link, network, transport)
Sorry if i badly translate my french knowing layer name of the OSI model

I tested LnS 2.04 last beta version and last beta driver.
Indeed, any firewall blocking fairly leaktest at network layer HAD to collect
information on the application layer to be able to make the link between the internet access and the requesting executable.
But there is a difference between :
- controling thread injection ( that could be legitimate ) and alert the user when and only when the injected thread attempts an internet acess
- controlling thread injection and alert the user when any is done (earlier than the other).

So there is a difference between colecting information about API in use and process access to be able when the time will come to show the guilty, and to base all the firewall on it to turn it in an application monitoring software without taking care of false positive.

This, which is legitimate to increase his security (so i understand vendors), isn't valuable for my testing purpose which only focus on the filtering at network layer (see the OSI model).

ALL firewall that i evaluated fails Copycat.
As of now, all outbound filtering that i evaluated failed it, so the only way to block such "executable" is application monitoring (the leaktest concept is still not blocked so not "passed", but at least you have tools/feature to prevent such concept to run on your system).

Not the two leaktest hijacks the same software in the same manner.
Copycat can hijacked any browser or any software, it let you choose the PID number to hijack when you run it, but to simplify we will say both leaktest targets IE.
Thermite injects a thread into the process (it creates a new one) whereas Copycat use and modify an _existing_ thread into the process, this is why
it is so much difficult to block.

LnS doesn't use such dirty trick.
In fact you already have a part of the answer with my answer just before (Thermite different than Copoycat).
I tried with renamming it in "toto.exe" and in packing it with UPX and it still detect it.
I don't think ANY firewall vendors will take such risk (like BlackIce does...) because if i discover such dishonessty, i will put a bullet on this firewall and everyone will know the firewall company policy : to lie to his customers providing them a false sense of security.


ouch, my hands hurt me and my keyboard is smoking, call fire men !

 

Ok thanks 4 the explanation comrade

That was exhaustive enough. U must be a Jedi Computer Master or something . I wish I knew where I could QUICKLY learn how to program such stuff...

So if I understand correctly, LnS 4 beta 2 CAN handle thread injection but not thread modification

And it is also capable of telling WHAT the injected thread is trying to do (ie. net access)? Impressive...

In other words, ZA needs a little more fine-tuning to be able to do the same thing since for the moment it only acts at a "lower OSI level" - correct me if I'm wrong.

As soon as it can handle Copycat-style trojans too in a similar fashion, I'll switch to this firewall. I hope others will follow in soon enough.

2 more questions:
- when ZA blocks a thread injection/modification, at which OSI level does it intervene?
- When LnS4b2 blocks a thread injection AND sees that the new thread is trying to access the Net, at what OSI level does step in??

 

No, i'm still a Padawan but may be a day the force will be with me and i'll become a Jeidai

About LnS, and in fact generally, to add a thread is easier to see (like to add a DLL).
Modifying which already exists is more stealth (and a lot harder to detect), this is why just hooking "OpenProcess" API call prevent any further leaks (since whatever you want to do on a process you must open it first).

Still generally, i don't think it's impressive, i think you have to do brainstorm training, and when you find the "trick" that no one thought you have winned.
Windows process interaction is a wide subject, and each month new technique of attack/protection is discovered.
It's all about Hacking (in the right term, not cracking)

About Application monitoring (and so ZA which have a feature like this), it takes place in higher layer of OSI model (not lower) than all which is about network.

7 - Application
6 - Presentation
5 - Session

4 - Transport

3 - Network
2 - Link
1 - Physics

Application Monitoring -> 5,6,7
OUtbound filtering -> 2,3,4

AM prevents leaktests to reach lower layers.

I think it's at "Application Layer" (7).

I don't know LnS code, i don't know which method authors uses, but if i have to bet :
first step : layer 7 (doesn't alert at this stage, just let an eye on it)
second step : when a "request" to go to lower layer is done, it's block it and popup the user (layers 5,6,7), before it reachs the layer 4.

It's different to block a request to launch or open a process (request toward layer 7) than to block IE to access an URL (request of layer 4,3,2).
It's the big difference for me between application monitoring and "Firewalling".

If we go other the leaktests topic, a multi layered security is stronger than to bet that you will prevent any threat to go outside of layer you are monitoring, if you fail it, other software will receive and handle it.
Just imagine a football match !
The goal man is the application monitoring, the web behind him is the outbound software filtering, and again behind, it's the Internet.
If one fail, the other can catch the threat.
But if the threat cheats and is very "small" (for the metaphore) it will may be pass trought both the goal man and the web behind it to reach the internet, so you need to further enhanced your security by adding more security layer

 

gkweb,

I'm not sure who actually said this (you or Morgott), but you've just broached another can of worms below . . . .

For the moment, let's forget about ZA, BID, and Gibson's Leaktest (1.0, I believe that was). If a firewall (from any vendor) passes a particular leaktest, are you actually then checking to ensure that it's not accomplishing this by this kind of subterfuge? Let's face it; it could be highly tempting for a PSF vendor to be the first one to 'pass' Copycat.

I hate to say it, but this can easily turn into a lot of additional work. For example, just renaming copycat.exe to msword.exe (in the file system and even possibly relocating it) isn't going to cut the mustard. Nor is changing the (file system) DateLastModified. Even changing the hash isn't necessarily definitive by modifying a text string within the file.

At a minimum, you'd also need to change the file header internals, and the original executable file name is usually found there, along with an internal FileDateLastModified field. You'd probably be best off to also add a nul byte to the end of the file. Now, these kinds of changes will certainly change the hash (whether CRC32, MD5, SHA1 or whatever the PSF uses).

See, here's the problem. If a PSF vendor was bound and determined to 'pass' some especially sensitive leaktest (presumably that no one else could easily pass and presumably by hard-coding in the PSF itself), they're going to check one helluva lot more than the file system's name for the file, the file system's date last modified, and the hash. Heck, we checked more than that with NIS FileCheck! And the latest versions of NIS/NPF can actually go out and check for additional information when such a file is first encountered. (At the moment -- as far as I know -- NIS simply checks to see if it can validate such a file, but there's absolutely nothing to prevent them from doing the same to invalidate a particularly pesky Leaktest, for that matter.) And, no, I don't believe that Symantec has done this.

But I hope you see the potential complication here for your analyses to be accurate.