[NEWS] Bypassing Content Filtering Software
From: support@securiteam.comDate: 02/18/02
- Previous message: support@securiteam.com: "[TOOL] Pluto, a Security Auditing Tool"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
From: support@securiteam.com To: list@securiteam.com Date: Mon, 18 Feb 2002 18:43:02 +0100 (CET)
The following security advisory is sent to the securiteam mailing list, and can be found at the SecuriTeam web site: http://www.securiteam.com
- - promotion
When was the last time you checked your server's security?
How about a monthly report?
http://www.AutomatedScanning.com - Know that you're safe.
- - - - - - - - -
Bypassing Content Filtering Software
------------------------------------------------------------------------
SUMMARY
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.
DETAILS
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:
Content-Type: text/plain; name==?us-ascii?Q?eicar.com?=
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:
Content-Type: text/plain;=?koi8-r?B?;name="eicar.exe";?=
Multiple filenames/boundaries
Another one point is how software behaves if there are multiple names or
boundary attributes.
Example:
Content-Type: text/plain;
name="safe.txt";
name="eicar.com"
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.
Example:
--aaa
Content-Type=text/plain;
--bbb
Content-Type=application/exe; name="eicar.com"
EICAR SIGNATURE
--bbb--
name="eicar.com"
EICAR SIGNATURE
--aaa
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.
ADDITIONAL INFORMATION
The information has been provided by <mailto:3APA3A@SECURITY.NNOV.RU>
3APA3A.
========================================
This bulletin is sent to members of the SecuriTeam mailing list.
To unsubscribe from the list, send mail with an empty subject line and body to: list-unsubscribe@securiteam.com
In order to subscribe to the mailing list, simply forward this email to: list-subscribe@securiteam.com
====================
====================
DISCLAIMER:
The information in this bulletin is provided "AS IS" without warranty of any kind.
In no event shall we be liable for any damages whatsoever including direct, indirect, incidental, consequential, loss of business profits or special damages.
- Previous message: support@securiteam.com: "[TOOL] Pluto, a Security Auditing Tool"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Relevant Pages
|
|
