CPF fails GRC Leaktest.exe

Pretty simple really.

  1. I installed Comodo PF
  2. I set up a rule to allow Firefox browser.
  3. I downloaded the Leaktest.exe file from GRC.
  4. I moved firefox.exe from its folder to another folder and placed Leaktest.exe in the firefox folder and renamed Leaktest.exe to firefox.exe.
  5. I ran it by clicking the firefox link on my desktop.

Leaktest.exe ran and connected to the GRC website totally bypassing CPF.

I tried this with D+ off and then I treid it with D+ on and set to default values. Then I tried it with D+ set to paranoid mode. Doesn’t matter. Leaktest succeeds in bypassing CPF every time.

The reason appears to be that CPF does not check the MD5 signature of files. The very old Kerio PF keeps a list of the MD5 signatures of every file that is has a rule for and when that exe is executed it checks that file against its list. If the MD5 has been changed it alerts you. It appears as though CPF does not do this. By not checking the MD5 signature of executable files it renders the firewall much less secure.

I just ran that test and passed.
It is not a D+ alert you should get, but rather a firewall alert. Blocking the test from access to the Internet will pass the test.
Make sure there isn’t already a (firewall) rule created to allow this app to connect. If there is, remove it and rerun the test.

i think most of security progs are able to block this leaktest.

i tested it and got no firewall alert, all comes from D+ here, using comodo 3.8 471 on xp pro sp3.

i launched the leaktest with D+ disbabled to get the exploit loaded then i set D+ into paranoid mode.

i launched the test; had only D+ alerts, never any FW one.

if i allow D+ alerts then comodo fails.

Wouldn’t even let me save the file to test. Flagged as malware. Disabled the AV, and downloaded the file… left my settings were they were at (AV disabled, Firewall at Custom, and D+ set to SAFE…) and it passed

I’m not quite sure what you mean here. There no firewall rules set to allow this app to connect to the internet. I have my Comodo set not to learn or allow anything that I specifically don’t allow. I manually create all my own rules. I don’t allow CPF to create any rules for me.

To all that answered … I appreciate the feedback but please be specific when you say “it passed” because I’m not quite sure what you mean. Do you mean that CPF passed the test meaning that it blocked the offending file from connecting out, or do you mean that Leaktest.exe passed the test meaning that it bypassed the security of CPF? In other words that CPF failed?

Sorry but I am just a bit confused by the replies and I want to be sure :slight_smile:

Of course if I create a rule to block the file (leaktest.exe) then yes, CPF will stop it and the test will fail (meaning that CPF succeeds in blocking it). But that is not a valid test. The point of this test is as I stated in my first post. That CPF does not verify the MD5 validity of any file, even files in its list of allowed programs. Therefore if some malicious program were to get in to your system and rename itself to something that is allowed by CPF then CPF would do nothing to stop it.

As I said, I created a rule to allow firefox.exe then I moved it to another folder and placed leaktest.exe in the default firefox folder where firefox was. I renamed leaktest.exe to firefox.exe and ran it. CPF allowed it go out. That means that it did not detect that the original firefox.exe had been replaced by another program. That is a fail for CPF in my opinion.

Well, not really.

This is a pretty strange thing about defense +, when a user changes a file, it will probably not detect it. But when a program moves firefox.exe, then replaces it with that leaktest, it will detect it (the firewall also I think) and give you an alert ! :slight_smile:


Edited comment:
Oh wait I see what you are saying. You are saying that if I do this behavior it will not alert me but if a PROGRAM does this without my intervention then it will alert me. Oh OK. I getcha.

Is there any way to verify this?

Yes indeedy, there is an easy way to detect this – See this DSLR thread:

I’ve posted an AutoIT script source code that does this, and described what happened in my testing…

I posted a wishlist proposal that may answer the performance concerns of MD5 testing: https://forums.comodo.com/defense_wishlist/checksum_for_all_applications-t36427.0.html;msg263817#msg263817