Is email more secure when not letting any zipped content through?

Question

Ah. This is a bit of a soft question, but I though there might be some here that can share some insight.

I'm a developer. Sometimes I need to send a (bugfixed) DLL or EXE file to a customer. If this customer is in a big company, here's what I do:

1. Rename the executable file (module.dll -> module.d__)
2. zip the file with password so that it cannot be unzipped by the mail server
3. rename the zip file (module.7z -> module.7.txt)
4. send this via email and add a lengthy explanation for the guy at the other end on how to get at the file
5. cross fingers that it'll get through the filters

Now, I can understand that email filters won't allow bare exe attachments.

What I fail to grasp is, how making email server filters unzip all attachments and then additionally check the unzipped files for executables regardless of their extension is adding any security. A zip-file won't suddenly explode in the users face. He'll have to unzip the file to get at any potentially malicious content. If you can get him to unzip a file, you get get him to jump through the hoops I described above.

Insights?

Answer 1

Well, a bare executable is dangerous in that some users will try to execute it. They should not, they were told they must not, yet they do.

A Zip file, possibly renamed, containing possibly renamed executable files, is also dangerous because some users will rename files, do the unzip, and execute what they find within. They should not, they were told they must not, yet they do.

I have received email virus which used a renamed Zip archive with renamed contents and a password. The email contained detailed instructions on how to "open" the archive, and a "motivation speech" (usually, the promise of a naked female celebrity, sometimes threats of a fiscal nature). That I have received such emails shows that at least some users, somewhere, followed the instructions and got infected. Sad but true.

Email filters try to strike the right spot between insecurity and extreme user annoyance. So they will let pass some cleverly concealed threats, if blocking them would imply stop doing any business. In your case, you are quite happy to be able to send your EXE or DLL through. In that view, blocking unrenamed Zip archives is a "minor annoyance" (which you are effectively working around, hence the "minor") but does block a substantial amount of virus and malware. Blocking more would be "more secure" but would escalate the annoyance to "major" level.

Answer 2

I think there is definitely an element of truth in your last sentence there - the problem is that the perimeter controls aren't effective.

If you are going to scan at the perimeter you need to make sure your controls are set up so that either the file gets scanned, or it doesn't get allowed through. Then it works as expected - anything entering is scanned for malicious payload.

What you have described, however, is a workaround which can reduce security, as it takes advantage of a very simple check - looking for a zip file by extension, which fails - thus allowing any content to pass the perimeter controls.

A correct way to do this (there are others) is to implement an enterprise secure email solution that provides secure transport, assesses a file based on what it is, not what it's extension is, as well as a way to scan everything at the perimeter, both incoming and outgoing.