[NT] Symantec Enterprise Firewall (SEF) HTTP URL Pattern Evasion Issue

From: support@securiteam.com
Date: 03/26/03

  • Next message: support@securiteam.com: "[UNIX] PostNuke Sensitive Information Disclosure" 
    From: support@securiteam.com
To: list@securiteam.com
Date: 26 Mar 2003 17:26:16 +0200

    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

    In the US?

    Contact Beyond Security at our new California office
    housewarming rates on automated network vulnerability
    scanning. We also welcome ISPs and other resellers!

    Please contact us at: 323-882-8286 or ussales@beyondsecurity.com
    - - - - - - - - -

      Symantec Enterprise Firewall (SEF) HTTP URL Pattern Evasion Issue
    ------------------------------------------------------------------------

    SUMMARY

    The aim of this advisory is to clearly define some issues related to a URL
    pattern evasion issue in the HTTP proxy of the Symantec Enterprise
    Firewall (SEF) product, as supplied by
    <http://enterprisesecurity.symantec.com/products/products.cfm?ProductID=47&EID=0> Symantec Inc.

    DETAILS

    Vulnerable systems:
     * Symantec Enterprise Firewall (SEF) version 7.0

    The SEF firewall product uses an application proxy strategy to provide
    enhanced security features for a variety of common protocols. For the HTTP
    proxy, part of this additional functionality allows the firewall to block
    URLs based on predefined regular expression patterns.

    However, by using URL encoding techniques this pattern matching
    functionality can be evaded.

    Analysis:
    The HTTP pattern matching functionality works by analysing the HTTP URL
    format and comparing this against a database of predefined signatures.

    When an HTTP connection is processed via a rule that is configured to use
    the pattern matching functionality, it is checked against the signature
    database and if a match is found, the request is blocked with a 403
    Forbidden error.

    However, if one of the standard URL encoding techniques (e.g. escaped
    encoding, Unicode, UTF-8) is used, then the pattern matching will fail to
    trigger and the attack will succeed.

    Proof of concept:
    Step 1: On the firewall host create a rule that allows HTTP traffic and
    under the Advanced Services tab include the http.urlpattern setting.

    Step 2: Using the Editor open the httpurlpattern.cf file and add in a new
    line consisting of only the word "hamster". Save and reconfigure the
    firewall.

    Step 3: To reproduce this issue, open a standard web browser and connect
    to a site that will be included within the scope of the rule created in
    the first step (i.e. http://www.gerbil.com). This should result in a
    successful connection.

    Step 4: If the target pattern created in step 2 is appended to the same
    URL (i.e. http://www.gerbil.com/hamster) then the connection should fail
    with a 403 Forbidden error.

    Step 5: If a form of URL encoding is now used on the URL from step 4,
    (i.e. http://www.gerbil.com/h%69mster) then this will pass through the
    firewall successfully.

    Recommendations:
    As an interim measure, the documentation that is supplied with the
    firewall should be revised to state explicitly that the pattern matching
    functionality does not support any form of underlying HTTP encoding
    schemes.

    Ideally, as a longer-term solution the HTTP proxy should be enhanced so
    that encoding schemes are resolved and applied prior to performing the
    pattern matching function.

    Symantec have provided a knowledge base article for customers who wish to
    restrict all escaped character sequences in protected URLS, using a
    regular expression pattern:
    <http://service1.symantec.com/SUPPORT/ent-gate.nsf/docid/2003032507434754>
    http://service1.symantec.com/SUPPORT/ent-gate.nsf/docid/2003032507434754.

    ADDITIONAL INFORMATION

    The information has been provided by <mailto:VulnWatch@corsaire.com>
    Martin O'Neal.

    ========================================

    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.

  • Next message: support@securiteam.com: "[UNIX] PostNuke Sensitive Information Disclosure"