______________________________________________________________________________
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 - cedricat_private
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.
______________________________________________________________________________
This archive was generated by hypermail 2b30 : Fri Mar 08 2002 - 15:51:03 PST