Checkpoint firewall's vulnerabilities revealed

*Telecom and Logistics Associates*	TLAalert *Security Service*
Translate this page from:	publication: Christian ALT

Save Time and Money

TLAnews: Security NEWs Service

31.7.2000 Security: Checkpoint firewall's vulnerabilities revealed
In a precedent publication we informed that a group of German consultants employed by TUV Data Protect announced that they had discovered numerous flaws in Check Point's firewall product. Checkpoint cooperated very closely with this group and should include corrections to those vulnerabilities in its Service Pack SP2.

French Les vulnérabilités du Firewall de Checkpoint révélées
Lors d'une précédente publication nous avons informé qu'un groupe de consultants employés par TUV Data Protect a annoncé la découverte de plusieurs vulnérabilités dans le produit firewall 1 de Checkpoint. En coopérant de manière très étroite avec ce groupe, Checkpoint a apporté des corrections à ces vulnérabilités dans son Service Pack SP2.

Home

TLAnews

TLAnews.com
Information for security concerned people

English version

TUV will be making a public posting to the Internet containing further details very soon. For the moment we publish the information we received about thoses vulnerabilities.

The collaboration seemed very good with Checkpoint, they even went so far as to give TUV a copy of the latest version of their firewall software (4.1 SP1) so that TUV could test their exploits against the newest technologies. TUV also made it very clear that the vulnerabilities they discovered are not necessarily Check Point-specific, but that Check Point was the first that they had thoroughly analyzed.

You should plan to immediately upgrade to 4.1 SP2. Once that is done, due diligence must be maintained when further configuring your firewalls. Never sacrifice security for convenience - this will cause you extreme pain in the long run.

Résumé en français

TUV va poster prochainement sur Internet des descriptifs de ces vulnérabilités. Pourle moment nous avons publiés l'information dont nous disposons.

Il semble que la collaboration avec Checkpoint s'est très bien passée que TUV a pu également tester ses vulnérabilités sur les versions cp2000 ou 4.1 avec SP1.

Les correctifs doivent se trouver dans le Service Pack 2 de Checkpoint qui vient d'être mis à disposition des utilisateurs.

Plusieurs de ces vulnérabilités touchent la communication entre firewalls et plus particulièrement la gestion distante. En exploitant certaines de ces failles il devrait ^'etre possible de recharger une nouvelle "policy" dans le firewall.

La situation semble être moins difficile pour ceux qui disposent de la version 2000 du firewall et qui ont activé "l'anti-spoofing". Un ensemble de recommandations fait suites à ces annonces, dont la mise à niveau rapide en utilisant le SP2.

Without to many details here is what was announced at the conference in Vegas US.

	Vulnerable	Description
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:

Spoof tracking should be configured on all firewall interfaces.
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."
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.
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.).
Outbound Internet access should never be unrestricted - only allow the protocols that your corporate security policy allows for.
The "any" object should never be used as a destination in your outbound Internet access rules. Use a NOT<my-internal-net> instead.
ICMP should be either disabled, or very closely scrutinized.
Broadcast traffic, especially multicast, should be blocked as much as possible.
In general, a "least privileges" model should be followed - no access should be granted which is not explicitly required for business to run.

Related information

more security information with TLAnews ...

All information provided is of a general nature and is not intended to address the circumstances of any particular individual or entity. Although we endeavor to provide accurate and timely information, there can be no guarantee that such information is accurate as of the date it is received or that it will continue to be accurate in the future. No one should act upon such information without appropriate professional advice after a thorough examination of the facts of the particular situation.

Author information. Copyright © [Telecom and Logistics Associates Sàrl]. All rights reserved. Revised: août 01, 2000 .

Author information.
Copyright © [Telecom and Logistics Associates Sàrl]. All rights reserved.
Revised: août 01, 2000 .