[FW-1] Checkpoint FW1 SecuRemote/SecureClient "re-authentication" (client side hacks of users.C)

[Cedric Amand <mailing-lists@FW1-NOSPAMCEDRIC.NET>]

______________________________________________________________________________

Affected products :
        All versions of Checkpoint FW1 when used with SecuRemote/SecureClient
        (Namely 4.0, 4.1 at any SP level, and NG FP1)
        http://www.checkpoint.com/products/security/vpn-1_clients.html

Description :
        Checkpoint Firewall-1 SecuRemote/SecureClient "authentication
        timeout" defined in FW1's security policy can be trivially
        bypassed at the client side. Probably more "tweaks" can be done.

Vendor Status :
        Contacted & acknowledged. Explains some ways to mitigate.
        Vendor answer attached to this advisory.
______________________________________________________________________________

Description :
   When using Checkpoint FW1 together with Remote Users connected thru
   SecuRemote and SecureClient
   ( http://www.checkpoint.com/techsupport/downloads_sr.html ),
   firewall administrators have the possibility to make these remote
   users re-authenticate after X minutes.

   This can be found in FW1's GUI inside :
           Global Properties -> Desktop Security -> Validation timeout

   This feature is described in the help file as :
           Validation timeout every...minutes
           If checked, users must re-authenticate after the specified time.

   However, this setting can be trivially bypassed by modifiyng
   the *client side*, inside Securemote's "users.C" configuration file.
   (Your receive this file when first authenticating. It doesn't change
    until you "update" the site. Users.C also contains the encryption
    domain, and a lot of other stuff to play with, see references.)

   Values to modify are "to_expire (true)" and/or "expire (60)"

   Replacing "true" by "false" will make your connection permanent,
   (no need to re-authentify whatever your Firewall admin wants)
           Changing the expire timeout (in minutes) to your
           liking can be used as well.

   Nothing in the docs warns about this behaviour.

   I believe this behaviour exists since years, as we discovered
   this "feature" under FW1 4.0, it was still working with 4.1 (any
   service pack) and is still working with FW1-NG FP1.

   I believe there are plenty of others settings that can be played
   with inside users.C, modifying DNS, encryption domains & networks
   is know to work, tough it leads to nothing useful if your security
   policy is solid. I mostly consider my advisory as a "proof of
   concept" on client-side users.C hacks.
______________________________________________________________________________

Severity :
        Low. But if you actually use this feature inside
        your company and think it's doing anything useful
        about your security : you're wrong.

References & acknowledgements :
        . Discovered by Amaury de Ville & Cédric Amand.
        . A previous analysis of "users.C" inside "pen-test"
        http://lists.jammed.com/pen-test/2001/05/0040.html
        (according to google, the web page speaking about this)

Author :
        Cedric Amand - cedric@cedric.net
        http://techos.org/
______________________________________________________________________________

Vendor Answer :

This email is in response to the issue you have raised with the
re-authentication handling in VPN-1 SecuRemote and SecureClient.

First off, thank you for sending this email to Check Point, we appreciate
the ability to respond to possible security concerns in a low key,
deliberative manner.

WRT the issue at hand: generally speaking, yes, the re-authentication
mechanism can be manipulated on the client side to reduce the need for
re-entering credentials, overriding the management station settings.  To
accomplish this several things must be in place:
1 - the user must be an authorized user (i.e., has a SR
username/authentication credentials)
2 - the user must be using "cacheable" credentials, such as: pre-shared
secret, OS password or FW-1 internal passwords
3 - the user must be able to edit the userc.C file
4 - the user must have some hostile intent or is very uneducated in security
practices (like posting their credentials on their keyboard) or their
machine has been compromised.

Several mechanisms exist to mitigate the above:
- As of NG, the userc.C file does not need to be writeable by
non-adminstrator privileged users.  For bounded OSes like NT, 2000, and XP
this solves the issue, unless the user has administrative privileges.
- Using a one time (S/Key) or periodic-based authentication credential
(SecurID)
- The encrypt_db (available in 4.0, 4.1 and NG) feature allows FW-1
administrators to, in effect, hide the topology data within userc.C where
these settings are located.  The encrypt_db property is NOT overridable by
the client (i.e., even if they change the setting of obscure_db in userc.C
they must delete/re-create the site to get in clear).  Clearly, this is a
security-through-obscurity mechanism and is not perfect.
- As of 4.1, one can force topology data to be updated automatically and
frequently, forcing the user to modify these re-authentication settings in
the userc.C after each update (these are override-able, but can be obscured
as well).

In summary, although yes, in theory you can override the re-authentiction
timer, it does require someone with authorized credentials (or a compromised
machine with those credentials available).  And, there are ways to
manage/mitigate this.

We will also look at steps to add some mechanisms to enforce this, but
again, for platforms like WinCE, and 9X this is problematic due to the lack
of a privileged (super)user mechanism inherent in these OSes.

Thank you again for your communication on this matter.

______________________________________________________________________________

=================================================
To set vacation, Out Of Office, or away messages,
send an email to LISTSERV@lists.us.checkpoint.com
in the BODY of the email add:
set fw-1-mailinglist nomail
=================================================
To unsubscribe from this mailing list,
please see the instructions at
http://www.checkpoint.com/services/mailing.html
=================================================
If you have any questions on how to change your
subscription options, email
fw-1-owner@ts.checkpoint.com
=================================================