Firewall-1 Security Advisory

[risks () diligence co uk (Diligence Risks)]

Diligence Security Advisory

Issue: 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.

Details: 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.

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 our 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, we were able to attack all other
machines on the "protected" side. We 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: Firewall-1 v3.0b on NT server 4.0 with Service Pack 3

Fix: 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. Diligence accepts no responsibility for
any problems caused by the disabling of these default settings.

For further information see: http://www.diligence.co.uk