今週のダイジェストで、ご紹介します。
- OAuth 認証のための適切な状態、nonce、PKCE チェックが欠けています。
- Apache HTTP サーバー：mod_proxy_uwsgi HTTP レスポンスの分割を行います。
- ShadowsocksX-NGは、CODE_SIGNING_INJECT_BASE_ENTITLEMENTSのため、com.apple.security.get-task-allow entitlementsで署名します。
- runcにおけるアクセス制御の問題により、攻撃者がコンテナ内で特権を昇格させることができる可能性があります。
cve-2023-27490:OAuth 認証のための適切な状態、nonce、および PKCE チェックが欠落している。
背景
OAuth (Open Authorization)は、ユーザー名やパスワードなどのユーザーの認証情報を知らなくても、サードパーティーのアプリケーションがユーザーの代わりにリソースにアクセスできるようにするオープンスタンダードなプロトコルです。OAuth は、リソース所有者（ソーシャルメディアプラットフォームなど）で自身を認証してアクセストークンを取得し、ユーザーの代わりにリソースにアクセスするために使用することによって、ユーザーがリソースへのアクセスを許可することができるという仕組みです。このアクセストークンはリソース所有者によって発行され、サードパーティアプリケーションは、ユーザーのログイン認証情報を知る必要なく、ユーザーのリソースにアクセスするために使用することができます。
ヴァルネラビリティ
脆弱性CVE-2023-27490 は、Next-auth パッケージに存在し、OAuth の認証フローに関連しています。具体的には、OAuth セッション中に、認証用 URL が攻撃者に傍受され、操作されることで発生します。この脆弱性により、攻撃者は被害者としてログインし、通常実施されているCSRF保護をバイパスすることができます。OAuth フローでは、認証プロセスを開始し、ユーザーのリソースへのアクセスを要求するために、認証 URL が使用されます。このURLには、CSRF、リプレイ攻撃、トークン盗難などの攻撃を防ぐために使用される、state、pkce、nonceといった重要なパラメータが含まれています。しかし、認証URLが攻撃者によって傍受され操作されると、これらの保護が回避され、Next-authパッケージで説明されている脆弱性につながる可能性があります。
脆弱性の根本的な原因は、侵害されたOAuth のセッション中に発生する部分的な不具合です。具体的には、セッションコードが誤って生成され、攻撃者がCSRF保護をバイパスして被害者としてログインできるようになります。
ミティゲーション
- この脆弱性はnext-authのバージョンv4.20.1で対処されており、最新版へのアップグレードが推奨されています。
- しかし、Advanced Initializationを使用することで、開発者はコールバックリクエストのstate、pkce、nonceをプロバイダ設定と照らし合わせて手動でチェックし、不一致があればサインイン処理を中止することができます。
CVE-2023-27522:Apache HTTP Server: mod_proxy_uwsgi HTTP レスポンスの分割。
背景
HTTP Request Smugglingは、Webアプリケーションの脆弱性で、攻撃者がアプリケーションまたはWebサーバーがクライアントから送信されたHTTPリクエストを処理する方法を操作できる場合に発生します。この脆弱性により、攻撃者はセキュリティ制御の回避、不正な操作、または機密データの窃取を行うことができます。
この攻撃は通常、フロントエンドのウェブサーバーとバックエンドのサーバーやアプリケーションがHTTPリクエストを処理する際のContent-Lengthヘッダーの解釈やchunkedエンコーディングの処理などの矛盾を利用するものです。このような矛盾を利用することで、攻撃者は2つのサーバーで異なる解釈をされるリクエストを作成することができます。その結果、リクエストは不適切に処理されるか、フロントエンドサーバーが攻撃者の代理として悪意のあるリクエストを実行するようになります。
ヴァルネラビリティ
脆弱性CVE-2023-27522は、Apache HTTP Server バージョン2.4.30 から 2.4.55 まで、特に mod_proxy_uwsgi モジュールを介して影響します。この脆弱性は、オリジンサーバーが、スペースやタブなどの特定の特殊文字を含む特別に細工されたHTTPレスポンスヘッダを送信し、その後に「Content-Length」ヘッダを送信した場合に発生します。
Apache HTTP Server の mod_proxy_uwsgi モジュールは、このヘッダーを誤 解釈し、切り捨てられたり分割された "Content-Length" ヘッダーでレスポンスをクライアントに転送することがあります。これにより、クライアントは不完全または不正なレスポンスを受け取ることになり、攻撃者がデータ漏洩、サーバーサイドリクエストフォージェリー（SSRF）、クロスサイトスクリプティング（XSS）、リモートコード実行（RCE）など、さまざまな種類の攻撃を行う可能性があります。
ミティゲーション
- Apache HTTP Serverの最新バージョンにアップグレードするか、利用可能なパッチを適用することをお勧めします。
- さらに、Webアプリケーションファイアウォールや侵入検知システムを使って、HTTPレスポンスの密輸攻撃を検知・防止することができます。
- また、HTTPレスポンスに特殊文字が混入しないように、適切な入力検証と出力エンコード技術を使用することが重要です。
cve-2023-27574:ShadowsocksX-NG は com.apple.security.get-task-allow で署名します。
背景
ShadowsocksX-NGは、ユーザーがインターネットにアクセスできる安全なsocks5プロキシを作成することにより、インターネット検閲を回避するための無料かつオープンソースのアプリケーションです。
アプリケーションを開発し、配布する準備ができたら、それが正当で改ざんされていないことを確認するために、有効な証明書で署名する必要があります。このプロセスはコードサイニングと呼ばれています。
コードサイニングの要件の1つに、アプリケーションが正しく機能するために必要な権限であるエンタイトルメントを含めることがあります。エンタイトルメントは、ネットワーク、ファイルシステム、ハードウェアなど、アプリケーションがアクセスできるリソースとアクションを指定します。
ヴァルネラビリティ
ShadowsocksX-NG version1.10.0には、com.apple.security.get-task-allow というエンタイトルメントで署名されたアプリケーションに脆弱性CVE-2023-27574が存在します。このエンタイトルメントにより、ユーザーの端末で動作している場合でも、Xcodeなどの開発ツールでアプリケーションのデバッグや検査ができるようになります。
このエンタイトルメントを含める理由は、CODE_SIGNING_INJECT_BASE_ENTITLEMENTSと呼ばれる機能によるものです。この機能は、コード署名プロセスの一部であり、開発者がアプリケーションのエンタイトルメントファイルで明示的に指定されたものを超えて追加のエンタイトルメントを含めることができます。言い換えれば、CODE_SIGNING_INJECT_BASE_ENTITLEMENTS機能が有効になると、Xcodeは自動的にアプリケーションの署名にデフォルトエンタイトルメントのセットを注入する。これらの権限は、開発者のアカウントとプロジェクトの設定に基づきます。彼らは、デフォルトでcom.apple.security.get-task-allow権限を含んでいます。
この方法の問題点は、com.apple.security.get-task-allowエンタイトルメントが攻撃者に悪用され、暗号化キーなどの機密情報をアプリケーションのメモリから取得される可能性があることです。これは、アプリケーションの脆弱性を悪用したり、サードパーティーのツールを使ってアプリケーションのメモリを読み取ることで可能です。
ミティゲーション
- ShadowsocksX-NG バージョン 1.10.0 のユーザーは、com.apple.security.get-task-allow エンタイトルメントを含まないバージョンにアップグレードするか、アプリケーションのコード署名からエンタイトルメントを手動で削除することを推奨します。
- また、VPN/プロキシソフトウェアの使用には注意が必要で、信頼できる安全なバージョンのソフトウェアを使用していることを確認する必要があります。
CVE-2019-5736: runc におけるアクセス制御の問題
背景
ランカは、Open Container Initiative (OCI) の仕様に従ってコンテナを生成・実行するためのコマンドラインユーティリティです。Docker、Kubernetesなどのコンテナランタイム環境で一般的に使用されています。
ヴァルネラビリティ
本脆弱性CVE-2019-5736は、アクセス制御の問題で、攻撃者がコンテナ内で特権を昇格させることができる。具体的には、1.1.4までのruncのバージョンで、コンテナ起動時にルートファイルシステム（rootfs）を処理する方法に関連する問題です。
でのlibcontainer/rootfs_linux.goは、コンテナのrootfsを読み取り専用でマウントし、その上に書き込み可能なレイヤーを重ねることで、コンテナのrootfsをセットアップします。このプロセスは、コンテナのファイルシステムを作成し、ホストシステムから分離するために使用されます。
しかし、このコードの欠陥により、攻撃者は、ホストシステムの /proc/self/exeファイル（runcバイナリ自体へのシンボリックリンク）を作成します。こうすることで、攻撃者は昇格した特権で任意のコードを実行し、コンテナを効果的に脱出してホストシステムの制御権を得ることができます。
ミティゲーション
- パッチが適用されたバージョンにアップグレードしてください。runcのバージョン1.0.0-rc6以降には、この脆弱性を修正したパッチが適用されています。
- コンテナランタイムをアップグレードしてください。DockerやKubernetesなどのコンテナランタイム環境を使用している場合は、パッチを適用したruncバージョンを含むバージョンに必ずアップグレードしてください。
- アクセス制御を実施する。この脆弱性のリスクを軽減するために、攻撃者がカスタムボリュームマウント構成のコンテナを生成し、カスタムイメージを実行する能力を制限するアクセス制御を実装する必要があります。
- コンテナの権限を最小化する。コンテナの特権を最小限に抑えることで、潜在的な攻撃の範囲を限定することができます。これは、コンテナを非 root ユーザーとして実行し、コンテナの機能を制限し、機密性の高いホストリソースへのアクセスを制限することで実現できます。
コメント