COMMAND

    MS Proxy

SYSTEMS AFFECTED

    Some machine with MS-Proxy Server 2.0

PROBLEM

    Mnemonix found  following.   This advisory  is for  those using MS
    Proxy  2.0  with  packet  filtering  and  use  the same machine to
    Publish Web pages,  or those that  don't enable packet  filtering.
    You network  is at  risk of  attack unless  you also  employ other
    security measures.  In certain and quite common configurations  of
    MS Proxy Server 2.0  it is possible to  attack the machines it  is
    there to protect.  This can be acheived in a number of ways,  more
    easily  if  access  can  be  gained  to  the same IP subnet as the
    "Dirty" Internet Interface. But first some key facts on Proxy.

    When MS Proxy is installed  on a machine with two  interface cards
    the Admin specifies the IP addresses of the machines on the  local
    / corporate network. This information  is stored in a file  called
    the LAT or Local Address Table.  Doing this lets Proxy know  which
    interface is the clean client side and which is the dirty Internet
    side.  The IP address of the dirty interface should not be  listed
    in the LAT.  IP forwarding should be disabled.

    Once installed  MS -  Proxy disables  connections to  TCP port  80
    (assuming this  is the  port Proxy  is listening  on) on the dirty
    interface (Proxy does not 100%  disable connections to port 80  on
    the dirty interface. It is still possible to create a TCP  virtual
    connection but nothing useful can be done with it - no information
    is returned)..  Only  the clean interface will  accept connections
    and service  requests on  port 80  - meaning  that only clients on
    clean  side  should  be  able  to  use  the Proxy services.  It is
    possible, however, to  make a connection  to port 80  on the clean
    interface from the  dirty side.   To see this  happening set up  a
    host on the  same IP subnet  as the dirty  interface and then  set
    your default gateway to the  IP address of the dirty  interface on
    the Proxy - then telnet to port 80 on the IP address of the  clean
    interface.  You should be connected. Then issue the request:

        "GET http://some.protected.machine.on.the.clean.side:port/HTTP/1.0<enter><enter>"

    Proxy  will  then  establish  a  TCP  connection  to the protected
    machine on the port you have  specified. It is easier to see  this
    if the machine is an Internal Web Server. One would expect with IP
    forwarding disabled that this should not happen - ie the  passsing
    of IP information from the dirty interface to the clean interface.
    This is the  "hole" but this  is not a  bug but rather  a feature.
    This happens  due to  the IP  routing algorithm:  If a multi-homed
    computer, not  configured as  a router,  receives a  packet on  an
    interface it will  check all of  its local IP  addresses and if  a
    match  is  found  -  whether  the  IP  address is bound to another
    interface card or  not - the  information is passed  across.  This
    should be acheivable also  in an attack involving  source routing,
    specifying  the  IP  address  of  the  dirty interface as the last
    "hop" to the target.  Once  on the clean side of the  Proxy server
    it is then possible using  the Proxy to redirect attacks  into the
    "protected" LAN.

SOLUTION

    First an foremost enabling packet filtering on the dirty interface
    card can prevent this. Don't allow inbound traffic on port 80. If,
    however, you also use the  underlying IIS to publish Web  pages to
    the Internet ( that is from the Web Proxy Properties -> Publishing
    -> Enable Publishing -> Send to local Server) then this is not  an
    option and you are at risk.

    Secondly,  enable  access  control  -  this  won't  stop this from
    happening but unless the attacker has a USER ID and password there
    is not much they can do.

    Thirdly, it seems  that flushing the  static routing table  on the
    machine (c:\>route -f) also resolves the problem.