How does Comodo 3.0 detect malware?

[goodbrazer]

@ganda post:40

…one quick question, how do i do that? ;D there’s no option to add the files
manually.

Press Add, type in whatever you want to add in the field Add new item, then Apply and Yes.

@ganda post:40

*i’ll add *.bat & *.vbs to Image Execution Control Setting

I guess this works only if you switch to “aggressive” control level.

[ganda]

@goodbrazer post:41

Press Add, type in whatever you want to add in the field Add new item, then Apply and Yes

huh ??? where i can find the “add new item”?
ahh, i’ve found it. you forgot to mention browse ;D
:■■■■ thx goodbrazer
gotta check this topic everyday to find the solution :THNK

[MaratR]

goodbrazer,

Great observations, thanks. You’re right about DLL’s - you can make Comodo treat them like executables by adding them to the Files To Watch list and setting the Image Execution Control Level to aggressive.

Unfortunately, you’re also right about the amount of alerts this brings in: when I launched wscript.exe to run a simple script (more on that later) I had around 45 (!) of them, and I have no idea how some of them relate to the script. Surely, this level of protection can only be used with some sort of generalization in Computer Security Policy rules, like blocking all applications from executing any dll’s on drive d:, and allowing to execute dll’s on drive c:. Otherwise the number of alerts would drive anyone crazy.

Speaking of VBS scripts, the same procedure failed to work. I have *.vbs in the Files To Check list, and the same aggressive Execution Control Level. When a vbs script is run, Comodo comes up with a number of alerts - wscript accessing Service Control Manager, running cmd.exe (part of the script), 45 cases of dll execution, but still no mention of the script filename. So it seems, unlike with rundll32.exe, you can’t control what scripts wscript.exe is allowed to execute.

To double-check that, I created a rule for all aplications, blocking the execution of *.vbs. Placed on top of the Computer Security Policy list, it doesn’t prevent wscript.exe from executing D:\test.vbs.

If anyone wants to experiment with the wscript.exe issue, I have a small VBS script (originally posted by pykko here on the forum) attached to this message. It launches your web browser and opens the Google webpage, nothing dangerous.

[attachment deleted by admin]

[goodbrazer]

@MaratR post:43

Unfortunately, you’re also right about the amount of alerts this brings in…
…Otherwise the number of alerts would drive anyone crazy.

Yes it is very annoying, i agree.

@MaratR post:43

Speaking of VBS scripts, the same procedure failed to work…
…So it seems, unlike with rundll32.exe, you can’t control what scripts wscript.exe is allowed to execute.

Thanks, Marat, for testing that approach. At least we know now that it doesn’t work.

@MaratR post:43

If anyone wants to experiment with the wscript.exe issue, I have a small VBS script (originally posted by pykko here on the forum) attached to this message. It launches your web browser and opens the Google webpage, nothing dangerous.

Thanks for the script! I was looking for appropriate one.

[tlu]

@MaratR post:38

Two general problems with rundll32 and wscript:

1. Comodo trusts these applications (they’re in the Safe list) without really knowing their behaviour, since their behaviour is defined by the dll’s and scripts they launch, and that could be anything. In my book, this breaks the concept of Clean PC / Train with Safe modes (most widely used), making them unsafe. The only mode that is really safe is Paranoid, which is not too practical, IMHO.

2. Comodo has only one ruleset for these executables. Which means that you can either create a single policy that would apply to any dll’s or scripts run by them (this is no good, because some functions could be required by both “good” dll’s/scripts and the “bad” ones, and you can’t differentiate between them), or have Comodo alert you every single time some dll/script is launched. The latter option is weak, too, since you won’t be presented with information on what dll/script is being launched, all you would see is an alert that the rundll32/wscipt is executed. Not practical at all.

I would be great to hear from Melih or Egeman if there is a chance that these problems are addressed somehow in the coming versions of CFP.

This is the area where any on-access anti-virus/anti-malware scanner will do a better job.

I think another way is applying a Software Restriction Policy as described on How to make a disallowed-by-default Software Restriction Policy . This can’t be done in XP Home, though.

[egemen]

@MaratR post:43

goodbrazer,

Great observations, thanks. You’re right about DLL’s - you can make Comodo treat them like executables by adding them to the Files To Watch list and setting the Image Execution Control Level to aggressive.

Unfortunately, you’re also right about the amount of alerts this brings in: when I launched wscript.exe to run a simple script (more on that later) I had around 45 (!) of them, and I have no idea how some of them relate to the script. Surely, this level of protection can only be used with some sort of generalization in Computer Security Policy rules, like blocking all applications from executing any dll’s on drive d:, and allowing to execute dll’s on drive c:. Otherwise the number of alerts would drive anyone crazy.

Speaking of VBS scripts, the same procedure failed to work. I have *.vbs in the Files To Check list, and the same aggressive Execution Control Level. When a vbs script is run, Comodo comes up with a number of alerts - wscript accessing Service Control Manager, running cmd.exe (part of the script), 45 cases of dll execution, but still no mention of the script filename. So it seems, unlike with rundll32.exe, you can’t control what scripts wscript.exe is allowed to execute.

To double-check that, I created a rule for all aplications, blocking the execution of *.vbs. Placed on top of the Computer Security Policy list, it doesn’t prevent wscript.exe from executing D:\test.vbs.

If anyone wants to experiment with the wscript.exe issue, I have a small VBS script (originally posted by pykko here on the forum) attached to this message. It launches your web browser and opens the Google webpage, nothing dangerous.

Hi Guys,

Yep. The behavior of CFP 3 for such “unsafe” applications have been modified sligtly to mitigate the risks with the upcoming update(Tomorrow hopefully) so that without requiring paranoid configurations, the users will be able to cope with these issues.

With the later releases, we will introduce command-line parameters in D+ rules for more flexible configuration options.

Egemen

[goodbrazer]

Thanks Egemen :-TU

Really good news.

[asker]

@richo post:3

I like the fact that Comodo & other HIPS don’t require signatures. The real question is… can Comodo replace the need for an antivirus program, especially real time monitoring?

Hi.
I had that same question and browsed forums for the answer. And i found it. A good hips is very much capable of blocking any malware attempts of penetrating your system, but it DOES NOT remove malware. For that, you need an antivirus or antispyware. I know I did not fully answered your question, but now it is up to you, if you only want to have malware blocked, or blocked and removed as well. For the latter you need virus-removing tool, which is most common anti-virus program.
Seems complicated but it is not. I do recommend you a good hips (defense+, threatfire, defensewall (paid) ) and a good antivirus product. If you add sandboxing program, combined by a good browser such opera or firefox, you are pretty much defended almost bulletproof. I assume you also use comodo firewall, which is a predisposition of safaty (:HUG)

Tomy