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
