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

[ reply ]