Re: [NTSEC] By-passing MS Proxy 2.0 and others packet filtering

On Tue, Oct 13, 1998 at 11:08:44PM +0200, Peter van Dijk wrote:
> On Fri, Oct 09, 1998 at 07:46:38AM +0200, Jean-Christophe Touvet wrote:
> > > Date: Thu, 08 Oct 1998 08:27:36 +0100
> > > From: "Mnemonix" <mnemonix@globalnet.co.uk>
> > >
> > > Firstly it seems that most web-based proxies, not just MS Proxy, are
> > > susceptible to this kind of attack. Thanks to Greg Jones and others for
> > > doing some testing on this.
> >
> > HTTP POST is limited: telnet, NetBios etc. will not work, while CONNECT wi$
> > pass them straightforward.
>
> Very untrue. Look at this:
> [hardbeat@haarlem hardbeat]$ telnet proxy 8080
> Trying 194.178.232.18...
> Connected to rotterdam.vuurwerk.nl.
> Escape character is '^]'.
> POST http://telnet:23/ HTTP/1.0
>
>
> VuurWerk Internet Telnet Server
> (telnet.vuurwerk.nl)
>
> Alle transacties worden gelogged, het gebruik
> van deze server is alleen voor klanten van

[CC'ed to Squid mailing list too]

Peter demonstrates using Squid to tunnel non-wanted connections.

In Squid's defence I'd just like to point out that sneaking connections
through in this fashion has been well known for some time and the Squid
example config files mentions explicitly how to fix it using Squid ACLs:

http_access deny CONNECT !SSL_ports
http_access deny Dangerous_ports

(where Dangerous_ports points to the port numbers you explicitly don't want
Squid to talk to)

However I don't think anyone thought about things like POST'ing to telnet
ports!. I think this is a real hum-dinger - you can't possibly
expect everyone to keep an up-to-date "Dangerous_ports" list.

What about changing the problem and getting the Web proxy server looking at
the returned "headers" in POST/GET calls and ensuring it matches the HTTP
spec - if it doesn't drop it and log it?

No downside that I can think of..?

-- 
Cheers
Jason Haar
Unix/Network Specialist, Trimble NZ
Phone: +64 3 3391 377 Fax: +64 3 3391 417