COMMAND

    WatchGuard Firewall

SYSTEMS AFFECTED

    Those using WatchGuard Firewall

PROBLEM

    Alfonso Lazaro found  following.  He  found a misconfiguration  in
    the default configuration of  Watchguard Firewall.  By  default it
    appends a rule that it accepts pings  from any to any.  So if  our
    firebox is defending our internal network ( 192.168.x.x ... )  and
    our  WG  Firewall  is  a  proxie  with  an external ip in internet
    (100.100.100.100  hipotetic  ip  address)  the  atacker can change
    his/her routes like so:

        # route add -net 192.168.0.0 netmask 255.255.255.0 gw 100.100.100.100

        # ping 192.168.1.1
        PING 192.168.1.1 (192.168.1.1): 56 data bytes
        64 bytes from 192.168.1.1: icmp_seq=0 ttl=251 time=514.0 ms

        ^C

        # ping 192.168.1.2
        PING 192.168.1.2 (192.168.1.2): 56 data bytes
        64 bytes from 192.168.1.2: icmp_seq=0 ttl=251 time=523.0 ms

        ^C

    and so on ...  The  atacker can now discovers internal network  ip
    and atack them

        # ping -f 192.168.1.1

SOLUTION

    Solution is easy ...  do not let pings  to internal network.   Not
    to detract from the security implications of allowing echo-request
    inbound unchecked, but in most cases the above would be of  little
    use.   Every  router  between  the  attacker  and  the  WatchGuard
    firewall would need to be configured to point 192.168.0.0  towards
    the firewall, something that is not going to happen per the  RFC's
    (unless the attacker also compromises each router along the link).
    The above  attack pattern  would only  be useful  in the following
    situation:

        1) The attacker can source route inbound traffic
        2) The  protected network  is actually  legal, routed  address
           space
        3) The attacker gains access to the wire between the  firewall
           & the Internet router

    If #1 works, shame on you.  If #3 works, you have bigger  problems
    than ICMP through the firewall.

    At WatchGuard preliminary analysis  is that the reported  behavior
    is  not  traceable  to  the  default  configuration files.  In the
    absence of any further information from Sr. Lazaro, it is believed
    that  his   report  of   a  vulnerability   in  Firebox    default
    configuration files is in error.