Quarantining unknown malware
I was asked recently about how to go about holding .exe files in mail.box so that they could be reviewed by an administrator before being released if found to be acceptable 1.It is only necessary to consider this type of hack because of the
Example: Since 13:35 UTC yesterday, I have 17 samples of the beast displayed to the left here.
The most recent is only a few minutes old. All are confirmed now by CA as Win32.Glieder.CC (alias W32/Mitglieder.GB, Email-Worm.Win32.Bagle.eb, W32/Bagle.gen and Trojan.Lodear.B 2).
They continue to stroll past Trend Micro SMD with a fully up to date scan engine and signature file and our desktop AV is still unaware of them despite a promise by the vendor to publish signatures as soon as possible.
And so, clearly it is necessary to operate some form of quarantine on files where malware is undetected but may still be present. Your challenge is to implement it in an unobtrusive and safe manner without creating a huge additional administration burden.
- Here's what I wrote in reply:
I think leaving potential malware lying around in mail.box marked held or even dead is risky and would strongly counsel against it.
This is most especially true where there is AV software running on the Domino server as most such AV software uses held status to prevent delivery of email while it scans for viruses and then releases held emails when no malware is found. Your most probable failure mode is therefore this:- Domino server receives some new malware as a .exe file (unknown to local AV system using signature based detection).
- AV system marks it held while it scans.
- Server mail rule marks it held because it is an .exe
- AV scan finishes and finds no malware.
- AV scan releases held message.
- Live malware delivered to hapless user.
This is in fact a common issue and is why I do not recommend using held flags in mail rules.
Another failure mode is the one you anticipate - a message released having been held in mail.box on server A will be held again by the same rule on server B. It is possible to mitigate this by using different rule sets on the two servers, but you just created an admin nightmare.
The final failure mode is simply this - why hold only simple .exe files? Most malware doesn't show up as an .exe anyway. All of our most recent samples are .exe files, but zipped. You would need to hold .zip files too and this would be highly inconvenient.
We use Trend SMD (AV system) and have additional rules built in it which look for all sorts of suspicious file types (.pif, .bat, .scr and so on as well as .exe) both natively and in archives (.zip, .rar and so on). These rules when triggered redirect suspicious mail to an administrator for approval. Admins just don't approve the malware items (which are always very obviously malware even though most users couldn't spot them). They don't reject either because we don't want a bounce to go to an innocent bystander whose email address was spoofed as the sender of the malware in the first place.
- And still not a sign of Common Malware Enumeration either.
Category: Viruses and Worms
Technorati: Viruses and Worms
1. Chris Whisonant03/11/2005 15:02:27
Homepage: http://cwhisonant.blogspot.com
I just have my Barracuda stop all EXE files... =)
2. Chris Linfoot03/11/2005 15:31:16
What about zips?
3. Stoomaroo03/11/2005 19:06:33
Gotcha. Those *.zips are pesky.
I once tried to capture those *.zip files and hold them in a quarantine -- but what a logistical headache. You essentially end up spending a full-time SPAM administrator's job trying to fish through the stuff.
If you could programmatically find the *.exe file inside the *.zip - then I say destroy it.
Essentially, to minimize the disruption -- a simplified FTP service would be needed (or some similar service). Not as easy as a 'Just click "Send"' (I admit) but I have found that a 1-page email drafted by corporate communications (i.e. NOT IS/IT staff) cuts through most of the problems.
Stoomaroo
4. Paul Mooney04/11/2005 14:10:24
Homepage: http://www.pmooney.net
Hi Chris.. Just a guess, but is this related to the email I sent you? If so, I gave some more details here.
http://www.pmooney.net/blogsphe.nsf/d6plinks/PMOY-6HSGQU#comments
All external mail is stopped at the entry point and scanned. The environment is locked down and I am reluctant to use the Domino AV software on the cluster. My particular issue is based on internal emails only and to prevent misuse.
5. Chris Linfoot04/11/2005 14:21:02
It is partly but the subject is broader than that so I thought it deserved a wider audience.
If you are looking to police an internal threat, this also demonstrates the need to segregate the duties of inbound SMTP from all other mail routing tasks by operating them on separate servers (I see you have done this).
You could then operate a different rule set on the internal servers. Your problem remains though - the rule will trigger on every mail.box unless you start hacking about in the design and you don't want to do that.
I understand your reluctance to consider it but a third party app would do this for you very reliably.
- Trend SMD or
- Group IQ Suite
6. Paul Mooney04/11/2005 14:55:40
Homepage: http://www.pmooney.net
Totally agree on the products. If I had a choice, I would install Trend in a second.... but unfortunately no, and the AV of choice in there is unstable on every site I have seen it on.
So I want to try to use the tools that come "out of the box". I don't think I am alone on this, and it would definately be a worthwhile enhancement for Mail rules in general.
7. Chris Linfoot04/11/2005 15:18:36
Except that there is no rule in the box yet which does what you want...
8. Scott Iver04/11/2005 15:30:33
Chris, as I recall we had a breif email exchange on a related issue, tword the begining of this year.
I realize that not eveyone likes McAfee products, but I do recommend that anyone running Domino should at least evaluate their "GroupSheild" product. Unlike other AV scanners running in Domino, they use the "Dead" mail status in mail.box for AV scanning. Mail is marked Dead - Waiting for Virus Scan rather than simply "held" in the mail.box. This allows me to use a couple of rules for "mark message held" (when I need them). I don't run those rules full time, but it's nice to know that when I see a held message, I know it's not because of the AV, and I don't have the related problems as you do with held messages and the AV product releasing them.
Now if we could only get AV vendors to read your site!
9. Paul Mooney04/11/2005 16:38:33
Homepage: http://www.pmooney.net
I know their is no rule that will do what I want. Looks like I will have to customise the mail rules and add a extra "release" option to the mailbox.ntf file. But, it is an obvious feature request so I will log it with Lotus to see if they can make the enhancement (even in ND7.x)
The reason I am against the customisation is that on this site, I just consult, and therefore I am not there all the time. I find that these custom features are ok, as long as they are closely monitored.
Unable to post a comment? Please read this for a possible explanation...
- 
