I receive files in my email, that are blocked in both Postfix and Amavisd-new

mariourk · Aug 17, 2016

I'm a bit puzzled about this one. Maybe one of you can shed some light on this problem.

I block certain extensions on my mailserver, for obvious security reasons. However, today I got an email with a docm-file attached to it. And of course it was spam and it contained ransomware. And obviously, I do not want these emails delivered to the users.

The fact that I got this email in my inbox is odd, because docm is one of the blocked extensions. I should have been blocked with a mere mention in the logfiles and nothing more. So, I tried to email to file to myself, to see if blocking docm even worked. And sure enough, I got an error, telling me the extension is not allowed.

So, why did this email with a blocked extension got delivered to me anyway? How did they manage to get around the blocked extension measures and slip a potential ransomware outbreak into my network?

This seriously bugs me.

Murph · Aug 17, 2016

You'll need to start by showing us the actual configuration you are using to block particular file extensions, and the original 822 headers on the message plus any MIME headers within the body of a multipart message. The short and simple answer is that the message did not match against your blocking filters, but we can't possibly tell you why that happened without seeing both the filters and the message headers.

Please also tell us the versions of FreeBSD, Postfix, and Amavisd that are being used.

mariourk · Aug 17, 2016

Ok, this is what I have in Postfix.

main.cf

Code:

mime_header_checks = regexp:/usr/local/etc/postfix/mime_header_checks.regexp

mime_header_checks.regexp

Code:

/^\s*Content-(Disposition|Type).*name\s*=\s*"?(.+\.(lnk|asd|hlp|ocx|reg|bat|c[ho]m|cmd|exe|dll|vxd|pif|scr|hta|jse?|sh[mbs]|vb[esx]|ws[fh]|wav|wmf|zip|docm|js))"?\s*$/
   REJECT Attachment type not allowed. File "$2" has the extension "$3".

This is what I have in Amavisd-new

amavisd.conf

Code:

$banned_filename_re = new_RE(
   qr'\.[a-zA-Z][a-zA-Z0-9]{0,3}\.(vbs|pif|scr|bat|com|exe|dll|zip|docm)$'i,
);

And finally, this is the source of the email itself.

Code:

Return-Path: <orderconfirmation@esab.co.uk>
Delivered-To: my@email.com
Received: from my.mailserver.com (localhost [127.0.0.1])
    by my.mailserver.com (Postfix) with ESMTP id C51CFD1EC
    for <my@email.com>; Wed, 17 Aug 2016 16:21:11 +0200 (CEST)
X-Virus-Scanned: by amavisd-new at mailserver.com
X-Spam-Flag: NO
X-Spam-Score: 0.8
X-Spam-Level:
X-Spam-Status: No, score=0.8 tagged_above=0 required=4 tests=[BAYES_50=0.8]
    autolearn=ham autolearn_force=no
Received: from my.mailserver.com ([127.0.0.1])
    by my.mailserver.com (my.mailserver.com [127.0.0.1]) (amavisd-new, port 10024)
    with ESMTP id bmrEF4oDTxlG for <my@email.com>;
    Wed, 17 Aug 2016 16:21:08 +0200 (CEST)
Received: from some.othermailserver.com (some.othermailserver.com [111.222.333.444])
    by my.mailserver.com (Postfix) with ESMTP id EB154D1E0
    for <my@email.com>; Wed, 17 Aug 2016 16:21:07 +0200 (CEST)
Received: from broadband.actcorp.in (unknown [106.51.143.28])
    by some.othermailserver.com (Postfix) with ESMTP id 5E97F42DE6
    for <my@email.com>; Wed, 17 Aug 2016 16:20:41 +0200 (CEST)
Date: Wed, 17 Aug 2016 19:51:03 +0530
From: <orderconfirmation@esab.co.uk>
Reply-To: <orderconfirmation@esab.co.uk>
Subject: =?ISO-8859-1?Q?Order_Confirmation-7165-2794475-20160817-912268?=
To: <my@email.com>
Message-ID: <9630.4553.3923010.7343786960.564.0@mailserver.com>
Content-Type: multipart/mixed; boundary="409438842-54314-7343786960=:9630"
MIME-Version: 1.0

--409438842-54314-7343786960=:9630
Content-Transfer-Encoding: QUOTED-PRINTABLE
Content-Type: text/plain; charset="ISO-8859-1"

=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=
=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=
=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F
This communication and any files transmitted with it contain information wh=
ich is confidential and which may also be privileged. It is for the exclusi=
ve use of the intended recipient(s). If you are not the intended recipient(=
s), please note that any disclosure, copying, printing or use whatsoever of=
 this communication or the information contained in it is strictly prohibit=
ed. If you have received this communication in error, please notify us by e=
-mail or by telephone as above and then delete the e-mail together with any=
 copies of it.=A0

ESAB does not accept liability for the integrity of this message or for any=
 changes, which may occur in transmission due to network, machine or softwa=
re failure or manufacture or operator error. Although this communication an=
d any files transmitted with it are believed to be free of any virus or any=
 other defect which might affect any computer or IT system into which they =
are received and opened, it is the responsibility of the recipient to ensur=
e that they are virus free and no responsibility will be accepted by ESAB f=
or any loss or damage arising in any way from receipt or use thereof.=20
--409438842-54314-7343786960=:9630
Content-Type: application/vnd.ms-word.document.macroEnabled.12;
    name="=?ISO-8859-1?Q?Order_Confirmation-7165-2794475-20160817-912268.docm?="
Content-Transfer-Encoding: base64

A whole bunch of binary stuff, that is the actual file

--409438842-54314-7343786960=:9630--

Murph · Aug 17, 2016

mariourk said:

mime_header_checks.regexp

Code:

/^\s*Content-(Disposition|Type).*name\s*=\s*"?(.+\.(lnk|asd|hlp|ocx|reg|bat|c[ho]m|cmd|exe|dll|vxd|pif|scr|hta|jse?|sh[mbs]|vb[esx]|ws[fh]|wav|wmf|zip|docm|js))"?\s*$/
   REJECT Attachment type not allowed. File "$2" has the extension "$3".

Ok, your Postfix problem is that you are using an out of date version of that filter, which does not handle filenames wrapped in a character encoding. You can find the current version of it (which ignores the the optional character encoding) at http://www.postfix.org/header_checks.5.html. You should review the list of extensions in the official example, as it is not the same as your current configuration (in particular, it does not include .docm). N.B. the current example uses pcre, not regexp parsing, and there are differences between those two.

If the out of date version of the filter is a symptom of the Postfix config dating back a long way into history, this might be a good time to give it a thorough review against current Postfix docs, defaults, and examples. As always, being on the current version of Postfix is strongly recommended; but bringing the config up to date is often overlooked when updating the port/package and just as important as updating the binaries.

Personally, I use PCRE, and configure it as header_checks = pcre:$config_directory/header_checks.pcre, not mime_header_checks = …, to follow the official example. I'm unclear, and would need to do some testing or read the source to find out, if mime_header_checks applies to the outer/top header, or just to MIME headers within the message body. header_checks applies to both in a default config (because there is a default of mime_header_checks = $header_checks), and will also catch headers inside attached 822 messages via the default nested_header_checks = $header_checks.

As for Amavisd, it looks to me like there is a bug in the version you are using. With Postfix, we expect the raw header, so expect to have to deal with the encoding ourselves. With Amavisd, on the other hand, the name of the config var and all of the supplied examples imply that it will be the actual filename that is being matched, so I consider it a bug that Amavisd does not handle the optional character encoding before matching.

Murph · Aug 17, 2016

An interesting observation/anecdote. I was just perusing my mail logs, and happened to spot the same envelope sender bouncing off my server. In my case, it never got anywhere near Postfix, being caught in a greylist tarpit via this PF rule:

Code:

rdr on $ext_if proto tcp from any os Windows to any port smtp -> 127.0.0.1 port spamd

Your spam sample almost certainly originated from a Windows botnet. Spamhaus Zen might well have blocked it, as they are pretty good against botnets in general, but I can't be certain because I don't bother RBL-ing stuff that goes into the tarpit.

From the behaviour I'm seeing in my logs, it would also have probably been blocked by postscreen(8) with a more aggressive config (the style with deeper protocol compliance tests).

It might have been newly added to their DNS, but the innocent owner of the envelope sender domain has published a SPF record with hard fail enabled. This could also have been used to bounce the message before it entered your systems, with a suitable Postfix policy daemon.

mariourk · Aug 30, 2016

Hey Murph,

Apologies for the late response. A few weeks vacation interfered.

Thanks for the explanation and suggestions. I'll look into it.