概要

セキュリティ研究者たちは、誤って設定されたJupyter Notebookサーバーに存在する脆弱性を発見しました。これにより、攻撃者はLinuxシステム上でルートレベルのアクセス権を獲得できる可能性があります。この問題はJupyter自体にバグがあるわけではなく、むしろシステムを特権昇格攻撃に対して無防備にする危険な設定選択に起因しています。

脆弱性の詳細と攻撃経路

最近のペネトレーションテスト中に、あるセキュリティ専門家は、認証なしでルート権限で実行されているJupyter Notebookサーバーが、システムを完全に侵害するゲートウェイとなっていることを発見しました。この攻撃連鎖は、正当なユーザーがシェル環境にアクセスするために設計されたJupyterの組み込みターミナルAPIを悪用したものです。適切なセキュリティ制御がなければ、この機能は直接的な特権昇格経路へと変貌します。

Jupyterは、ターミナルエンドポイントを含むREST APIを提供しています。これは、パッケージのインストールや環境管理を目的としていますが、Pythonコードを実行するカーネルAPIとは異なり、実際のシェルアクセスを許可します。保護されていないJupyterインスタンスにネットワークアクセスできる攻撃者は、認証を必要とせずに/api/terminalsエンドポイントを通じてターミナルセッションを作成できます。

攻撃はWebSocket接続を通じてさらに巧妙になります。Jupyterのターミナルセッションは、従来のHTTPリクエストではなくWebSocketプロトコルを介して通信します。websocatのような特殊なツールを使用することで、攻撃者はメッセージをJSON配列としてフォーマットし、WebSocketインターフェースを通じてコマンドを送信できます。例えば、["stdin", "id\n"]のような単純なコマンドをWebSocket経由で実行すると、出力が直接返され、ターミナルがルート権限で実行されていることが明らかになります。研究者は、JupyterターミナルのWebSocketに接続し、idコマンドを実行することで攻撃を実証しました。これにより、直ちにuid=0 (root)が返され、特権昇格を必要とせずに完全なシステム侵害が確認されました。

攻撃後の影響

ルートアクセスが確立されると、攻撃者は/root/.local/share/jupyter/runtime/に保存されているJupyterのランタイム設定ファイルにアクセスできます。これらのファイルには、カーネル接続ポート、メッセージ認証用のHMAC署名キー、セッション情報などの重要な情報が含まれています。これらの認証情報を手に入れた攻撃者は、他のユーザーのノートブックセッションを乗っ取り、そのカーネルで任意のコードを実行できます。研究者は、Jupyterターミナルを通じてリバースシェルを起動することで、永続的なバックドアを確立できることを示しました。これにより、侵入は正当なJupyterアクティビティとして監視システムに表示されるため、検出が困難になります。

推奨される対策

セキュリティコミュニティは、これがJupyterの脆弱性ではなく、デプロイメントのアンチパターンであることを強調しています。組織はJupyterをルート権限で実行すべきではありません。代わりに、Jupyterは非特権ユーザーとして、必要な機能のみを付与された状態で実行されるべきです。マルチユーザー環境では、管理者は適切なユーザー分離と認証がデフォルトで有効になっているJupyterHubを実装する必要があります。

• Jupyterを実行しているシステムは、不要な場合はターミナルAPIを直ちに無効にするべきです。
• 強力な認証トークンを実装してください。
• 認証なしでJupyterインスタンスをlocalhost以外のネットワークインターフェースに公開してはなりません。

組織は、攻撃者が悪用する前に、Jupyterのデプロイメントを直ちに監査し、この危険な設定パターンを修正する必要があります。

元記事: https://gbhackers.com/jupyter-misconfiguration-exposes-systems/