Add option to block mail with zip files that contain supicious file e…

[Udera]

…xtensions

Over the last weeks, there were a lot of spam mails with contagious attachments. Many were hidden in zip-files and if you don't want to block zip-attachments in general, you can block certain file-extensions of files within the zip archive. I implemented this solution:
http://www.gossamer-threads.com/lists/exim/users/98336#98336

It is turned off by default.

[Udera]

I have this option running for a few days and it seems to be quite successful. I'm not sure what you feeling is about this function if we should implement this already in 2.3 or wait for 2.3.1 and if it should be enabled by default.

[runout-at]

i'd like to get his soon into the release.
i did my own implementation last week, but i like yours more because it doesn't need an external shell script.

[Udera]

OK, I verified with a several TB large zip-bomb, this doesn't affect the server. So let's add this optional feature.

[runout-at]

i tried your implementation and just got a .wsf (included in an .zip) in my mailbox.
the .wsf contains JS-code

unzip was not found in the path...
i did correct this now.

[Udera]

what system are you using?

[runout-at]

debian jessie. but i used 7zip. so i installed unzip now :)
the issue was on my side.

[runout-at]

i just got an email through this filter.
i'm not sure yet why this happened.

maybe...
only the first attached file is checked? not all attachements?
or the mail did come from a logged in user/system (forward from gmail). i have to check this.

anyways i would suggest to remove the !authenticated = * because if a mail is forwarded by an other system (with a login) and this system did not do a check we will accept the virus blindly.

from the message:
the first attachement was a jpeg, the second a zip:

Content-Type: application/x-zip-compressed; 
        name="Miriam Rotfinger - Bewerbungsunterlagen.zip"
Content-Disposition: attachment; 
        filename="Miriam Rotfinger - Bewerbungsunterlagen.zip"
Content-Transfer-Encoding: base64
X-Attachment-Id: 6bc8293217b159e_0.2

[rimas-kudelis]

Gmail does not log into your server when forwarding messages, and I'm not sure what other "logged in" systems you might be talking about here. Care to explain?

[rimas-kudelis]

I'd like to discuss the idea of this patch here a bit.

I personally don't quite like this approach for a few reasons:

• by blocking all *.exe files, you're also blocking legitimate ones. It's of course not very common to send these by mail nowadays (mostly due to similar policies of e.g. Gmail, I would guess), but still, there are sometimes valid reasons to do this.
• I tend to think that blocking attachments this way only shifts the problem elsewhere: if the user in question is clueless enough to open random attachments, they will probably have a tendency to click on links as well, which means they might just end up downloading same virus/trojan from Dropbox or a hacked web server. I think that actually allowing these attachments (especially in .zip files) is a more secure solution, if you have a good antivirus filter.
• This particular implementation applies the policy system-wide. I think it should be a per-user setting, similar to SA and AV checks, in Vexim 3.0. Otherwise, I could ask why this is globally on, but AV scanning is not.

Regarding the second point: sadly, I've experienced lately that Clamav isn't as reliable as I thought it would be – it sometimes lets trojans through for weeks after they start circulating around. I've learned Clamav lacks manpower, so they're not to be blamed, but the bottom line is, this antivirus is likely less reliable than some other solutions. On the other hand, there are projects like extremeshok/clamav-unofficial-sigs, which provide unofficial signatures for Clamav, and might help lessen the gap.

[runout-at]

gmail is using 'my' server as a smarthost because it is sending 'from' an account of a domain of 'my' server.

i now checked this and this is really the case.
for now i deactivated the !authenticated = * line.

I agree with your statement @rimas-kudelis. It's just shifting the problem.
But on the other hand i had already 3 times this summer the Problem that users jut open anything they get per email. And to use dropbox or other file sharing systems is a little more complicated than opening an attachement of an email.

about clamav: i already have seen provider which use 2 different virus scanners on every email. even the samba plugin of clamav is not maintaned/working anymore.

per user setting: would be nice, but i'd like to have a non override policy too. i think for vexim 3.0 we should discuss more such features.

[rimas-kudelis]

Override policy just for this doesn't make sense. We should either allow locking settings for AV and SA as well, or not allow locking them at all.

Regarding ClamAV, I'm currently testing third party signatures. Hoping to find something free and reliable...

[Udera]

Hmm, I'm actually not very happy with this patch either but I don't see a good alternative. This summer I was hit by a large number of such fishing mails - some of them were very pretty good. The problem was, if you were hit by one of the first waves, there was no protection. Neither hash-sum checks of spamassassin (ixHash & others), they kicked in later, nor anti-virus software. On virustotal you could literally observer how fast anti-virus companies were reacting.

How many legitimate *.exe files are still send in zip-files? Clearly, it doesn't solve the problem, however it does in some way. A company can send you an invoice via mail (usually not in a zip-file containing *.exe-files) or they ask you to login into the customer interface. You bank sending you a fishy invoice to be downloaded from dropbox??

In this PR #142 I had the idea that we enforce a valid DKIM signature from certain senders who never send user mails (problem with mailinglists) and which are subject to phishing very often (paypal, banks, or who have a Author Domain Signing Policy The problem was that some of these mails are signed with several dkim-signatures (when other sending mailservers were used, e.g via amazon/google). If we figure this out properly, we could at least prevent phishing mails from *@paypal.com. Unfortunately, the sender is often not visible, so users can be tricked by:
From: Paypal Service <no-reply@my-paypal.com>. Not sure if we could just block anything with "paypal" (either name or address part) in the from header unless there is a valid dkim from paypal. Not sure if we find a good and efficient solution without false positives.

Or as most of the spam is from hijacked residential accesses, we could implement greylisting only for these dynamic-looking ips (hostname: dialin-*, ...). Authenticated users can send without restrictions.