Users login

Create an account »

JOIN XATRIX

Users login

Home » Hacking News » 3Com SuperStack 3 Firewall Content Filter Exploitable Via Telnet

3Com SuperStack 3 Firewall Content Filter Exploitable Via Telnet

by Nikola Strahija on March 5th, 2003 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.


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.

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 (for example). 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.


- Bit_Logic


Newsletter signup

Signup to our monthly newsletter and stay in touch with IT news!

Free E-books

We've got ebooks! But they're not online. :( Please give us a few days to bring downloads back.

Contact

Have something to say or just wanna drop us a line? Please keep this in mind: to spam, we reply with spam.

Contact us »