|
Vulnerability SurfControl Affected SurfControl Description 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.