A Little Concerned :(

I'm a little worried over a possible oversight by NOD32. If you go to the eicar site you will see eight versions of the test file now, including SSL protected files. The non-protected files are detected by IMON, as they should be but the protected files, even after accepting the certificate, as not detected by NOD32; not by IMON, or even AMON once they are written to the disk. Why is that? Other AVs, such as Dr Web, detect all protected eicar file upon disk write. This could be an area that NOD32 should rectify.

 

@n8chavez

I'd check the settings you have for AMON on your system. Works like a champ on my computer:



As you can see it actually picked the temp file up even before Firefox gave me an option to save it.

I'd check your setup against Blackspear's Settings and try again. As it stands IMON does not scan SSL traffic so AMON takes care of detecting the virus (or in this case Eicar) when it is DLed to the PC.

-Cov

 

Also works here with IE6 .

Have you tried the txt and the comd file which are encrupted , they should work . The others (zipped files) are not detected by AMON because it doesn't scan archives in real time

 

Good call. Didn't think about that one. NOD32 does go nuts when you try to open that Zip file though.

-Cov

 

Okay, just to be sure, you guys are talking about the SSL protected test files, right? I have my setting configured appropriately. (I use the nod32-av.com installer) But the zip files are still not detected by IMON. The .com file was though. I've had no issue with the non-protected files, com, txt, zip1, or zip2. All of those were detected by IMON. Why then does it not work the same way for the protected files?

 

With the Eicar Test file (on Eicar Organisation's official page www.eicar.org) you have 8 files you can play with to test

4 are normal
4 are encrupted (SSL)

On the other hand you have NOD32 -> AMON and IMON
AMON is the resident protection scanning everything on-access,on-create and on-execute . It scans all files but doesn't scan archives (zip,rar...) except from self-extract archives
IMON is the internet monitor , which protects mails (pop3) and html (http) . It works on the early level Winsock to be able to control the situation (what enters the PC) It can scan all kind of files including archives , however IMON can't scan encrupted communitcation . That's why it is encrupted because it should be encrupted and nobody should be able to read it . If IMON was able to detect the encrupted stuff , this communication wouldn't have been safe (e.g. encrupted bank transfers...)

Let's get back on the topic , the first 4 files are detected both from IMON (and if IMON is off , then by AMON) -> no problems

The latest 4 , the encrupted . The first (com) is detected only by AMON because IMON can't scan encrupted stuff . The same applies for the second one (txt)
The 3rd and the 4th are encrupted (IMON can't scan them) and are aslo ZIP files (archives) so AMON can't scan them , too . Although they are not scanned , if you save them on your PC , this "pottential" malware can't affect you unless it is unpacked . When unpacked , AMON takes place and deletes the malware (Move newly created files to quarantine )

 

Thank you for that. Although that lengthy explanation was not required. There is a chink in NOD32's armor; NOD32, more specifically AMON and IMON, should be able to scan inside archives. That, I'd have to say, is a real problem. Other AVs can do this, as I've mentioned. It kind of makes the user feel less protected even if that may not be true.

 

no problem

 

SSL is not scanned by IMON whatsoever as the data is encrypted and IMON does not understand it. However, AMON will scan any file you save to the disk with the exception of archives that would be scanned upon extraction.

 

i believe it is done on purpose. if AMON scanned archives in realtime, it would cause a performance hit.

 

AMON actually scans withing SFX archives on create as many threats spread in SFX archives. However, this may have an adverse effect on performance so one might want to disable this option in the AMON setup.

 

This is not exactly true. As I said before, Dr Web scan archives in real time via SpiderGuard and there's no slowdown

 

i stand corrected. and actually, i think kav scans archives in realtime too.

 

I've done some tests with the 2 ssl file and the result are those:
1) file eicar.com ssl : with ie and firefox the amon popup and get the test file
2) file eicar.com.txt : opened with firefox i don't get any popup about virus by inod, opened with IE 6 i get the popup but the file is already loaded into the ie browser page.

 

Yes, that is true. They actually do something that I think it rather neat too: It scan encrypted ports. This is very usefil for instances such as this or for anyone that uses Gmail (which uses SSL POP3: 995) Hint Hint!!!! Eset please add to v3.

 

This is a bit off-topic, but just wondering...
Can I know what you mean by "scan archives in real-time"? Do you mean that Dr.Web treats archives same as any other files? So if for example I browse a folder on my PC and I single-click with my mouse on an archive (I mark it) that is about f.ex. 500 MBs, with a couple of hundred files inside, it will scan the entire archive before I even open it? Or do you mean upon opening it?

If it's the latter, then doesn't it mean the files have already been stored in cache (isn't that what WinRAR etc. do directly when opening an archive?), and that the file(s) that Dr.Web is scanning is actually what's been placed in cache and not really the file(s) in the archive itself? Or am I mistaken about how WinRAR (and any other archiver/un-archiver works)? And does this again mean that NOD32's AMON "ignores" the files that are placed in cache ("infected" files are not detected until extraction)? Not a big deal since most programs should clean up the cache after themselves.

 

I don't want to misstate any information, which I will probably do. But I have had archives where there was malware inside being detected upon a signle click, as you described above. But the archive I generally use, and those that contained malware were no where near 500 meg. So that being said I cannot tell you for sure if Dr Web can actively scan archives that are that large. But I can say that you are somewhat right; general the practice with most AVs and archivers is to have the archive extracted to a temporary location. I do not believe this is the case with Dr Web's equivalent of AMON and IMOM ,SpiderGuard for Dr Web is both when you are not using SpiderGate. SpiderGate, which is now in beta, Dr Web's IMON, will be able to scan everything before it is downloaded. But SpiderGuard acts diferently that AMON in that it can scan archives on-the-fly. This is something that apparenty AMON cannot do, else it would have caught the SSL eicar zips.

AMON does not ignore cachede files. Once the file is no longer archived, AMON will spring into action, as you can see with the non-encrypted and encrypted eircar com files. In that way you are safe. NOD32 just does not have the same capabilities that Dr Web has in on-the-fly archive scanning.

 

its odd because kav can scan archives on the fly as well. will nod32 be able to in version 3.0?

 

Let's hope so. As of right now no one knows anything about v3. And if they do they're not sharing.

 

your right. i dont mind it taking ages because then it will be as good as 2.5 is. and no rush it out and fix the bugs later=p

 

Nor do I. The lack of information is what is unsettling. I do wish they would add archive scanning to "AMON."

 

i agree i think they should provide more info.

 

Since KAV is taking a page from NOD's playbook and dramatically improving heuristics, maybe NOD should do the same from KAV. Kaspersky has a great features of being able to scan SSL encrypted ports, which is great for Gmail users. That same technology could be used to scan files such as the SSL protected eicar. Would this then be an acceptable solution? IMON would be able to scan it, as it currently can with the non-encrypted eicar. Then not effecting AMON or resource usage.

BTW...I understand that the eicar file itself is harmless but it is just one more hole that NOD could close if it wanted to.

 

i agree because it would be an extra layer of protection.