【ITニュース解説】Rejetto HFS signs its admin session cookie with Math.random()

Rejetto HFSの脆弱性CVE-2026-61500について解説する。HFSは、オフィスで使われるようなシンプルなファイルサーバーソフトウェアで、単一の実行ファイルとブラウザからアクセスできる管理画面を持ち、ファイル共有に使われる。今回の脆弱性は、このようなツールがセッションのセキュリティを、秘密を守るようには設計されていない「Math.random()」という乱数生成器に依存していたことで発生した。

この脆弱性は、CVSS 4.0スコアで9.3という高い深刻度と評価され、CWE-338（暗号学的に弱い擬似乱数生成器の使用）に分類されている。具体的には、HFSのバージョン3.0.0から3.2.0までが影響を受け、バージョン3.2.1で修正された。

問題の核心は、セッションクッキーの署名キーがJavaScriptの「Math.random()」から生成されていたことにある。この乱数生成器は汎用的なもので、暗号学的な要件を満たしていない。さらに悪いことに、この生成器の出力が、ログイン時などに未認証のクライアントにも一部公開されていた。

弱い乱数生成器が単独で使われていたとしても、攻撃者にとっては未知の値であり推測は難しい。しかし、その生成器の出力を攻撃者が観察できる場合、話は大きく変わる。両者が組み合わさることで、攻撃者は「キーを推測する」という途方もない作業ではなく、「少数のサンプルから生成器の状態を再構築する」という、はるかに現実的な方法でキーを特定できてしまう。

なぜ生成器の出力を観察するだけで十分なのかを説明する。JavaScriptエンジンで使われる擬似乱数生成器は、基本的に「決定論的な状態機械」である。これは、現在の内部状態によって次の出力が決まり、同じ内部状態からは常に同じ出力が得られるという性質を持つ。通常、一つの出力だけでは次に何が出るかを予測するのは困難だが、連続した複数の出力が得られれば、その生成器の内部状態を力ずくで探すのではなく、計算によって特定することが可能になる場合が多い。

今回の脆弱性もまさにこの手口が悪用された。攻撃者は、ログイン時のサーバーからの応答をいくつか集める。これにより、擬似乱数生成器の連続した出力の一部を知ることができる。その出力から生成器の内部状態を逆算し、最終的にセッションクッキーの署名キーを特定する。

署名キーが一度特定されてしまえば、クッキーを盗む必要はなくなる。攻撃者は自ら管理者権限を持つ偽のクッキーを作成し、特定した署名キーで署名してサーバーに提示できる。これにより、パスワードを推測したり、フィッシング詐欺を仕掛けたり、長時間同じネットワークセグメントに滞在したりする必要なく、管理者セッションを奪取されてしまう。

管理者アクセスを奪われると、攻撃者はさらに深刻な攻撃を行うことが可能になる。HFSには「server_code」という設定機能があり、管理インターフェースを通じてサーバーサイドのJavaScriptコードを実行できる。そのため、偽造された管理者セッションを持つ攻撃者は、「共有フォルダの内容を見られる」という状態から一歩進んで、「ファイルサーバーを実行しているアカウントの権限でコードを実行できる」状態へと被害を拡大させることができる。

このコード実行能力は、脆弱なクッキー生成の欠陥をシステム全体の乗っ取りへとつながる重大なものに変えてしまう。HFSが通常動作する小規模なサーバーでは、このファイルサーバーのプロセスが、システムの管理者アカウント（SYSTEMアカウントやローカル管理者など）で実行されていることも少なくない。これは、ツールが簡単にインストールされた結果、利便性が優先されてしまったためである。もしそうであれば、攻撃者はサーバー全体を完全に制御できるようになる。

HFSのインストールは特定の業界に集中しているわけではない。支社のマシン、ビルド成果物を配布するエンジニアリングワークステーション、数年前に導入され放置されている管理サービスプロバイダーのクライアントサーバーなど、さまざまな環境で利用されている。

ZoomEyeのような検索エンジンでHFSの存在を調べると、数万件ものインスタンスがインターネット上に存在することがわかる。しかし、これらの検索結果ではHFS 2.xと3.xの区別がつかず、脆弱なビルドを実行しているホスト数を正確に特定することは難しい。そのため、自身の環境におけるHFSのバージョン情報は、社内の構成データから確認する必要がある。

このような脆弱性から身を守るために、まず確認すべき点がいくつかある。

第一に、HFSのバージョンを確認する。バージョン3.0.0から3.2.0までの範囲は影響を受けるため、すぐにバージョン3.2.1にアップデートする必要がある。HFS 2.xは別のコードベースだが、これにも独自の脆弱性の歴史があるため、安易に安全と判断すべきではない。

第二に、管理インターフェースがインターネットに公開されているかどうかを確認する。管理機能を持つファイルサーバーを不特定多数のアドレスからアクセスできるようにすることは、セキュリティ上の大きなリスクである。管理ネットワークやVPNに制限し、ファイル共有機能と管理ページは分離することが望ましい。

第三に、サービスアカウントの権限を見直す。HTTPリクエストに応答するプロセスがローカル管理者などの高い権限で実行されている場合、将来的に別の脆弱性が見つかった際には、それが直ちにシステム全体の乗っ取りにつながる可能性が高まる。専用の、最小限の権限を持つアカウントでサービスを実行することで、万一の被害を最小限に抑えることができる。

第四に、アップグレード後も既存のセッションクッキーには注意を払う。脆弱性修正により署名キーは変更されるが、アップグレード前に発行されたクッキーは、すでに攻撃者に知られているキーで署名されている可能性がある。そのため、サービスを再起動し、チーム内の誰も実行していない管理者操作がないか、アクセスログを徹底的に確認することが重要である。

パッチが適用された後も、システムが侵害されていないかを確認するための検出アイデアがある。これはバージョン情報に頼るのではなく、システムの振る舞いを監視するものだ。

管理エンドポイントでの認証成功ログを監視する。特に、ログインフォームを通さずに認証が成功しているにもかかわらず、そのアクセス元のアドレスが以前にログインしたことがない場合に注意が必要だ。偽造されたクッキーによるリクエストは、通常の一連の対話的なログイン手順（失敗した試行や複数のリクエストによるログインフロー）をスキップし、新しいソースから直接特権エンドポイントへの認証済み呼び出しとなるため、通常のログインとは異なる振る舞いを示す。

HFSサービスがどのような子プロセスを起動しているか監視する。Windows環境では、HFS実行ファイルが子プロセスを生成することは通常稀であり、特にシェル、スクリプトホスト、またはダウンロードユーティリティのようなプロセスが子として現れた場合は、強力な警告信号とみなすべきだ。Linux環境でも、ファイルサーバーのプロセスツリーは通常ほぼ空であるため、その下にシェルが現れた場合は同等の危険信号となる。「server_code」機能の悪用は、まさにこの層で子プロセスとして実行されるため、監視によって可視化される。

ファイルサーバー自身の構成変更にも注意を払う。「server_code」機能は非常に強力であり、不要であれば無効にすることで、未パッチのホストであっても攻撃チェーンの最終段階を排除できる。この機能に対するいかなる変更も、厳重にレビューするべきである。

今回の事例から得られる教訓は、一つの小さな製品にとどまらない。汎用的な乱数源から組み立てられたクッキー署名キー、およびその乱数源の出力を外部に晒すようなコードパスは、パスワードに触れることなくセッションモデル全体を無効にしてしまう。アプリケーションが「このユーザーはログインしているか」を署名に基づいて判断する場合、暗号学的に安全な乱数生成器を使用し、キーがサーバーから決して漏洩しないように設計し、そしてこれらが適切に機能していることを確認するレビュープロセスを確実に実施する必要がある。