Comodo scores well but not 100% at new Matousec x64 tests

Soon they will test with adjusted leaktests for Windows 7 x64:
http://www.matousec.com/info/?news=154-Security_Software_Testing_Suite_64

The tests can already be downloaded (a few are not functional yet, e.g. because of missing dlls):
http://www.matousec.com/downloads/ssts64.7z

Comodo fails SSS3 test, it can shut down Windows.
Also, ProxyTest can enable the proxy option of IE although it may not be able to set up a real IP adress for it, dunno:

http://www.ld-host.de/uploads/thumbnails/be561c8e7fefd8f5a46ac62be8795d9b.png

Tested with proactive profile, sandbox off.
Please fix these.

It seems all other tests are passed, very nice! :slight_smile:

i was just about to post this however i dont agree with the fail of SSS3 i was able to block it dunno why it faild for you also to pass the proxytest you need to add the following registry \SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings\Connections and CIS fails socksnif as there is no alert for it accessing the windows socket interface but socksnif from the older ssts comodo does give an alert and successfully blocks it. I agree with the missing dll files I have already sent them an email about that issue, however you can use the ones from the original ssts archive but it only works for firehole2 and inject1 and inject2, firehole and cpilsuite2 will still fail to run correctly even with the proper dlls in the folder.

It looks like they have updated the ssts64 tests just received an email that they fixed the issue with the missing dlls and to download the new archive, they also added the autorun dlls that i totally forgot about that the origianl ssts had but i didnt have problems running any of the autrun tests nevertheless the tests should be ready to go and I am going to retest CIS proactive a/v and sandbox off, admin account uac disabled on my live windows 7 sp1 x64 fully updated and patched. Though I dont expect different results only proxytest and socksnif are the only tests that technically CIS fails against.

Shut down of Windows was never seen as a security issue by Comodo. I remember egemen commenting on it a couple of years ago (I don’t feel like looking this up).

It was a problem of my config.
I don’t know how this could happen since I didn’t delete any single rule, at least it’s blocked now.

[at]futuretech: You are right with the socksniff issue. If you run it with “-u” parameter Comodo can block it, so it seems the leaktest successfully bypasses Comodo’s usermode hook.

it seems matousec is down right now, sad. i wanted to check the results. oh well, ill try later, thanks for the info :-TU

I wish matousec add an test for trojan Sinowal/Mebroot.

There is no any malware process showed in the task manager.

Some firewall might be bypassed by this type of attack.

:smiley:

Just as I said before, CIS passes all but two tests which are proxytest and socksnif, however a simple modification to the protected registry keys will enable CIS to pass proxytest. Also one interesting note is that if socksnif runs autosandboxed as either limited, restricted or untrusted, it will not be able to access the windows socket interface and therefore causes the test to report a pass.

Would you be so kind to write it here? :-*

yeah sure, add *\SOFTWARE\Microsoft\Windows\Currentversion\Internet Settings\Connections* to the list of protected registry keys. Actually it would be better to modify the registry group “Internet Explorer Keys” to remove all of the *\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings\ separate entries to only have *\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings* to protect every registry item thats under Internet Settings.

Nice.
+1 to your Karma.

I see that it passed 100% of the test now ( level 1 to level 10 ). Sweet !!

How do you think this is possible without changing of CIS and the leaktests?
Of course it still fails ProxyTest and Socksniff.

Well, I don’t see “ProxyTest” on any of the level but I do see “SockSnif” at level 9 and it passed it 100%

The result you are referring to is for x32, not x64.

Drat !! My bad. I thought I read someplace from here of the level 1 test result of 64bit and I bookmarked it. Then later I thought I saw the rest of the results. Oh well. Back to the waiting period. Thanks.

It would almost be pointless for matousec to create a test for this as Mebroot is a MBR rootkit. This means that the rootkit is actually being started before Windows. Thus any software based security on an infected system would likely not see it because they rely on Windows API calls to get information about what is happening in the system (same goes for BIOS based rootkits). Any MBR rootkit is going to patch Windows to hide its activities as that is it main purpose. The only way to stop this is to prevent it from getting installed which I am sure with Defense+ can currently do (correct me if I am wrong).

CIS can block it by this item, “Do heuristic command-line analysis for certain applications”

1.viewed by comodo

2.viewed by other firewalls

What Im saying is, MBR rootkits can make it so that even Windows does not know something is happening. The MBR is executed before Windows loads. I dont know everything about this particular rootkit or Comodo but I am saying in General, a good MBR rootkit could make it so nothing on that particular infected system could see it… In other words you would have to boot from a different harddrive/CD and scan the MBR of the infected hard-drive. Of course if the particular rootkit does not hide everything then yes software based solutions could detect it (as you pointed out with this particular rootkit).

With that said, the Matousec tests to ensure security products can protect themselves, not if they can detect a particular peice of malware. About the only test that I think would meet this criteria is ensuring the security suites monitor Write access to MBR. I would be inclined to believe this is already the case for Comodo (but I may be wrong).

Sorry, Ill correct myself here… Matousec tests:

Leak-test: Leak-tests attempt to send data to the Internet server, this is called leaking. Most of the leak-tests from Security Software Testing Suite are configured to use a script on our website that logs leaks to our database by default. For such tests, you can use My leaks page to see whether the test was able to transmit the data. For leak-tests that do not use this script, we use a packet sniffer in unclear situations. In order to pass many leak-tests, the tested product has to implement some host protection features.
Spying test: These tests attempt to spy on users' input or data. Keyloggers and packet sniffers are typical examples of spying tests. Every piece of the data they obtain is searched for a pattern, which is defined in the configuration file. These tests usually succeed if the given pattern has been found.
Autorun test: These tests attempt to install to the system in order to ensure they will be started again. The most common goal in case of these tests is to survive the reboot. Such a system infection is typical for various kinds of malware. The tested product fails the autorun test if the test is able to ensure that it will be started in the future again.
System integrity test: One of the roles of security suites is to protect the system integrity from malicious modifications. System integrity tests attempts to gain enough privilege in the system so that they are able to subvert the system.
Self-defense test: This category of tests include various attacks against the security product itself. Termination tests are the first subtype of tests that belongs in this category. These tests attempt to terminate or somehow damage processes, or their parts, of the tested product. The termination test usually succeeds if at least one of the target processes, or at least one of their parts, was terminated or damaged. Besides processes and threads, the security software usually relies on various files and registry entries. Tests that attempt to remove, destroy or corrupt these critical objects for the security product also belong to this category.
Other: Tests that do not fit any of the previously defined types are of this type. These tests, for example, may check stability, reliability or other quality of the tested product.

That being said, it would be nice to ensure the MBR is being monitored… But any test writing to the MBR could cause a lot of problems, but then again they do state these are not test for production systems.