RE: Check Point response to RDP Bypass

["Clarke, Paul [IT]" <paul.clarke () ssmb com>]

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:jtb () inside-security de]
Sent: Wednesday, July 11, 2001 7:45 PM
To: bugtraq () securityfocus com
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: jtb () inside-security de
70569 Stuttgart, Germany            |    http://www.inside-security.de