COMMAND

    FIrewall-1

SYSTEMS AFFECTED

    Systems using Firewall-1

PROBLEM

    Following  is  based  partly   on  Diligence  Security   Advisory.
    Checkpoint's Firewall-1 has a "feature" that can allow an external
    intruder  to  pass  through  the  firewall  and  attack  machines,
    unihibited, on the protected side.

    When  Firewall-1  is  installed  there  is  an  implicit rule: ANY
    (Source), ANY (Destination), ANY (Service) and ACTION (drop). This
    means, in theory, that all  IP based packets, whether incoming  or
    outgoing should be dropped.  However, Firewall-1, out of  the box,
    allows certain "core" network protocols through - these being  RIP
    (UDP port  520), DNS  (UDP and  TCP port  53) and  all ICMP except
    Redirects.  These  are allowed through,  from ANY (source)  to ANY
    (Destination),  without  being  logged,  before  the  rule base is
    referenced.

    These are because  the Firewall Properties  are set to  allow this
    protocols  through.   These  settings  are  what  as  known as the
    Firewall-1 "Implicit Rules".  These properties have four settings,
    unchecked, which means disabled; checked, and "First" which  means
    the  this  is  handled  before  it  hits  the ruleset; checked and
    "Before Last" which means that this property is passed through the
    ruleset but accepted just before  the last rule, which is  usually
    any-any-any-drop; and  checked and  "Last" which  means that  this
    rule is  automatically the  last rule  in your  ruleset.   This is
    documented in the administration  guide and CCSE training  classes
    also cover these.  In FW-1 version 4.0 you can toggle the  display
    of these implicit rules, which makes them much easier to  identify
    and  understand  how  they  affect  your  ruleset..   In  previous
    versions, you had  to keep track  of them manually,  and they were
    much easier to forget about.

    Consequently,  DNS  cache  poisoning  aside,  if  an  attacker has
    managed to place a trojan or  another "backdoor" on a host on  the
    protected side, through whatever  method, and set it  listening on
    TCP  or  UDP  port  53,  they  will  be  able  to access this host
    transparently, through the firewall.  No logging will take  place.
    The firewall host  itself is reachable  by this method,  even if a
    'stealth' rule has been placed in the rule-base to protect it.

    During lab  tests we  set an  NT Server  listening on  TCP port 53
    using netcat and on connection spawned a command prompt (cmd.exe).
    On telnetting to this server, through the firewall, test team  was
    able to attack all other  machines on the "protected" side.   They
    also  installed  the  cDc's  Back  Orifice  on a Windows 95 client
    listening on UDP port 53 and could access this machine through the
    firewall.  When listening on UDP 520 (RIP) the we could not access
    the 95 client, indicating  that firewall-1 checks the  validity of
    traffic sent over  the RIP port.   Versions tested was  Firewall-1
    v3.0b on NT server 4.0 with Service Pack 3.

    Here's more info on exploit method.  Rule base:

        1. ANY Source, WebServer (dest), HTTP, SMTP (service),  Accept
           (action), Short (track)
        2. Internal (Source), Any (Destination), Any (Service), Accept
           (Action), Short (track) (This was to give interanl  trusted
           users full access to the 'Net)
        3. Any  (Source),  Any  (Destination),  Any  (Service),   Drop
           (Action), Long (Track))

    The Web Server (IIS) was compromised by exploiting:

        /scripts/passwd.txt%20.pl

    to get a perl error to give a password (webboard.pl). The whole of
    the  C:  drive  was  made  a  virtual directory and given read and
    execute permissions.  Using <path>/cmd.exe?/c%20net%20use....  etc
    etc the  web server's  v: drive  was mapped  to the  attacker's c:
    drive then Netcat  was copied to  the webserver.   Netcat was then
    run  (/nc.exe?-l%20-p%2053%2-e%20cmd.exe)  and  set  to listen for
    connection on TCP port 53.   Because of the default settings  FW-1
    allows DNS  TCP through  before the  rule base  is checked with no
    logging. On telnetting to the  compromised web server it was  then
    used a a platform to attack other machines (an NT file server  was
    compromised as well as a SUN Solaris machine.)

SOLUTION

    From the Firewall-1 Security Policy Window choose Properties  from
    the Policy Menu.  Uncheck the "Accept  Domain Name Queries  (UDP)"
    and "Accept Domain  Name Download (TCP)".   This will disable  DNS
    which, of course, will cause problems.  In order to avoid this you
    will need  to create  a specific  rule in  the rule  base to allow
    these core protocols to function.   The exact nature of this  rule
    will vary depending  on the configuration  of DNS within  your own
    network and the above steps should only be taken after  consulting
    with in-house DNS administrators.

    Instead of completely disabling  these rules, you could  make them
    "enabled"  but  process  it  "Last"  and have appropriate rules to
    authorize  and  log  these  services...   The "Managing Firewall-1
    Using the Windows GUI" book that comes with the firewall (both  in
    hardcopy and pdf on the CD) covers this in Chapter 8.  In  Chapter
    9  they  list  in  order  the  bits  a  packet is matched against.
    Unfortunately,  this  documentation  is  insufficient.  They don't
    give  any  advice  as  to  the  implications of doing DNS and ICMP
    before the  rule base.   In spite  of what  they might  consider a
    complete  description  of  how  it  work,  it's  easy  to miss the
    security implication  of their  default settings,  especially when
    they  declare  some  things  essential,  making  it  seem  to  the
    administrator  that  she'd  better  leave  the  services wide open
    rather than handle them explicitly in the rules.