[VulnDiscuss] RE: Corsaire Security Advisory - Symantec Enterprise Firewall (SEF) HTTP URL pattern evasion issue
"Mike Fratto" <[email protected]>
| Newsgroups | gmane.comp.security.vulnerabilities.watch.general |
|---|---|
| Message-ID | <[email protected]> |
This is a non-issue. The documentation for SEF and the URL pattern file offers suggestions and sample patterns. It should be obvious from the pattern file that SEF does string mathcing and does not norm resolve URI's > -----Original Message----- > From: Martin O'Neal [mailto:[email protected]] > Sent: Wednesday, March 26, 2003 4:10 AM > To: [email protected] > Subject: [VulnWatch] Corsaire Security Advisory - Symantec > Enterprise Firewall (SEF) HTTP URL pattern evasion issue > > > > -- Corsaire Security Advisory -- > > Title: Symantec Enterprise Firewall (SEF) HTTP URL pattern > evasion issue > Date: 24.02.03 > Application: Symantec Enterprise Firewall (SEF) 7.0 > Environment: Windows NT 4.0, Windows 2000, > Author: Martin O'Neal [[email protected]] > Audience: General Distribution > > > -- Scope -- > > The aim of this document 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 Symantec Inc. [1] > > > -- History -- > > Vendor notified: 24.02.03 > Document released: 26.03.03 > > > -- Overview -- > > 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 [2]. > > > -- CVE -- > > The Common Vulnerabilities and Exposures (CVE) project has > assigned the name CAN-2003-0106 to this issue. This is a > candidate for inclusion in the CVE list > (http://cve.mitre.org), which standardizes > names for security > problems. > > > -- References -- > > [1] http://enterprisesecurity.symantec.com/products/products.cfm?Pro > ductID=47&EID=0 > [2] http://service1.symantec.com/SUPPORT/ent-gate.nsf/docid/20030325 > 07434754 > > > -- Revision -- > > a. Initial release. > b. Minor revisions. > c. Minor revisions. > d. Revised to include CVE reference. > e. Revised to include Symantec recommendation. > > > -- Distribution -- > > This security advisory may be freely distributed, provided that it > remains unaltered and in its original form. > > > -- Disclaimer -- > > The information contained within this advisory is supplied > "as-is" with > no warranties or guarantees of fitness of use or otherwise. Corsaire > accepts no responsibility for any damage caused by the use or > misuse of > this information. > > > Copyright 2003 Corsaire Limited. All rights reserved. >