Enhancing E-Mail Security With Procmail

Un-mangling mangled filenames and attachments

Mangled ("defanged") attachment filenames

The sanitizer mangles the names of executable attachments in order to force the recipient to save the attachment to disk and rename it before opening it. This gives the user's antivirus software a chance to examine the attachment (as it is being written out to disk) before it starts running.

What is considered "executable" is fairly broad; in addition to the familiar .EXE programs, scripts in languages such as VBScript (.VBS), Javascript (.JS) and Perl (.pl), Windows Shortcuts (.PIF and .LNK), screen savers (.scr) and code libraries (.DLL and .OCX) are all executable. Since documents and spreadsheets can carry complex scripting and macros, .DOC and .XLS and related files are also considered executable. Finally, poorly-designed data file formats such as Windows help files (.hlp and .chm) and Windows Media files (.wmf) can carry scripting commands that can be used to attack a computer.

Unmangling a mangled attachment filename is very easy. In the case of Outlook, simply right-click on the attachment icon and select "Save as..." from the menu that pops up. Before saving the document, edit the recommended filename to take out the defanging text, leaving the original extension. The procedure will be similar in other mail clients.

For example, an attachment whose filename has been mangled into USELESS_EYE_CANDY.DEFANGED12345-EXE is saved with the name USELESS_EYE_CANDY.EXE by simply deleting the "DEFANGED12345-".

The user then runs or opens the file the same way as any other file on their computer.

Poisoned attachments

The sanitizer makes it difficult to access poisoned attachments by altering the MIME header that describes the attachment, which makes it impossible for the mail program to see the original attachment contents properly. For example, here is a MIME attachment header and the first line of the base64 encoded attachment data:

------=_NextPart_000_0027_01BF26F5.91230E60_ Content-Type: application/octet-stream; name="byebye.vbs" Content-Transfer-Encoding: base64 MjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjL/wAARCAEgAa4DASIA

You would see this if you looked at your mailbox file using a text editor. Mail clients interpret the MIME header information to determine the type, filename and encoding of the attachment, and from that whether or not the attachments contents should be displayed.

To mangle this attachment, the sanitizer inserts a new set of MIME attachment headers before the original headers:

------=_NextPart_000_0027_01BF26F5.91230E60_ Content-Type: TEXT/PLAIN; X-Content-Security: NOTIFY X-Content-Security: REPORT: Trapped poisoned executable "byebye.vbs" X-Content-Security: QUARANTINE Content-Description: SECURITY WARNING SECURITY WARNING! The mail system has detected that the following attachment may contain hazardous executable code, is a suspicious file type or has a suspicious file name. Contact your system administrator immediately! Content-Type: application/octet-stream; name="byebye.16920DEFANGED-vbs" Content-Transfer-Encoding: base64 MjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjL/wAARCAEgAa4DASIA

Note that the original MIME header is intact and unchanged (except for the filename being mangled, which is performed separately from the attachment mangling), it is just moved to where it will not be interpreted as a MIME header by the user's mail program.

Also note that the encoded attachment itself is also unchanged. Because the MIME type of this part of the message has been changed to TEXT/PLAIN the encoded attachment will suddenly be visible in the mail client. This will make people think that the attachment has somehow been encoded so that they can't use it, which is not the case. The mail program no longer thinks the attachment is base64 encoded (because that part of the attachment header has been moved out of the way), so it no longer hides the base64 encoded attachment data from the user.

Attachment mangling does not result in any information loss.

Unmangling attachments

If you (as the administrator) wish to unmangle such a mangled attachment, it is assumed that you have access to the quarantine file and can make changes to it. You can edit the quarantine file with your favorite text editor, unmangle the attachment, and using a mail program on the gateway (for example, Pine) forward the message from the quarantine file to the intended recipient. The quarantine file is a standard *nix-format mailbox file and will be recognized by any *nix mail program.

To unmangle the attachment, just insert a copy of the MIME boundary string before the original attachment header. You will also have to remove the X-Content-Security: headers, or the sanitizer will quarantine the message again when you try to re-send it.

------=_NextPart_000_0027_01BF26F5.91230E60_ Content-Type: TEXT/PLAIN; X-Content-Security: NOTIFY X-Content-Security: REPORT: Trapped poisoned executable "byebye.vbs" X-Content-Security: QUARANTINE Content-Description: SECURITY WARNING SECURITY WARNING! The mail system has detected that the following attachment may contain hazardous executable code, is a suspicious file type or has a suspicious file name. Contact your system administrator immediately! ------=_NextPart_000_0027_01BF26F5.91230E60_ Content-Type: application/octet-stream; name="byebye.16920DEFANGED-vbs" Content-Transfer-Encoding: base64 MjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjL/wAARCAEgAa4DASIA

If you aren't quarantining poisoned messages, end users on *nix systems (or most any system where their mail isn't buried in some binary format and they have access to the raw MIME headers) can do this unmangling themselves. If the messages are stored in a database, the user may be able to save the message as a text file, make the changes, and re-read the file using their mail program.

Unmangling poisoned attachment filenames

If you also try to help the recipient out by unmangling the attachment filename instead of having them do it themselves, then the message will probably be poisoned and quarantined by the sanitizer all over again. There are several ways you can avoid this. One possibility is to modify your /etc/procmailrc file to something like the following:

:0 * ! ^From:.*<root@mydomain\.com> * ! ^X-Security: bypass sanitizer 954kJF64ljf8o6r { INCLUDERC=/etc/procmail/html-trap.procmail }

Use a different string of gibberish for the "bypass sanitizer" header so that someone who reads this documentation does not know how to bypass your sanitizer. If you want persons from offsite to be able to bypass the sanitizer, omit the test on the From: header. It is also possible to put a bypass code into the message subject, but doing this is very insecure and not recommended.

Then, while you are editing the message to unmangle the MIME header you can locate the headers for that message and add:

X-Security: bypass sanitizer 954kJF64ljf8o6r

...which will bypass the sanitizer when you re-send the message. You need to use your own secret gibberish string, of course, instead of the one given here. If you add a bypass code like this, you don't need to delete the X-Content-Security: headers while unmangling - the sanitizer is being bypassed, and therefore they'll not have any effects that you need to prevent.

I can be contacted at <jhardin@impsec.org> - you could also visit my home page.

I'd be very interested in hearing from people who'd be willing to translate this page.

Best viewed with Any Browser