3Com SuperStack 3 Firewall Content Filter Exploitable Via Telnet

[<bit_logic () s-mail com>]

The following exploit presumably applies to all versions of the 3COM web 
content filtering software, and possibly web filtering devices of other 
makers.

Many businesses, schools, libraries, and other public places providing 
Internet access to customers implement web content filters to minimalize 
access to pornography, illegal software, racist literature, and so forth.  
A local school district, for example, uses the 3COM SuperStack 3 
firewall's filtering ability to weed out access to restricted websites.  
When a user attempts to access a banned website, the filter appears to 
check the HTTP request against a list of restricted sites and phrases.  If 
a match is found, the user is returned a notification that the requested 
site has been blocked.

The weakness exploited by this vulnerability is that the 3COM filter 
apparently does not reassemble fragmented packets before checking a 
request against its filter list.  This can be demonstrated in the 
following example:

A user on the LAN being filtered wishes to view a blocked website.  We'll 
call it www.blockedsite.com (original, eh?).  He opens his browser and 
enters the address.  Obviously, he is greeted with the 3COM "blocked site" 
page.

Possessing excessive ambition today, our user decides to find a way around 
the filter.  After a short series of tests, he finds that he can connect 
to the blocked site by telneting to port 80 of its domain or IP, and 
manually craft his own HTTP request header:

C:\>telnet www.blockedsite.com 80

GET / HTTP/1.1
Host: www.blockedsite.com

Given the nature of Telnet, the request is sent to the server one 
character at a time; obviously, the filter cannot examine packets with a 
single character of valid data, so each packet makes it through with no 
problem.  The blocked server waits until it receives all packets, then 
pieces them together and responds to the request.  Incoming traffic isn't 
monitored, so the user is easily able to receive the source code of the 
page he requested via telnet.

Taking this trivial exploit a step further, an experienced hacker could 
easily write a script or application to automate this entire process, 
parsing the source for images and other embedded content where necessary.  
This would result in a local copy of the requested site right on the 
user's hard disk.  In theory, one would only need to break apart key areas 
of the HTTP request packet in order to fool the filter, rather than 
sending every character individually.

Unfortunately, I do not have the necessary equipment at my disposal to 
further test the exploit, although I know for a fact that it works, at 
least on firewalls with basic filter configurations.  I also have yet to 
come up with a successful work-around for this bypass, as it occurs at a 
very low level.  If anyone has any ideas, I'm all ears.  Thanks.

- Bit_Logic