ZIP file attachment not recognized and therefore no file check performed

Steve Freegard steve.freegard at fsl.com
Wed Oct 16 15:24:15 IST 2013


Tony,

On 16/10/13 14:30, Tony Larco wrote:
> The attachment was a zipped up EXE file, but something was unique about
> these messages.  We block ZIP and EXE files to most of our users, but
> our MailScanner instance was not acknowledging these emails contained a
> ZIP file and therefore not doing the "Filename Check".  What is very
> interesting is when MailScanner delivered the email to an invalid
> recipient and it was bounced back to the sender, MailScanner detected
> the existence of a ZIP file and blocked it on the way out!  But not on
> the way in!  This is the heart of the issue... how can we determine why
> these messages were not interrogated while other (legit) zip files were
> being rejected at the same time?
> 
> We observed these emails were encoded with windows-1251 encoding
> (http://en.wikipedia.org/wiki/Windows-1251) and the content type of the
> attachment was simply "Content Type ;"  Other than that, we did not see
> anything out of the ordinary with these emails. 
> 
> We tried to create a zip file of the same name as the malware and send
> it from gmail and the ZIP file was detected immediately by MailScanner,
> so we were not able to reproduce the problem strictly by name.  Now that
> F-prot is detecting this, its getting dropped for containing a virus,
> and we can really cannot test further in our production environment.  We
> took this into our lab, but we were not testing with the exact same
> version of MailScanner and we were not able to recreate the problem.  In
> our minds, whether MailScanner could detect the virus or not, it should
> have detected the ZIP and/or EXE and rejected it for this reason alone. 

Being as MailScanner caught it on the way out - I suspect you have a
ruleset somewhere that was bypassing the scans for the hosts that were
sending them.

Look for rulesets on:

Dangerous Content Scanning
Maximum Archive Depth (make sure this isn't set to 0)
Find Archives By Content
Archives: Allow Filenames
Archives: Deny Filesname
Archives: Filename Rules

If that doesn't yield anything - then I would set:

Log Permitted Filenames = yes

And then if one comes through you can simply look at the logs and see if
the file was even noticed by MailScanner (which it wouldn't be if
Maximum Archive Depth = 0 or if the file is hitting an allow rule).

The important thing when testing is that you emulate the client that
send the message exactly.   Same IP, HELO/EHLO, MAIL FROM, RCPT TO and
message data.   If you are using Postfix then you can use XCLIENT to
emulate the IP of the sender e.g.  XCLIENT ADDR=1.2.3.4

Alternatively - you can use the ruleset tester, but then you're only
testing one rule by hand e.g.:

[root at mta41 ~]# MailScanner --value="Maximum Archive Depth"
--from=foo at bar.com --to=smf at fsl.com --ip 1.2.3.4
Looked up internal option name "maxzipdepth"
With sender = foo at bar.com
  recipient = smf at fsl.com
Client IP = 1.2.3.4
Virus =
Result is "3"

Hope that points you in the right direction.

Kind regards,
Steve.





More information about the MailScanner mailing list