Computer Security
[EN] securityvulns.ru no-pyccku


Related information

  Content filtering bypass for SMTP/HTTP in multiple products

  [SA13869] SafeHTML Hexadecimal HTML Entities Security Bypass

  [Full-Disclosure] Corsaire Security Advisory - Multiple vendor MIME Content-Transfer-
Encoding mechanism issue

  [Full-Disclosure] Corsaire Security Advisory - Multiple vendor MIME field whitespace issue

  [Full-Disclosure] Corsaire Security Advisory - Multiple vendor MIME separator issue

From:3APA3A <3APA3A_(at)_security.nnov.ru>
Date:09.03.2002
Subject:SECURITY.NNOV: Bypassing content filtering software

There are common methods allowing to bypass almost any content filtering
software  (antiviral products, CVP firewalls, mail attachment filtering,
etc). I believe multiple products are vulnerable.

Contents:

I.  Bypassing  attachment  detection  or invalid detection of attachment
type.

 1. Encoded filename or boundary  in Content-Type/Content-Disposition
 2. Multiple  filename  or  boundary  fields  in  Content-Type       /
    Content-Disposition
 3. Exploitation of poisoned NULL byte
 4. Exploitation of unsafe fgets() problem
 5. MIME part inside MIME part
 6. UUENCODE problems
 7. Additional space symbol
 8. CR without LF

II. Bypassing detection of potentially dangerous content

 1. Inability to check Unicode (UCT-2) content
 2. Inability to check UTF-7 content
 3. Inability to check file marked as UTF-7 Content

III. What should be done?

 1. What client software vendor should do.
 2. What server software vendors should do.
 3. What system administrators should do.

 
I.  Bypassing  attachment  detection  or invalid detection of attachment
type.

Imagine  administrator who set his server to strip mail attachments with
dangerous  extensions:  .exe,  .com,  .bat,  .cmd, .pif, .scr etc. No he
sure,  that  his  user can't get executable file via e-mail. He's wrong.
Because  server  and  client  software  may  use  different ways to find
attachments  and to discover the type of attachments. Also, some servers
have vulnerabilities preventing them from discovering attachments. There
are few exploitation scenarios:

1. Encoded filename in Content-Type/Content-Disposition

Mail software finds that MIME part is actually attachment by the 'name'
attribute  in  Content-Type  of  'filename'  in Content-Disposition. If
neither name nor filename attribute present most software will faild to
find attachment.

name and filename may contain encoded-words. Usually Content-Type looks
like

 Content-Type: application/binary; name="eicar.com"

or

Content-Type: application/binary; name="=?us-ascii?Q?eicar=2Ecom?="

But there are different sub-variants server software may fail to check:

Content-Type: text/plain; name==?us-ascii?Q?eicar.com?=

or
              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 this many programs fail to detect .com extension
or  to  find attachment at all (please note: base64 may be used instead
of quoted-printable).

Another example is

            name="=?us-ascii?B?eica.com

in this case encoded word is incomplete and it's not clear if it should
or  shouldn't  be decoded from base64. It will depend on client program
realization. Good content filtering software should try both cases.

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  exactly
"=?koi8-r?Q?aaa?=".

Another  case  is  then  software  tries  to  decode  enocded word, for
example multiple programs miss attachment if it's marked as

Content-Type: text/plain;=?koi8-r?B?;name="eicar.exe";?=


2. Multiple filenames/boundaries.

Another  one  point  is  how software behaves if there multiple name or
boundary attributes. Example:

 Content-Type: text/plain;
   name="safe.txt";
   name="eicar.com"

Most  client  programs will use last name or boundary, but good content
filtering  software  should  block  that  kind of messages or check all
possible situations.

3. Exploitation of "poisoned null byte".

I   belive   there   is   not  need to explain that ASCII 0 byte may be
string  terminator.  NULL  byte  may be present in data as is or may be
encoded  using base 64 or quoted printable. There is a lot of situation
where  server  and  client software may react to null byte in different
way. At least Outlook Express treats NULL as CRLF.

 3.1 Filename and boundary.

 There  is  no  need  to  explain  that  both name="file.txt\0.exe" and
 name="file.exe\0.txt"  may be dangerous and boundary="aaa\0bbb" may be
 treated as is or as "aaa".

 3.2 MIME header and MIME body

 Imagine there is a MIME part with

 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  will  think it's a part of
 header.  Or  vice  versa.  The only good solution is do not allow NULL
 byte in headers.


4. Exploitation of unsafe fgets() problem

I've  used  "unsafe  fgets()"  term  some time ago regarding to mailbox
parsing  problem  in  few  application. This is input validation bug in
programs  processing  string  input  then  long  string  are  processed
incorrectly   in   specific  situation.  It  has  nothing  common  with
overflowing  some buffer. Let's review small example. Imagine next code
looks for empty string of only '\n' to find the end of MIME headers:

 while ( fgets(buffer, BUFFERSIZE, input) ) {
  ...
  if (*buffer == '\n') header = 0;
  ...
 }

 There  is a bug in this code. Imagine the string of BUFFERSIZE+1 bytes
 long (last byte is '\n').

 First fgets() call will return BUFFERSIZE characters. Second call will
 return  the  strin  of  only  '\n'  character.  It will be incorrectly
 believed to be empty string.

 A lot of client and server software has this kind of bugs. It makes it
 possible  to fool this software to detect headers there they shouldn't
 for exampe:

  Header:(number of spaces)Content-Type: text/plain; name="eicar.exe"

 or  like  in  case of 3.2 to treat some header fields as a part of the
 body.

 5. MIME part inside MIME part

 This  bug  is  very  common  for software which strips 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

 then  bbb part will be removed  aaa part will contain eicar.com

 6. UUENCODE problems

 UUENCODE  is  older  format  for file attachments that doesn't require
 MIME part. In classic case uuencoded file begins with

 begin XXX filename.ext

 (XXX - file permissions in octal encoding).

 The problem is if filename contains spaces, for example

 begin 666 eicar .com

 is  valid  filename  but  multiple  attachment  filter  fail  to check
 everything  after space.

 7. Additional space symbol

 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 both
 cases should be checked.

 same thing is with filename in MIME or UUENCODE.

 8. CR without LF

 At  least  Outlook Express treats <CR> without <LF> as end of line. It
 makes  it  possible  to create Content-Type headers and body invisible
 for content filtering software (was reported by Valentijn Sessink)
 

II. Bypassing detection of potentially dangerous content

There  is  a  lost of software that tries to detect and block or remove
dangerous  file  content  (HTML  strippers,  antiviral  products, etc).
Inability of this software to handle specific data makes it useless.

1. Inability to check Unicode content

Multiple products (including Internet Explorer/Outlook Express) support
Unicode  encoding for text formats including text/html. Unicode (UCT-2)
text  begins  with 0xFF 0xFE bytes with wide (WORD) characters in Intel
host byteorder (less significant first). Content filtering software may
fail to strip potentially dangerous information (scripts, ActiveX, etc)
from  Unicode  format text. For example, "<script>" tag in unicode will
be {'<', 0, 's', 0, 'c', 0, 'r', 0, 'i', 0, 'p', 0, 't', 0, '>', 0}

2. Inability to check UTF-7 content

Almost  any  MUA/Web  client  software support 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 <script> tag in UTF-7 may
look like <+AHM-+AGM-+AHI-+AGk-+AHA-+AHQ->.

3. Inability to check content marked as UTF-7/UTF-8

If  MUA  or  Web client retrieves UTF-7/UTF-8 encoded file this file is
decoded  for  internal  processing, but not then saved to disk. That is
text  "<+AHM-+AGM-+AHI-+AGk-+AHA-+AHQ->"  will be used as "<script>" in
Internet  Explorer itself, but if this text is in attached file it will
be saved without changes.

It  may be possible to fool software into thinking attached file should
be decoded, while it shouldn't.

For example,


Content-Type: text/html;
              charset=utf-7;
              name="trojan.exe"

shouldn't  be  decoded from utf-7 before checking it's content, because
it will be saved by Internet Explorer (or MUA) as is.

I  believe  for  content  marked  as  utf-7/utf-8  both decoded and not
decoded content should be checked.

III. What should be done?

1. What client software vendor should do.

 Client  software behavior should be as predictive as it possible. Even
 small  problems  (like  null  bytes  and  unsafe  fgets())  should  be
 corrected.  Configuration  options  to  block  dangerous  content (for
 example   files   with   specified  extensions).  If  content  doesn't
 correspond to standards it's better ignore content rather then to make
 some  intuitive  decision about it. Behavior should as close to RFC as
 it  possible. Message with RFC violation shouldn't be processed (or at
 least user should be warned).

2. What server software vendors should do.

 Check  all  possible situations with all known client software. Report
 all  bugs  found  (even  if it doesn't seem to be security related but
 looks  like  RFC  violation)  to  vendors.  Block content that doesn't
 conform  to  RFCs. Implement all possible encodings, but do not expect
 client software to support them always.

3. What system administrators should do.

 Never  believe  you  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 it's behavior rather
   then signature. It allows to catch almost any malware.
  Your workstations:
   It's  not  enough  to  protect  servers. It's 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.


 
--
http://www.security.nnov.ru
        /\_/\
       { , . }     |\
+--oQQo->{ ^ }<-----+ \
|  ZARAZA  U  3APA3A   }
+-------------o66o--+ /
                   |/
You know my name - look up my number (The Beatles)

About | Terms of use | Privacy Policy
© SecurityVulns, 3APA3A, Vladimir Dubrovin
Nizhny Novgorod