Comodo Defense+ fails to stop drivers from loading

i recently installed comodo defense+ to protect myself from rootkits. i've spent a few days learning the software now, and i think i've found a major weakness: it fails to stop some drivers from loading! it does stop some drivers, but not all of them. to test this out, i installed a product called virtual cd. virtual cd is basically a virtual dvd rw burner (whereas daemon tools is just a virtual dvd rom). according to eqsecure 3.41, the trial version of virtual cd 9 ( http://www.virtualcd-online.com/vcd/apps/download/vcddownload.cfm?lg=0 ) installs 4 drivers:

HH9Help.sys
VC9SecS.exe
VDRV9000.SYS
vdrv9000.sys

comodo stops 1: VC9SecS.exe and lets all the others through without even saying anything about a device driver installation. to confirm this, simply download and install that trial version and see which drivers your hips can catch! is this a weakness in comodo defense+? if it will let 3 drivers from a non malicious app through, then it can easily allow any rootkit through, right? i stopped using eqsecure because they are no longer updating the old version. they released a new version of eqsecure (version 4) but it's no longer free, and i can't read the chinese on their webpage anyways even if i wanted to. i have had serious trouble finding a replacement. i tried online armor already, but it doesn't allow you to detect only specific types of behavior like comodo does, and it also doesn't seem to have a mechanism for blocking drivers.

 

Have you tried Outpost Security Suite 2009. It has excellent HIPS. Download a free trial at www.agnitum.com and do the test again and compare results. If you decide to try OSS 2009 please uncheck train agnitum for 7 days; since in that mode OSS 2009 is actually learning rather fully blocking. Good Luck and keep us posted on the result.

 

i haven't tried outpost security suite, but i tried its free version to see how it would be like. for some reason, it's showing 300 kb/sec i/o in process hacker (this would probably be "I/O Delta Total Bytes" in process explorer). i would be ok with this, but it's making my fan spin a lot more. i googled for solutions but could not find a solution. actually, in 2005, a super moderator named paranoid2000 posted in outpost's forums (i think he's here on wilders as well) about the problem being related to virus scanners scanning outpost's logs. however, i disabled my only on demand scanner (eset nod32), and the i/o was still very high. in any case, i think his solution was for an older version of outpost anyways, since it was so long ago.

if anyone knows a solution to this problem, i would be more than happy to test the other features of outpost. a pity...i really liked its menus and settings. in fact, i liked everything about it except for its abnormally high i/o

 

great suggestion! unfortunately, i don't want .exe files in the list. is there a way to have only .bat, .com, and .sys? i allow .exe files to run automatically to minimize the number of alerts. only when they try to do something suspicious do i want comodo to alert me.

edit: i figured out how to add .sys manually. i browsed and then entered *.sys, but does comodo distinguish between .exe files simply running and .exe files being "loaded as drivers" (whatever that means)?

 

Well that would be a bummer. Image execution is intended to check whether code is changed. That has nothing to do with driver loading or driver installation.

When a driver access ring 0 it has at least the same 'priveledges' as Comodo, so would be an interesting an unpredicted battle between say an installed rootkit and Comodo.

Does not have Comodo a better solution for that (just doing what it suppoesed to do when you check monitor driver loading/creation). So I would post this in the comodo forums.

 

May be you were using safe mode that allowed drivers loading automatically?

 

I was going to write the same question: what about these drivers and CIS in Paranoid mode ?

 

i'm in paranoid mode. i even deleted the rules of all applications, including system applications so i could control exactly what was loaded. those drivers i listed from virtual cd 9 are not detected at all (except one of them that is).

i'm in paranoid mode and i have *.sys added under image execution control. i thought this would do it. unfortunately (or perhaps fortunately), kees1958 has shown that execution and driver loading are not the same, even if they involve the same file. interestingly enough, the one file CIS does detect being loaded as a device driver is an .exe file, not a .sys file.

any thoughts on this?

 

It's best to post in their forums.

 

i did already.

 

Anyone ever got a response posting the Comodo forum with a problem?

 

Well, I problably have made to many jokes on Comodo. Noticed that 3xist is no longer a member of wilders also

 

He's back, like always. He's an Incredible Massive Quitter.
Maybe he suffers of the revolving door effect.

Cheers

 

here are some related topics on comodo's forum:

https://forums.comodo.com/leak_test.../defence_failed_against_malware-t19073.0.html

https://forums.comodo.com/leak_test...t_about_dns_trojan_dropper_test-t25570.0.html

https://forums.comodo.com/leak_test...tdriver_install_not_intercepted-t25663.0.html

https://forums.comodo.com/defense_help/defense_fails_to_stop_driver_loading-t43955.0.html

these threads seem to indicate that comodo currently fails to stop a significant number of drivers from being installed. the only fixes so far have not been to improve the "device driver" loading detection filter, but rather to manually add lines to both the registry protection AND the list of protected files/folders. a rootkit could easily find a line that hasn't yet been added and bypass defense+. these tweaks would not work against an unknown rootkit as well as better protection against driver loading would.

there is also the danger that if you don't enable a fourth filter (namely, COM protection), then you would unknowingly allow a malicious installer to install an innocuous looking driver through services.exe. you already get plenty of alerts about drivers from legitimate applications and windows itself as is, and it would be all too easy to click one more time. put together, these seem to be pretty significant holes in defense+.

 

CFP intercepts driver loading fine. However there is a problem with alerts about intercetion of driver/ service install. The pop up alerts in these cases are very poor unlike other HIPS.

https://www.wilderssecurity.com/showthread.php?p=1526872#post1526872

 

You can block things like .BAT.COM etc etc seperately from any HIPS etc.

An App such as the very good and free Script Defender will do this http://www.analogx.com/contents/download/System/sdefend/Freeware.htm

Whenever an included extension trys to launch it will instantly intervene and block it, and ask you if you want it to run or not.

I've been using it for years, and it works every time. Uses NO resources except when blocking, and then hardly any, and only until you allow/deny.

 

No execution,no infection is the rule ofcourse.

 

pretty sure the test is just to see what the alerts wuld look like if u wer to run the .exe. not to simulate a real life scenario.

 

I consider this matter resolved now based on Aigle's tests. They seem to show that Comodo was not bypassed as a result of it being blind to driver loading. However, the way in which Comodo alerts the user needs serious improvement for many reasons, not the least of which is that the registry alert corresponding to the driver install could easily be mixed in with many other more trivial alerts. I have made the relevant suggestion in Defense+'s wishlist forum. If you have any thoughts, please post them here :

https://forums.comodo.com/defense_w...stall_not_registry_modification-t43954.0.html

Even though Comodo itself may have been able to see the activity, I still consider it a serious problem if it does not alert the user in a way that gives the user to respond appropriately. Driver loading is very different from registry intrusion, and should be kept separate by Defense+.

Another alert type that should be kept separate from driver installation alerts is the protected file/folder alert, for the same reason. Please see the thread on Comodo's forums at the link above for details.

Finally, on COM access and similar situations in which one program invokes a system process to load a driver, an appropriate alert should be given to the user. Once again, the link above provides all the details.

 

Script Defender sounds like a fantastic little app. And I can configure it to intercept any extension I want?

 

Dregg Heda

Glad you like Script Defender, yes it's a fab little App, and very effective at what it can do.

 

Your request for wishlist will be good if you want to improve some behavior blocker (thretfire, mamutu....) D+ is pure HIPS, in other words, what you see is what you get...
Read carefully what you are allowing, just suggestion

here, how driver can be easily registered...(Matousecs first kernel test)

 

... but only because of the KIS prompts, which have pretty much the same quality like the CIS prompts.

Would you like to post the pics for the KIS prompts related to the Virtual CD drivers in this thread?
https://www.wilderssecurity.com/showthread.php?t=251309
Just to see how easy everyone can figure out this actions with KIS.

Cheers

 

Here, some of KIS prompts:



(not necessarily by that order)
I really dont have problem with quality of Comodo prompts, it can be easily figured out that drivers trying to register...
What about OA prompts?
Autorun warning?
Why not Autorun services, or new services warning, or something similar...
P.S. sorry didnt catch last couple of warnings...
will post it later if find some time...

 

Hi Steve,

Just to be clear does Script Defender intercept any extension I want it to?