There are common methods allowing bypassing of almost any content filtering software (antiviral products, CVP firewalls, mail attachment filters, etc). Multiple products have been found to be vulnerable to methods described below.
Credit:
The information has been provided by 3APA3A.
Bypassing attachment detection or invalid detection of attachment type:
Imagine administrator who sets his server to strip all mail attachments with dangerous extensions: '.exe', '.com', '.bat', '.cmd', '.pif', '.scr' etc. Now he is sure, that his users cannot get any executable file via e-mail. As will be explained below he is wrong. Because both the server and client software may use different ways to find attachments and different ways to determine the type of attachments. Further, some servers contain vulnerabilities preventing them from discovering attachments. There are few exploitation scenarios:
Encoded filename in Content-Type/Content-Disposition:
Most mail software determine whether a MIME encoded area is actually an attachment by looking for the 'name' attribute (usually found in the Content-Type) or by looking for the 'filename' attribute (usually located inside the Content-Disposition). If either 'name' or 'filename' attribute are not present most software will fail to find attachment.
Further, 'name' and 'filename' may contain encoded-words causing failure of malicious intent detection.
Usually Content-Type looks like:
Content-Type: application/binary; name="eicar.com"
Or
Content-Type: application/binary; name="=?us-ascii?Q?eicar=2Ecom?="
However, since there are different server algorithms, some may fail to check:
Alternatively any of these variants:
name=eicar.com
name=""eicar.com
name=eicar .com
name="eicar.com
name==?us-ascii?Q?eicar.com?=
name==?us-ascii?Q?eicar?=.com
name="eicar.=?us-ascii?Q?com?="
name="eicar.=?us-ascii?Q?com?=
name=eicar.=?us-ascii?Q?com?=
name=eicar.=?us-ascii?Q?co?=m
In case of names like these, many server will fail to detect the .com extension or to find an attachment all together (Note: base64 may be used instead of quoted-printable).
Another such example would be:
name="=?us-ascii?B?eica.com
In this case, the encoded word is incomplete and it is not clear if it should or should not be decoded from base64. Decoding will depend on client program's internal algorithms. Good content filtering software should try both.
Some programs also rely on boundary to detect attachments. If Content-Type contains something like "boundary==?koi8-r?Q?aaa?=" they may try to use boundary "aaa" while most clients will use "=?koi8-r?Q?aaa?=".
Another problem occurs when different software types try to decode an encoded word. For example, great deals of programs miss attachment if they are marked as:
Most client programs will use the last name or boundary, but good content filtering software should block that kind of messages or check all possible situations.
Exploitation of "poisoned NULL byte"
Since an ASCII's equivalent of a '0' (NULL) is usually regarded as a string terminator, a problem may occur when it is handled by different kinds of string manipulation algorithms. A NULL byte may be stored inside data that is encoded using base 64 or using quoted printable. There are many situations where a server and the client software may react to a NULL byte in different way. One such example is Outlook Express that treats a NULL byte as CRLF.
Filename and boundary (NULL related)
As you already know that treating the value of name="file.txt\0.exe" and name="file.exe\0.txt" incorrectly may prove to be dangerous since, neglecting to detect an '.exe' extension may result in the fatal execution of the program by the user.
MIME header and MIME body (NULL related)
Imagine a MIME part that looks like:
Content-type: text/plain; name=eicar.com
\0Any: text
EICAR-SIGNATURE
Client software may think that EICAR-SIGNATURE is beginning of file data, while content filtering software thinks it is a part of the header. Alternatively, vice versa. The only good solution is not allowing NULL bytes inside headers.
Exploitation of unsafe fgets() problem
This is a commonly found input validation bug found in many programs, it occurs while the program tries process incoming string inputs. It has nothing in common with overflowing a buffer but rather, the incorrect handling of large incoming strings.
Let us review a small example:
Imagine that the next code looks for an empty string of only '\n', in order to find the end of MIME headers:
while ( fgets(buffer, BUFFERSIZE, input) ) {
...
if (*buffer == '\n') header = 0;
...
}
You should notice that there is a bug in the way this code handles strings. Imagine that the string is of exactly BUFFERSIZE bytes long (last byte is '\n').
First fgets() call will return BUFFERSIZE-1 characters. The second call will return the string of only '\n' character. This will cause it to incorrectly believe that an empty string has been provided, where in fact this is not the case.
A lot of client and server software have these kinds of bugs. This makes it possible to fool certain types of software to detect headers there they should not, for example:
Header:(number of spaces)Content-Type: text/plain; name="eicar.exe"
Alternatively, like in case of the MIME header or MIME body, treat some header fields as a part of the body.
MIME part inside MIME part
This bug is very common in software that strip (almost blindly) attached files.
What will happen is that the 'bbb' part will be removed while the 'aaa' part will still contain the malicious eicar.com
UUENCODE problems
UUENCODE is an old format for transferring file attachments. Since the format does not require a MIME part, many software packages neglect to handle it properly.
In a classic case uuencoded files begins with
begin XXX filename.ext
(Where 'XXX' is the file permissions in octal encoding).
The problem occurs in filenames that contain spaces, for example:
begin 666 eicar .com
The following is a valid filename however an attachment filter may fail to check for the trailing extension since it is located after a space.
Additional space symbol
An additional space symbol at the end of filename or boundary may be treated in different ways by client and mail filtering software. For example:
boundary=aaa\r\r\n
May be treated by client software as either "aaa" or "aaa\r" and in both cases it should be checked. The same goes for filenames encoded in MIME or UUENCODE.
CR without LF
Currently it is known that Outlook Express treats <CR> without <LF> as end of line (Other software packages might do this as well). This makes it possible to create a Content-Type header and body invisible for content filtering software (as was reported by Valentijn Sessink).
Bypassing detection of potentially dangerous content
There are many software packages that try to detect and block (or remove) dangerous file content s (HTML strippers, antiviral products, etc). The inability of software to handle these specific data types makes it useless and even dangerously comforting (making the user/administrator think he is safe, while he is not).
Inability to check Unicode content
Multiple products (including Internet Explorer/Outlook Express) support Unicode encoding for text formats (this includes encoding for text/html).
Unicode (UCT-2) text begins with the 0xFFFE bytes followed by word characters in Intel byte order (less significant bit first). Content filtering software may fail to strip potentially dangerous information (scripts, ActiveX, etc) from a Unicode formatted text.
For example:
The "<script>" tag in Unicode will show up as: {'<', 0, 's', 0, 'c', 0, 'r', 0, 'i', 0, 'p', 0, 't', 0, '>', 0}
Inability to check UTF-7 content
Almost all MUA/Web client software supports UTF-7/UTF-8 encoding for text. Content filtering software may fail to strip dangerous content from UTF-7/UTF-8 encoded data.
For example:
The "<script>" tag in UTF-7 will show up as: <+AHM-+AGM-+AHI-+AGk-+AHA-+AHQ->.
Inability to check content marked as UTF-7/UTF-8
If a MUA or a Web client retrieves an UTF-7/UTF-8 encoded file, the attached file will be decoded, and not saved to disk.
The text "<+AHM-+AGM-+AHI-+AGk-+AHA-+AHQ->" will be decoded as "<script>" by Internet Explorer itself. However, if this UTF encoded text is included inside a file it will be saved without being decoded.
This may allow attackers to fool the software into thinking attached file should be decoded, when in fact it should not.
For example:
Content-Type: text/html;
charset=utf-7;
name="trojan.exe"
This header should not be decoded from utf-7 before checking its content, because it will be saved by Internet Explorer (or MUA) as is.
What should be done? What client software vendor should do:
Client software behavior should be as predictive as possible. Even small problems (like NULL bytes and unsafe fgets()) should be corrected. Configuration options to block dangerous content (for example, files with specific extensions) should be provided. If content does not correspond to standards, it should be ignored rather then tried to make some intuitive decision about it. Further, behavior should as close to RFC as possible. Messages that contain RFC violations should not be processed (or at the very least, the user should be warned about it).
What server software vendors should do:
Check all possible situations with all known client software. Report all bugs found (even if it does not seem to be security related but looks like RFC violation) to the vendors. Block content that does not conform to RFCs. Implement all possible encodings, and do not expect client software to support them fully.
What system administrators should do:
Never believe your system is protected against malware. Always build your network having in mind possibility of intrusion.
Protect:
Your users:
Have a written instruction and signed acceptable usage policy agreements. Instruct your users on how to deal with potentially dangerous software.
Your applications:
Use application level antiviral products/firewalls. Only application level antiviral products (for example antivirus for Outlook or for MS Office) can block malware by its behavior rather then signature. It allows catching of almost any malware.
Your workstations:
It is not enough to protect servers. It is very important to also protect your workstations. Even if your server software will miss a virus in e-mail, it may be caught on workstation than it will try to launch.
