MRG Rogue Software Test

Yes, classical HIPS, as far as I know, has always warned the user of any new execution, and thus acts like an anti-executable. That's why I like classical HIPS so much. You have incredible control over your system.

And yes, I do agree that Defense+ should not be used in a test like MRG's to compare against an antivirus/behaviour-blocker, as it will not be fair haha. The classical HIPS will always block all the malware, and also all the good-ware haha. Anyway, that's the beauty of classical HIPS - if you're uncertain about an execution alert, block it or isolate it, and then go look it up.

As I said, you can think of classical HIPS as always having 100% detection rates, and in some ways, a horrible false positive rate too. But a classical HIPS with a decent white-listing database and that starts with a clean PC (hence "Clean PC Mode" for Comodo) will not give many pop-ups at all. The pop-ups will mainly come about when installing new applications etc, in which you can simply switch to "installation mode".

 

Therein lies the rub with a lot of the rogue applications out there today; they appear legitimate and, therefore, will execute legitimately. Many virus analysts will tell you a lot of these don't contain malicious code; in some cases, the applications contain buggy code, which is not the analysts' job to decipher. The only downside really is extortion i.e. to try to get you to part with your cash. How AVs/HIPS can detect such intent is a difficult area without more analysis than they probably have time for, and this is borne out by the apparent numbers that are not detected by some anti-malware programs.

 

Dude, even if the rogue application doesn't execute any dodgy processes, the classical HIPS will ALWAYS flag it. A classical HIPS is NOT a behaviour-blocker mate. Any new .exe file etc will always be flagged by a classical HIPS, no matter if it's good-ware or malware. If the specific file has been added to the HIPS' white-listing database (and therefore has been deemed safe), then there is nothing to worry about anyway.

 

Exactly, and perhaps that is the issue. Should they be white-listing them? It's much like the virus analysts saying files fine, no malware here. I've sent rogues off for analysis to be told that on a few occasions. Granted, the files are fine in terms of not containing malware, but they're still rogues by definition of intent and not to be trusted. I won't fall for them, and neither will most here, but unfortunately, a lot out there do and don't have the same knowledge or expertise as we do.

I guess the real question is should AVs/AMs/HIPS warn users about such applications, which are basically frauds/scams? If so, how best to do that considering most don't contain malware?

 

I see your point.

I guess in the end, if you're unsure about an executable file, don't execute it, or use a VM to test it. It's always good to put the file in question through virustotal etc too.

But if an anti-malware company has purposefully white-listed the applications in question, you can be very sure that they are safe. As I said, I'm keen to get hold of the "rogue" software that Comodo have added to their white-list.

 

The applications may be safe to run, but the results they give in their scans are often erroneous, and so the clueless user ends up paying to get that fixed. When we hear of these stories, we shout it's a scam, it's a rogue, oh you shouldn't have done that etc. This is the difficulty; how do we help those users understand that while the files are apparently safe to run, they are in fact bogus, which is really what this is all about.

I appreciate there are services like WOT which can alert users to rogue websites so they're warned when looking for free anti-virus, for example, and these are useful in that regard. Others have existing anti-malware installed, but they go to install a registry fixer of some description, but don't have any of the link checkers installed. AV says it's fine, but invariably they get messed up because of sloppy code in the program they just downloaded, and some even pay to get the alleged errors fixed.

This seems to be more and more of a problem these days, and I think we should be looking at ways to try to prevent those users falling prey to such tactics.

 

Dude, Comodo's HIPS would not purposefully white-list an application if it's trying to steal money from you (even if it's safe to run). Classical HIPS is default deny or default ask questions haha.

As I've repeated, the white-listed applications are white-listed because they are not "rogue" software at all. They are genuine software. If the program was "rogue", Comodo would never have purposefully white-listed the program. As far as I can tell, it takes quite a lot of doing to get on Comodo's white-list.

 

ummm....like what?

 

I'm not certain, but it will be a similar process to how OA creates their white-list and how DriveSentry etc. creates their white-list.

 

I think ssj is right on this one. I cant see a classical HIPS purposefully whitelisting a product that may be rogue. Theres a difference between an AM company refusing to list a rogue as malware and a classical HIPS maker iintentionally whitelisting it so that it can bypass its protections. If they whitelist a product it will be only those they are absolutely certain it is safe. They will not only coonsider the product but the company behind the product and the reputation of the company and the product. The whitelist is only for known reputable programs, not any old program which doesnt seem to be maliciious.

 

well not testing Kaspersky Internet Security for both kis and kav results would be same as per sveta statement

and OA++ and comodo missing rogues entails that MRG was interested in allowing the initial execution and letting the subsequent layers catch the rogues which is confusing to say the least and dilutes the efficacy of hips..

 

If that's the case, I find the test result display very mis-leading:

Online Armor ++ (All Features Enabled) Failed to block the following Rogue Software samples:
Reg Genie

COMODO Internet Security (All Features Enabled) Failed to block the following Rogue Software samples:
PC On Point, Advanced Audio DJ Mixer, FTP and Download helper.

Note how they state "All Features Enabled", implying that the HIPS is enabled and used properly. In fact, if the HIPS component of each program was used properly, nothing would have "failed to block", as all you'd need to do is deny the initial execution of the file. Then, you'd do an on-demand scan with whatever on-demand scanner you have installed, run it past virustotal etc, or do a google search. If still in doubt, ask about it on Wilders haha. If you are itching to test out the program, run it in a sandboxed VM!

 

By the way, I'm pretty sure the majority of people on Wilders trust Softpedia right? Well, I think these are what Comodo Internet Security "failed to block":

http://www.softpedia.com/progDownload/Advanced-FTP-and-Download-Helper-Download-93598.html
http://www.softpedia.com/get/Multimedia/Audio/Audio-Players/Advanced-Audio-DJ-Mixer.shtml
http://www.softpedia.com/progDownload/PC-On-Point-Download-45885.html

Guess why Comodo's Defense+ failed to block those 3? Well, it's because they are not "rogue" software - they are genuine software! And Comodo have added those to their white-list database.

And this is what Online Armor "failed to block":

http://www.softpedia.com/progDownload/RegGenie-Download-112567.html

Again, this is not "rogue" software, and is in fact genuine software! Online Armor must have added it to their white-list database.

 

Yes, but your reasoning could go the other way also. Comodo caught the 1 OA missed and OA flagged the 3 comodo missed and prevx and emsisoft flagged them all. Must be something there. I would trust the security vendors before softpedia.

 

Indeed, but I'm fairly sure Prevx and emsisoft flagged many false positives - that is, they flagged some programs which are not "rogue" software, and are in fact genuine software.

Also, you seem to have missed the point of how a classical HIPS works, and how a white-list database is implemented into a classical HIPS. Only completely trusted software will make this white-list. If the software is unknown (even if it has the same name as a white-listed software program), the HIPS will always ask the question of whether you want to allow its execution.

Anyway, here is some further evidence that the "rogue" software is in fact not rogue at all.
virustotal gives the following results for the 4 "rogue" software that Comodo and OA "failed to block":
1. pconpoint.exe: 3/41 (a-squared, Ikarus, Prevx)
2. RegGenieSetup.exe: 0/40
3. sdam.exe: 6/41 (a-squared, Ikarus, McAfee+Artemis, Norman, Panda, Prevx)
4. sdfh.exe: 6/41 (a-squared, Ikarus, McAfee+Artemis, Norman, Panda, Prevx)

I also scanned all 4 files with my Avira AntiVir with highest heuristics, and it all came out clean.

So this is all rather interesting. Some implications have arisen:
1. We all know that a-squared and Prevx have a history of high false positive rates. Could it be that they are flagging these genuine software programs as malware?
2. RegGenie scored 0/40 on virustotal! This makes me more confident that OA did not block it simply because it has been white-listed
3. NOD32, Kaspersky, Norton, AVG, Avast, GData (these are generally highly respected Antivirus products) all say that these 4 software programs are clean, based on their signatures.
4. I can confirm that Avira AntiVir says that all 4 of these software programs are clean, with highest heuristics setting.

Anyway, I might have just wasted my time here, as perhaps those 4 files were not the files that were tested haha. But I'm pretty sure they were.

 

ssj100: These files are not false positives - pconpoint.exe finds 134 problems on my completely empty Windows XP SP3 image and requires payment to clean these non-existent issues, RegGenie found 158 errors and requires payment to clean all of them (which also don't exist) and sdam.exe/sdfh.exe both install RelevantKnowledge spyware (make sure you test with an internet connection active so that you receive the prompts.

I'm surprised you could say a-squared or Prevx have high false positives when you find it acceptable to receive a FP on every installed program from a HIPS

The samples are clearly rogue and these programs are incorrect - the test I just ran can be reproduced anywhere: just install an empty XP SP3 image and try them Rogues do require manual analysis to find and we've seen many cases of AV researchers being misled to trusting a signature because the program literally does nothing bad on the system, just tricks users into paying for it.

 

i prefer to deal with a FP than a missed malware

 

I see, and thanks for that PrevxHelp.

By the way, I just tried running all of those 4 software programs and Defense+ gave a pop-up for each of them, and successfully blocked each of them from running easily.

Dude, you of all people should know that you can't compare a classical HIPS to an antivirus/behaviour-blocker. A classical HIPS will always ask you what you want to do for any unknown file in question, while an antivirus/behaviour-blocker will miss a lot of genuine malware. Also, the classical HIPS will never say a file is malware for sure, and therefore in theory, it will never give a false positive.

Anyway, good try haha.

But seriously, thanks for those other bits of information.

And MRG, how did Comodo fail to block those 3 software programs? I just tested it, and Defense+ easily blocked all 3.
EDIT: this means that those 4 files that I have illustrated are NOT in Comodo's white-list. And since PrevxHelp has confirmed they are malware, that's a good thing!
EDIT2: Quite incredible that Avira, NOD32, Kaspersky, Avast, AVG, GData did not flag these programs as malware. Makes me even more glad that I no longer rely on black-listing/behaviour-blocking at all.

 

One of the rogues missed by Online Armor ++ is digitally signed by Comodo. OA did not perform the scan using the A2/Ikarus engine because it believed the signature to be trusted.

Our investigations showed that the signature was not trusted - we have fixed the bug, and patch is being prepared for release ASAP.

Cheers,


Mike

 

Strange that it's digitally signed by Comodo and yet my Defense+ gives a pop-up when it tries to execute. I thought if something was trusted by Comodo, then Defense+ would stay silent right?

And Mike, can you confirm that OA's HIPS also failed to block this rogue? I just can't believe that OA's HIPS would fail to give an initial execution alert.

EDIT: also, someone better tell these guys that RegGenie is rogue-ware:
http://ezinearticles.com/?RegGenie---Does-This-New-Registry-Cleaner-Work?&id=2316413
http://download.cnet.com/RegGenie/3000-2094_4-10913403.html
http://www.softpedia.com/get/Tweak/Registry-Tweak/RegGenie.shtml

 

comodo signed rogue

well that by default is risky isn't it?

 

I don't know how Defense+ works, so I can't comment.

Assuming an out of the box install of OA, all default options, when a file is executed the following things happen:

1st - check the hash of the file against the local whitelist. If we get a safe decision here, no more processing.

2nd - check the digital signature of the file against the local siglist. If the signature is trusted (or not) then we're done - no more processing.

3rd - if the ++ engine is installed, perform an AV Scan. If we get a hit, display a dirty great big red prompt.

If we still do not have a "safe" decision then ask the user what to do. If we've found it to be a "red" decision, alert the user.

So what's happened here is that we've found the signature is trusted - and let it past. In the case with this signature, it's a bug which allowed it to happen. This signature is *not* on our safelist (generally speaking, Usertrust signatures do not make it on our safelist).


Mike

 

Yes, based on my findings with Defense+, it seems that signature did *not* make it on to Comodo's safelist either.

Also, sounds like a very strange bug Mike. But as usual, you guys fix things very quickly. Keep it up!

 

I'm not getting involved in that debate, it's already caused enough trouble.

Not if everything works as intended. If you have an application which is signed by a trusted vendor and it has not been tampered with it is not necessary to run an AV scan on it. The most you could possibly hope to achieve by doing so is an FP.

 

Yes, I'm also staying quiet with regards to that issue haha. I doubt anyone would be brave enough to bring up this issue in this very sensitive thread already.

Yes, and as Mike said, it was just a bug that cause OA to be "bypassed".

Anyway, I'd like to know how MRG tested Comodo too. I just ran those 3 rogues again that apparently "bypassed" Comodo, and Defense+ gave a pop-up and blocked them all easily. I'm running in Clean PC Mode, Proactive Security. Thanks for any feedback MRG.