COMMAND
FW-1
SYSTEMS AFFECTED
FW-1
PROBLEM
'root of sysconn' found following. There are two vulnerabilities
in FW-1. The first is an authentication issue, the other is a
configuration issue.
#1
The basic authentication used in Checkpoint FW-1 used for
inside/outbound and outside/inbound allows unlimited attempts to
authenticate without a timeout or disconnect between unsuccessful
attempts. To make matters worse, the attempt at authentication
will let you know if you have the wrong username before you are
allowed to enter in the passsword.
The exploit is trivial, grind away at user names until you hit
one that works and then grind away at passwords with the username
you just found until you find one that works. For an example of
this, set authentication on the FW-1 software to authenticate
telnet connections. Telent to a destination past the firewall,
when prompted for a username, pound away. A script could crack
the authentication in a very short time.
#2
The default configuration in FW-1 allows for rlogin management of
the server. The rlogin prompt is avaialable on all NICs. Unless
a rule is placed in your ruleset to drop or reject all connections
to the firewall, the authentication problem above can be used to
remotely administer someone elses firewall without them knowing.
SOLUTION
For fisrst one, the workaround is to use Checkpoint's encrypted
authentication program "SecuRemote" and not allow clear text
authentication (browser based, telnet, etc.) to destinations
beyond the firewall. Another solution is to use one-time-passwords
or generally token based passwords like SecurID (but the session
should additional make use of securemote due to preventing
man-in-the-middle attacks). SecuRemote alone does not prevent from
guessing the username - it only encrypts and authenticate your
session. But you can still authenticate to the firewall, using
SecuRemote - and have unlimited number of tries. FW-1 will let
you know if username exists or not. It was tested with V4.0. As
for second, the workaround is to include the rule.
1) This is standard on almost every OS, if you want to be secure
run against RADIUS and have that reject after x failures, or
even against NT. This is available in checkpoint 3.x and 4.x.
2) This is absolutely poor configuration. You should always set
to deny traffic to your firewall, its in every checkpoint
book, and every piece of literature you read about network
security.