COMMAND
SurfControl
SYSTEMS AFFECTED
SurfControl
PROBLEM
Franklin Witter found following. It appears that there is yet
another way to bypass the site blocking feature of SurfControl for
MS Proxy.
He has set up our rules to deny access to anyone attempting to
reach sites classified as Adult/Sexually Explicit, Hacking, etc.
That would mean that anyone trying to reach www.blockedsite.com
would normally be denied access to the site.
The workaround:
1. First, do an nslookup on www.blockedsite.com to get the IP
address of the site -- xxx.xxx.xxx.xxx
2. Next, convert each octet to an octal number using the windows
calculator -- yyy.yyy.yyy.yyy
3. Insert eight (8) leading zeros in the first and third octets
and seven (7) leading zeros in the second and fourth octets --
00000000yyy.0000000yyy.00000000yyy.0000000yyy
4. Type the modified octets into your browser's address bar and,
viola!, your are successfully bypassing the SurfControl filter.
As far as we know, this, or close variations on this (ie,
0yyy.0yyy.0yyy.0yyy, or turning the whole thing into binary,
removing the dots, and reconverting to decimal, hex, etc.) work
on most, if not all web censors/filters.
Not only does it let you hit the first page using the octal
address, but it allows you to surf the entire site. We tested it
on 3 different systems logged in as different users and were able
to make multiple visits to the same site.
Another way to bypass other URL filtering software is to convert
the IP octets into hex using 0xnnn representation. Some will let
you block certain regex's, some won't. If it does support
regex's, the actual regex will depend on the different
combinations you can use to represent the IP octets. For
example, a combination of hex, octal, and regular decimal:
0xc0.168.000000001.1
Running SurfControl Version 3.0.0.1 people were able to get to
the same 'blocked' sites on multiple machine using the octal
format. Not only that, but blank lines gets written to the
real-time monitor window. A blank line for every bypass
connection...
A URL containing an IP address is not canonical for HTTP. HTTP
1.1 does virtual hosting via the "Host:" header, so multiple
distinct servers can be on a single IP. If you restrict based on
IP, you'll block access to both http://www.juicysex.com/ and
http://www.bible-history.org/, should they both be on the same
box. However, one or none of the sites has the be the default for
requests where the site isn't specified. So, if the default is
juicysex, then the IP address can be blocked. If it's bible
history, then you don't. The bypass only "works" if the
restricted site is the default.
SOLUTION
SurfControl has confirmed this to be a vulnerability in 3.0.2
version. No ETA for a patch has been given at this point.