Checkpoint FW1 SecuRemote/SecureClient "再認証" （users.C のクライアント側の不正使用）

［翻訳：関谷　麻美］
2002年3月13日

概要：
　FW1 のセキュリティ・ポリシーで規定されたCheckpoint FW1 SecuRemote/SecureClient "認証タイムアウト"は、クライアント側でささいなことで迂回される。

詳細：
脆弱なシステム
　SecuRemote/SecureClient と共に使用する場合の Checkpoint FW1 の全バージョン（すなわち、あらゆる SP レベルの 4.0、4.1 と NG FP1）：
http://www.checkpoint.com/products/security/vpn-1_clients.html

SecuRemote と SecureClient
　（ http://www.checkpoint.com/techsupport/downloads_sr.html ) を介して接続された Remote Users が Checkpoint FW1 を使用する場合、ファイアウォール管理者は X 分後にそれらのリモートユーザを再認証するオプションを持つ。

　これは、FW1 のGUI 内部で確認できる：
Global Properties -> Desktop Security -> Validation timeout

　この機能は、ヘルプ・ファイルに下記のように記述されている：
有効のタイムアウトは…分毎
　チェックされる場合、ユーザは指定された時間の後、再認証されなければならない。

　しかしこの設定は、SecuRemote の "users.C" 構成ファイル内部のクライアント側を変更することで小さく迂回することが可能だ。（最初、認証時にあなたはこのファイルを受け取る。あなたがそのサイトを"アップデート"するまで、そのファイルは変更されない。Users.C は暗号ドメインそして他の多くの要素も含む。参考資料を参照のこと。）

　変更する値は、 "to_expire (真)" そして/もしくは "expire (60)" だ。
　"真"を"偽"に置き換えることで、あなたの接続は永久的になるだろう（あなたのファイアーウォール管理者が何を要求しようと、再認証する必要はない）。
有効期限（分単位）タイムアウトをあなたの好みに変更する際も、同じく利用できる。

　本文書では、この動作に関し何も警告も行わない。

　この動作は FW1 4.0 で発見され、（どのサービスパックの）4.1 でも未だ機能している。そして FW1-NG FP1 でも未だ機能している。旧バージョンも同様に影響を受けていると思われる。

　DNS の変更など users.C 内部で操作する他の多くの設定があると考えられる。あなたのセキュリティ・ポリシーが確かなものであるとしても、何の役にも立たない。このアドバイザリは、クライアント側の users.C 不正使用に関する"概念の実証”として見なされるべきだ。

影響：
　低い。しかし、社内で実際にこの機能を使用し、その機能がセキュリティ上有用な動作をしていると思っているとしたら、あなたの考えは間違っている。

ベンダーの対応：
　この電子メールは、VPN-1 SecuRemote と SecureClient の再認証処理で発生する問題に対する回答だ。

　『まず、Check Point にこの電子メールを送付してくれたことに感謝する。
我々は、控えめで熟慮した方法において起こり得るセキュリティ懸念に対応したあなたの能力を高く評価する。

　懸案の問題に関して：この問題の手動管理ステーション設定を再定義にして再認証メカニズムをクライアント側で操作し、再エントリする際の資格証明書の要求を抑えることが可能だ。この動作を達成するためには、いくつかの事を適切に行う必要がある：
1- ユーザは、認証されたユーザでなければならない（すなわち、SR ユーザ名　　/認証資格証明書を持っている）
2- ユーザは、事前共通秘密、OS パスワード、FW-1 内部パスワードのような"　　キャッシュに保存可能な"資格証明書を使用しなければならない。
3- ユーザは、 userc.C ファイルの編集が可能でなければならない。
4- ユーザは、敵意のある意図を持つ必要がある。もしくは、セキュリティ実　　践において知識に乏しい（つまり、自身の資格証明書をキーボードに貼っ　　たり、過去に自身のマシーンが攻撃を受けたりした）。

前述の事態を緩和するためのメカニズム：
　NG の場合、userc.C ファイルは管理者権限を持たないユーザによる書き込み可能である必要はない。NT、2000、XP のような制限可能な OS の場合、ユーザが管理権限を持たないのなら、それでこの問題を解決する。
- 使い捨て(S/Key) もしくは期間ベースの認証資格証明書(SecurID) を使用する。
- FW-1 管理者が ncrypt_db(4.0、4.1 そしてNG で利用可能) 機能を使って、それらの設定が配置されている userc.C 内にそのトポロジー・データを隠蔽することができる。クライアントが encrypt_db プロパティを再定義することはできない（すなわち、たとえクライアントが userc.C の obscure_db の設定を変更したとしても、平文にするにはそのサイトを消去するか、再生しなければならない）。明らかに、これは曖昧なセキュリティ・メカニズムであり、完全ではない。
- 4.1 の場合、各アップデート後に、ユーザに userc.C の再認証設定の変更を強いて、自動的そして頻繁にトポロジーをアップデートを強いることが可能だ（それらは、再定義可能だが、同様に曖昧である）。

　理論上では再認証タイマーの再定義は可能だが、認証された資格証明書を持つ人物（もしくは入手可能なそれらの資格証明書で不正使用されるマシーン）が必要となる。そして、この事態を管理/緩和する方法がいくつかある。

　我々はその方法を実施するため、複数のメカニズムに講じる措置も調査している。しかし再度、WinCE や9X の場合、これはそれら OS 固有の特権（スーパー）ユーザ・メカニズムが欠如していることが一因となり問題を含んでいる。

　この問題に関して電子メールを送付してくれたことを再度感謝する。』

追加情報：
　この脆弱性は、 Amaury de Ville & Cedric Amand が発見した。

参考資料：
"pen-test" 内の"users.C" の以前の解析：
http://lists.jammed.com/pen-test/2001/05/0040.html

［情報提供：SecuriTeam］
http://www.securiteam.com/