ZA PRO 4.5.530 against CopyCat leaktest

You are right, and i can only ensure of such dishonnest tricks aren't use against my leaktest only (i have totally different version on my comp).

Even, for other leaktest, change filename and pack them with UPX isn't enough as we can notice it from you said.

As i said i just hope that no firewall vendors is circumventing currently leaktests like that, because if we discover that... he will be face serious customers complains, it would be unacceptable.

 

If you find one, you become the next Steve Gibson!

 

"gkweb Gibson", yea, sounds good

lol, let stay in the reality

 

gkweb :

Thx again for the explanation .
However, when U said:

I fear I didn't quite catch on:
forgive my lack of knowledge (I'm not familiar with the meanings of the terms "Hook" or "API", though "hook" may have something to do with fishing? ), but whenever a trojan wants to inject itself into a process, isn't the process already open (For example for Thermite or Copycat against IE, the user himself must open IE...)


Mr Morris :

Affirmative, that's the theory I'm trying to corroborate/invalidate. Some have already done so. Others could be tempted, regardless of the possible consequences.

I'm not sure if by your statements you meant that :
"Altering the test file's hash does NOT suffice to test a firewall's 'honesty' - further tests are needed"
or instead :
"The methods I used (changing some text bytes within the test file) are NOT enough to change a hash"

although I'd incline for the latter explanation. IF so, you may well be right - changing a few bytes could well leave the hash unchanged. But here's a counter-example: the eDonkey P2P app uses MD5 authentification to be able to pinpoint fake sources. So this I tested: I placed a 53 Mb .img CD image in my shared folder and noted the MD5 value that eDonkey returned. Then I altered just 1 byte, towards the beginning of the file, but nowhere near the header. Well, the new MD5 value was RADICALLY DIFFERENT!!!

Anyways, 'tis probably true, further tests might be needed. Perhaps changing the structure of the source code itself would do the trick...

I'll let U attend 2 it ... feel dozy now ... time 4 a 5 min. nap ...

 

I'm probably screwing up the quotes here, but you've raised a very critical issue in my estimation. As gkweb notes (and Gibson maintains), BID apparently did something like this in its response to Gibson's Leaktest 1.0. Gibson publicly stated (in his own forums) how he could defeat this (and he was quite correct, at that time).

No, I think you've misunderstood the nature of my comment. If some PSF vendor was critically determined to pass a published leaktest, they'd check one helluva lot more than the MD5 or SHA1 hash (and they wouldn't even bother to check the directory filename or DateLastModified). As gkweb notes, changing all of these parameters is trivial, even for the most casual investigator. And they could then embed code in the PSF to shut down the leaktest.

Now, what we've been referring to as 'leaktests' in this thread are actually non-malicious demonstrations of potential vulnerabilities; they are not malicious apps (or exploits) by any means (as far as I know). Indeed, gkweb made this point in his response to mvdu. Consequently, shutting down a published "leaktest" (and only that) does not mean that the PSF is invulnerable to the vulnerability that the leaktest was intended to demonstrate. (Still with me, here?)

Well, the PSF vendors are quite aware of how to test any app to determine if it's a disguised leaktest. If one of these was worth their effort (Copycat, for example?) it would be all too easy for them to embed code to simply shut the "leaktest" down (in most instances). For that matter, if you were a PSF vendor, wouldn't you love to be the first vendor to show that your firewall solves that problem? The temptation is potentially overpowering. I'm simply asking whether gkweb is doing anything to detect such nefarious behavior on the part of the various PSF vendors. This is not to say that any of the PSF vendors will do this; it's simply intended to keep all of them honest -- for fear of disclosure, if nothing else.

 

Morgoth,

Sorry, missed a point below (and what's with all this Mr. Morris stuff that's starting to show up here? Why, I've even been known to respond to yomama! on occasion -- if I knew it was directed to me. )

I meant the former, not the latter interpretation. Indeed, if you or gkweb changed a few bytes (or even added a few bytes to the file), the MD5 or SHA1 hash would almost invariably change -- and dramatically as you note. A Trojan writer, on the other hand, could modify the code without changing a CRC32 hash (that's almost trivial these days) or (with a bit more effort) the MD5 hash. Changing a SHA1 hash (or possibly something more exotic) is quite difficult however. Unfortunately, the ways this would be accomplished would undoubtedly change some other characteristic of the file -- and that's precisely why some PSF vendor would check far more than the hash signature (if they were intent on a bit of subterfuge). Now, this behavior would not be much better than being a blackhat, but it is certainly feasible.

 

@Morgott

First, let me explain what a "hook" is (no, not fishing in my case )
In Windows system, all program does call windows function all the time, this functions are known as API (Advanced Programming Interface).
So, if you are interested to see who and when is using a particular API (a critical one for what you are monitoring), you can put a "hook" on it, i mean a piece of code which will be the first to handle the particular API calls before it forward (or block) those to the API.
Thus you can control this API (allow/deny calls on it) or simply monitoring it (see which program access it).

Second, "open" IE hasn't the same mean than "open" a process.
When you "open" IE, in fact you start it, and then, the process is running.
A running processes is not opened to any other process.

When a process want to manipulate another one (suspend, resume, terminating, modifying, etc...) it must ask to the OS the authorization to access the process. To do that, it must use the "OpenProcess" API and say in which manner it wants to access the process (full control, read, write, etc...).
After that, the OS say "ok" and give to the requesting program a free "handle" of the target process (just a number), without this number you can't do anything.
"OpenProcess" mean "I want to acess this process with full permission, can I?".

In programming, it _very_ common to have to open something first to access it (registry, files, process, socket, etc...).

So, blocking an "OpenProcess" call is by far too much earlier in the leaktest stage, there is nothing malicious in itself (you can't know what will follow).

@all

About leaktest circumventing method, even changing the MD5 hash of the files, change file name, pack it with UPX, and then with ASPack.... isn't an evidence that the firewall isn't able to recognize it, what if it just read windows title ?

I can only ensure that a firewall will be honnest while passing successfully my leaktest (Wallbreaker) because i perfectly know it and have already _very_ different version.
So vendors be aware, do not cheat on my leaktest

 

Heaven, ye moderators worketh in mysterious ways...

Look here - now I'll have nightmares !!

There's little I remember about CRC32 (I recall something about Hamming codes or whatever - time to start reviewing I guess) and I never studied MD5, leave alone SHA1 which I never heard of.
But the question is, whatever the authentification method used, could a Trojan modify a file in such a way that:
1) Hash is unchanged
2) The modified code within is still viable, and can carry out whatever misdeeds it's intended for?

Second, as far as I know, Personal Firewalls use MD5 hashing - at least the most common ones we all know of. Can U cite any other firewall (for PC !) that uses SHA1 ?

 

1) it's possible if we are talking about CRC32 chesksum.
If we talk about MD5, it is sufficiently safe, althought theoricaly it is possible that two different files can have the same hash, but it still theory, i never see someone giving evidences or an example.
MD5 is widely used and trusted.

SHA,SHA-256, or SHA-512, go over this theory to ensure it's really impossible to fake a file (a trojan with same hash than a trusted app).

2) if you mean that a trojan can modify the executable code, letting it runable and still doing his usual job (+ trojan ones), it is possible (e.g viruses) but the file hash is modified.
Modifying _one_ byte give a totally different hash.


So no need for nightmares
you can rely on MD5.
SHA is better but require a little more ressources if you went to need to compute some at same time.

 

From http://www.faqs.org/rfcs/rfc1321.html

 

Actually, what I meant was: can a trojan or virus modify an app in such a way that that the modified app is still executable AND yet the hash is unchanged? That's what Morris suggested, I think...

 

exactly as i said, it depends of the algorithm you use to compute the hash.
If you check applications by a MD5 hash, no, it isn't possible.

JV Morris said :

agree about CRC32, but disagree about MD5.

MD5 RFC :

MD5 is a safe hash algorithm

 

“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!!!”

* Look ‘n’ Stop v2.04p2 + Latest Application Filtering Driver passes ALL AWFT tests regardless Explorer settings.
* Look ‘n’ Stop does not leave port 135 open by Default, problem is some Online web-scans falsely report 135 of being opened, that and users improperly configures rules which leaks from too…

 

Phant0m, you are answering to who ?
Is there any reason to post on this thread ?

 

http://www.wilderssecurity.com/index.php?action=display;board=23;threadid=16981;start=15#msg106272

 

oh ok, i missed this point, i answered to so many question that i forgot that

 

Phantom:

Huh - I you say so. But leaving aside the fact this is a beta version - still not released as a final version, for who knows what reason - it still is unable to handle copycat-related leaks IN THE SAME WAY that it can handle Thermite-type leaks, ie. on the network level (from what gkweb said, this is because Thermite inject a new thread into a process whereas Copycat modifies an existing one)
SO THE QUESTION IS: when will there be an LnS release that will also be able to cope with such threats (ie. thread modification)? Of cos', I mean a FINAL version preferably, not jus' a beta one. And will this version retain all the benefits of the previous versions, ie. low CPU usage, etc... ??

 

Hey Morgoth

You are correct; Look ‘n’ Stop v2.04p2 with latest Application Filtering Driver is still unable to handle Copycat. Copycat method is very ingenious and technical and further-more requiring much work to detect accessing Internet Resources. Obviously, it will be easy to just prevent an application from using the involved functions without checking the fact the application connects, but this is not the way a firewall should work.
A firewall should alert the user only if the application tries to connect...

I’m sure once Frederic officially releases Look ‘n’ Stop v2.05b1 that he’ll investigate into Copycat further and release a patch, if Look ‘n’ Stop v2.05b1 doesn’t already handle Copycat

As for CPU Usage; implementing NEW Features does mean little more memory requirements, but considering Frederic work to this point I’m sure it’ll not take more than necessary to offer better level Software Security…

 

...which is what ZA does for now I guess, huh? Damn! So in a way ZA only "half-passes" the test. I wonder how long they'll wait at Zonelabs to "fine-tune" their prog...

What about OFFICIAL versions? Why are they so seldom released? Not that I'm paranoid or something, but experience has often taught me that "beta" means "beware" (stability issues, bugs, other @$%&#! that, combined with Microsh*t Windows, can lead to ... U know what) - can't fool with that when it comes to firewalls & other security imperatives...

As long as the CPU load stays low, that's what matters. But any plans for adding extra features such as privacy, anti-popup & script-blocking? These can prove extremely handy, however the only 2 decent firewalls I know of that have all these features are Outpost & ZA - I've tried both (and still do as I keep switching between at least 5firewalls, namely Kerio, TPF, ZA, LnS, Outpost). Unfortunately, both these firewalls are known to wallop huge amounts of RAM with time

I know which brands to avoid, like Norton (a tad too cumbersome), Blackice (snipped - no software bashing please), ... but this still doesn't help me in choosing a final product, & sticking 2 it. These are my criteria (from the highest down):
1) Inbound protection, stealth - but they all seem to be on a par in this matter...
2) OUTBOUND protection
3) CPU & RAM usage (I value firewall protection during online gaming
4) Ergonomy
5) Mobile-code blocking (esp. vbscript & javascript)
6) Popup-blocking (not critical, but much appreciated)
6) Privacy (anti-cookie).

I've had it trying to find the "perfect" firewall - which would have ALL the benefits of the others combined, minus the drawbacks. C'mon folks, it's about time someone took the final step to distinguish themselves from the pack!!!

 

i'm sure firewall vendors are working hard each day to improve their product, let them time

About Look'n'Stop and his "beta" name (2.0.5b1) i don't think this means that the firewall has stabilities issues, i only know that it doesn't works as of now on HyperThreading CPU (P4 HT 3.2Ghz).
What about others _official_ firewalls having real issue about the loopback for instance ?

Official doesn't mean there isn't any bug, beta doesn't mean the product is buggy, it's just a word of caution.

System Safety Monitor is in beta stage too and works perfectly for me

 

I agree with Morgoth - been having trouble finding a firewall that I'm really happy with. Have licenses for NIS, ZAP, and Outpost - only one thing stands out with NIS (the IDS,) but since I'm behind a router, I'm using ZAP at least until Outpost improves. And as these leak test results show, ZAP is ahead of NIS when it comes to firewall updates.

 

OK that may have been somewhat excessive - but an understandable outburst of anger, too ! I agree that no one should criticize a retail prog this way without any argument of substance - but arguments there are, in this case!! Blacklisting a leak test site's IP (cf. 'grc.com' site) to give users a false sense of security - how dare they? That's nothing short of outright TREACHERY (not to mention a cause for litigation)! So denouncing that is more than legitimate, think you not?
But anyways I'll keep that in mind from now on - I'll be nice, I promise..

In the meantime, I wonder if it's possible setting up like 6 different firewalls on a single PC that, furthermore, operates with Windows (yipes!), and all this whilst still keeping a stable system. Anyone for testing a simultaneous setup of ZA, LnS, Outpost, Sygate, TPF & Kerio ("Red Alert, Maximum Shields!") ?

I don't even know if that would significantly the protection, if at all...

Unfortunately, ZA 4.5.530 's OpenProcess protection is only a makeshift solution against copycat-type leaks, pending a future release that will fully cover the issue (hopefully)...

 

About BlackIce, i don't really trust them too because of the GibSon leaktest story...

About running different firewall in the same time, it has been well covered in DSL report forum.

In fact, many firewall root them deeply into the OS, and install drivers/hooks.
When you installed two or more firewall at same time, they could interfers each other and blocks themselves.
I already tested, i don't remember with which firewalls, but a firewall able to block a leaktest wasn't anymore able to while running another firewall with it (drivers conflicts i think).

This is why when i do leaktest testing, i have to uninstall a firewall and reboot before installing another one.

However, i think it's mvdu which pointed that out, you "could " find 2 firewall "apparently" running fine together, but no way to ensure that they doesn't conflicts with each other.

So 6 firewall...

At the end, about Copycat, don't worry, for now no firewall pass it, it's like WallBreaker, you must use application monitoring feature/software to block them.

 

Indeed, I had to do a clean install of XP - I'm not sure what caused it (could have been the combination of NIS and ProcessGuard or a bad uninstallation,) and since I don't know, no more 2 firewalls for me. It will be ZAP, NIS, or Outpost. Maybe gkweb can add BlackICE to his leaktest results.