Firewalls Tutorial: Checkpoint firewall's vulnerabilities, security threats

The following are the vulnerabilities found in CheckPoint Firewall. Upgradation to 4.1 SP 2 is necessary.

1. Remote Management
   There is a weakness in the logic used for firewall to firewall   communications - the IP of the supposed real management console is   not checked at layer 3, but instead at layer 7. This means that if   someone can authenticate to a firewall module somehow, they can come   from any arbitrary IP and trick the firewall module into thinking   that the attacker's machine is its management console.

2. S/Key
   The S/Key authentication mechanism used by 4.0 and below (default   for v.3.0, but also used occasionally in 4.0) can be trivially brute- forced. This, combined with the first finding, means that an   attacker could have all they need to remotely control your firewall -   provided you are using S/Key authentication, set by your   $FWDIR/lib/control.map file, and that your policy allows connections   to TCP port 256 (i.e., "Accept Firewall-1 Control Connections" box   is checked in the firewall properties dialog.) In their example,   Thomas Lopatic of TUV Data Protect issued the command to remotely   unload the firewall policy so that he could then circumvent all   security controls.

3. fwn1
   fwn1 authentication was also found to be trivially cracked using   other methods, allowing the same remote policy unloading   capabilities.

4. fwa1 fw-to-fw authentication
   They also broke fwa1 fw-to-fw authentication, but since that authentication also includes some encrypted communications, they were not able to fully authenticate. Thus, 4.1 looks "okay" for now (since some 4.0 and all 4.1 versions use fwa1 by default).

5. FTP PORT and PASV command
   Another variant of both the FTP PORT and PASV command handling vulnerabilities was also found, which allowed vulnerable servers behind the firewall to be compromised under certain conditions.

6. one-way connection
   There is also a problem with one-way connection handling, in which fw-1 really allows two-way traffic if TCP header and TCP payload are split into two separate packets.

7. FWZ
   Found problems with FWZ encapsulation which could allow connection spoofing.

8. RSH Error
   They also figured out that RSH Error connections weren't properly handled, which allowed them to connect to certain protected hosts via any UDP port (assuming spoof tracking was not turned on).

9. Spoof tracking
   Found a problem with fw-1's spoof tracking, in which you could use multicast addressing to connect to protected hosts, under certain circumstances.

10. "fastmode" services
   They also pointed out the security vulnerabilities inherent to the use of "fastmode" services.

   From our information all of these vulnerabilities have been diligently addressed by Check Point, and included in 4.1 SP2. In general, however, the following practices should also be used to prevent most of these types of attacks:

a. Spoof tracking should be configured on all firewall interfaces.

b. All implicit rules, set by the firewall policy properties, should be disabled - especially "Accept Firewall-1 Control Connections," "Accept ICMP," "Accept RSH Error Streams" and "Accept UDP DNS Requests."

c. TCP port 256 should not be open to anyone but the true firewall management console. If there is a burning need to allow access to this port from other sources (say you can't get SecuRemote working or something), ensure that your $FWDIR/lib/control.map file is set to use fwa1 encryption.

d. Outbound Internet access should not be given to machines that don't need it (Web servers, FTP servers, routers, etc. should have no reason to be able to Web browse, etc.).

e. Outbound Internet access should never be unrestricted - only allow the protocols that your corporate security policy allows for.

f. The "any" object should never be used as a destination in your outbound Internet access rules. Use a NOT<my-internal-net> instead.

g. ICMP should be either disabled, or very closely scrutinized.

h. Broadcast traffic, especially multicast, should be blocked as much as possible.

i. In general, a "least privileges" model should be followed - no access should be granted which is not explicitly required for business to run.