05/03/03, 22:37
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
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