RE: Check Point response to RDP Bypass
Jochen,
I think this depends on which version of FW-1 you are running.
V4.1 behaves as you've described below, but for V4.0, no matter what implied
rules you have switched on in your policy, you have:
grep ^#include wo_control.pf
#include fwui_head.def
#include user.def
#include init.def
#include code.def
#include fwui_trail.def
Then in the code.def, you have
/*
*Intercept decryption requests. This rule intercept the first packet in
* the session. The first packet needs special treatment by the
encrypt_intrcpt
* trap because this GW is not the IP-destination of the packet.
*
* For SecuRemote, we check whether srrdpcon is in the rdp table.
*
* The packet is held. If the daemon decides to take care of the request,
the
* packet is dropped. Otherwise, it releases the packet.
*/
#ifndef NO_ENCRYPTION_FEATURES
/* Non-encryption versions of these follow... */
inbound all@all {
accept
RDPCRYPTF,
((rdpconn in rdp_table)
or
(srrdpconn in rdp_table)
or
(log packet-1 new_encrypt_intrcpt, hold));
}
/*
* All other RDP packets of the decryption session will be targeted to a
* specifice host which could be this GW (on which the inspection is done)
* or other GWs along the way.
*/
eitherbound all@all {
accept
RDPCRYPT;
}
So it would appear that this is included no matter what your implied policy
rules are.
Laters,
Paul
-Original Message-
From: Jochen Bauer [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, July 11, 2001 7:45 PM
To: [EMAIL PROTECTED]
Subject: Re: Check Point response to RDP Bypass
On Wed, Jul 11, 2001 at 11:41:23AM +0200, Johan Lindqvist wrote:
The original advisory
(http://www.inside-security.de/advisories/fw1_rdp.html) says that a
workaround is to Deactivate implied rules in the Check Point policy
editor
(and build your own rules for management connections).. I've not been
able
to find any changes in the INSPECT code generated to confirm that not
using
the implied rules from Policy/properties/Security policy/Implied
rules/Accept VPN-1 FireWall-1 Control Connection
Hmm.. strange. I cannot reproduce this. Here's the test i carried out:
I set up a policy with all implied rules, the policy file w_control.W
is attached to this mail. From this policy the INSPECT file w_control.pf
was generated (also attached). The relevant part of this file is:
[...]
#define REVERSE_UDP 1
#include code.def
accept_fw1_connections; -
accept_proxied_conns;
enable_radius_queries;
enable_tacacs_queries;
[...]
accept_fw1_connections is defined in $FWDIR/lib/base.def:
#define accept_fw1_connections accept_fw1_connections1
accept_fw1_connections2
accept_fw1_connections3
and the macro accept_fw1_connections3 includes accept_fw1_rdp which is
the flawed macro.
#define accept_fw1_connections3
[...]
accept_fw1_rdp;
So, the RDP vulnerability finally comes into the INSPECT
file w_control.pf with the macro accept_fw1_connections.
However, if i go to the policy editor and uncheck policy-properties-
Security Policy-Implied Rules-VPN-1 FireWall-1 Control Connections and
re-compile the policy (wo_control.W, see attachment), i get an INSPECT file
(wo_control.pf, see attachment) that does not make use of
accept_fw1_connections and does therefore not lead to this vulnerability.
I've also tested this with our proof of concept code. (BTW: I'm going to
post this code tomorrow on BUGRAQ)
Can you post the policy and INSPECT files you generated?
Jochen
--
Jochen Bauer|Tel: +49711 6868 7030
Inside Security IT Consulting GmbH |Fax: +49711 6868 7031
Nobelstr. 15|email: [EMAIL PROTECTED]
70569 Stuttgart, Germany|http://www.inside-security.de
Re: Check Point response to RDP Bypass
On Wed, 11 Jul 2001, Johan Lindqvist wrote: The original advisory (http://www.inside-security.de/advisories/fw1_rdp.html) says that a workaround is to Deactivate implied rules in the Check Point policy editor (and build your own rules for management connections).. I've not been able to find any changes in the INSPECT code generated to confirm that not using the implied rules from Policy/properties/Security policy/Implied rules/Accept VPN-1 FireWall-1 Control Connection If you run nmap against FW-1 you will notice different behaviour. Hugo. -- All email send to me is bound to the rules described on my homepage. [EMAIL PROTECTED]http://hvdkooij.xs4all.nl/ Don't meddle in the affairs of sysadmins, for they are subtle and quick to anger.
Re: Check Point response to RDP Bypass
The original advisory (http://www.inside-security.de/advisories/fw1_rdp.html) says that a workaround is to Deactivate implied rules in the Check Point policy editor (and build your own rules for management connections).. I've not been able to find any changes in the INSPECT code generated to confirm that not using the implied rules from Policy/properties/Security policy/Implied rules/Accept VPN-1 FireWall-1 Control Connection Does deactiviating the implied rule stop the vulnerability? /Johan Lindqvist -- -BEGIN GEEK CODE BLOCK- Version: 3.12 GCS/E d+ s: a- C++(+++)$ ULOSI*++()$ P+++$$ L++ E++$ W+(+++) N++ o? K-? w---(++)$ O? M-(+) V? PS++ PE-(--) Y++(+) PGP++ t++@ !5- !X- R tv b++ DI D+ G++ e+++ h r+++ y --END GEEK CODE BLOCK-- _ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com.
Re: Check Point response to RDP Bypass
On Wed, Jul 11, 2001 at 11:41:23AM +0200, Johan Lindqvist wrote: The original advisory (http://www.inside-security.de/advisories/fw1_rdp.html) says that a workaround is to Deactivate implied rules in the Check Point policy editor (and build your own rules for management connections).. I've not been able to find any changes in the INSPECT code generated to confirm that not using the implied rules from Policy/properties/Security policy/Implied rules/Accept VPN-1 FireWall-1 Control Connection Hmm.. strange. I cannot reproduce this. Here's the test i carried out: I set up a policy with all implied rules, the policy file w_control.W is attached to this mail. From this policy the INSPECT file w_control.pf was generated (also attached). The relevant part of this file is: [...] #define REVERSE_UDP 1 #include code.def accept_fw1_connections; - accept_proxied_conns; enable_radius_queries; enable_tacacs_queries; [...] accept_fw1_connections is defined in $FWDIR/lib/base.def: #define accept_fw1_connections accept_fw1_connections1 accept_fw1_connections2 accept_fw1_connections3 and the macro accept_fw1_connections3 includes accept_fw1_rdp which is the flawed macro. #define accept_fw1_connections3 [...] accept_fw1_rdp; So, the RDP vulnerability finally comes into the INSPECT file w_control.pf with the macro accept_fw1_connections. However, if i go to the policy editor and uncheck policy-properties- Security Policy-Implied Rules-VPN-1 FireWall-1 Control Connections and re-compile the policy (wo_control.W, see attachment), i get an INSPECT file (wo_control.pf, see attachment) that does not make use of accept_fw1_connections and does therefore not lead to this vulnerability. I've also tested this with our proof of concept code. (BTW: I'm going to post this code tomorrow on BUGRAQ) Can you post the policy and INSPECT files you generated? Jochen -- Jochen Bauer|Tel: +49711 6868 7030 Inside Security IT Consulting GmbH |Fax: +49711 6868 7031 Nobelstr. 15|email: [EMAIL PROTECTED] 70569 Stuttgart, Germany|http://www.inside-security.de (##w_control :rule ( :src ( : Any ) :dst ( : Any ) :services ( : echo-reply : echo-request ) :action ( : (accept :type (accept) :color (Dark green) :macro (RECORD_CONN) :icon-name (icon-accept) :text-rid (61463) :windows-color (green) ) ) :track () :install ( : testfw ) :time ( : Any ) ) :rule ( :src ( : Any ) :dst ( : Any ) :services ( : SSH ) :action ( : (accept :type (accept) :color (Dark green) :macro (RECORD_CONN) :icon-name (icon-accept) :text-rid (61463) :windows-color (green) ) ) :track () :install ( : testfw ) :time ( : Any ) ) :rule ( :src ( : Any ) :dst ( : Any ) :services ( : Any ) :action ( : (drop :type (drop) :color (Firebrick) :icon-name (icon-drop) :text-rid (61465) :windows-color (green) ) ) :track ( : Long ) :install ( : testfw ) :time ( : Any ) ) :filename (w_control.W) ) // INSPECT Security Policy Script Generated by admin@blackmore at 20Jun2001 20:00:22 // from Rulebase w_control.W by FireWall-1 Version 4.1 Code Generation //
