Microsoft Exchange の脆弱性 ProxyToken によりメールがハックされる

Microsoft Exchange ProxyToken bug can let hackers steal user email

2021/08/30 BleepingComputer — Microsoft Exchange Server の深刻な脆弱性 ProxyToken について、技術的な詳細が明らかになった。この脆弱性は、標的となるアカウントからメールにアクセスする際に、認証を必要としないというものだ。攻撃者は、Exchange Control Panel (ECP) アプリケーション内の、Web サービスへ向けたリクエストを細工することで、この脆弱性を悪用し、被害者の受信箱からメッセージを盗み出す。

権限委譲の混乱

この 脆弱性 ProxyToken CVE-2021-33766 は、認証されていない攻撃者に対して、ユーザー・メールボックスのコンフィグレーション・オプションへのアクセスを許し、さらに、メール転送ルールの定義まで許していまう。その結果として、標的となるユーザーに宛て送信されたメールが、攻撃者が管理するアカウントにも配信されてしまう。

このバグは、Information Security Center of Vietnam Posts and Telecommunications Group (VNPT-ISC) の 研究者である Le Xuan Tuyen により発見され、3月に Zero-Day Initiative (ZDI) プログラムを通じて報告された。同氏は、Microsoft Exchange のフロントエンド・サイト (Outlook Web Access / Exchange Control Panel) は、主にバックエンド・サイト (Exchange Back End) のプロキシとして機能しており、バックエンド・サイトに認証要求を渡していることを発見した。

この委任認証 (Delegated Authentication) 機能が有効になっている Microsoft Exchange のデプロイメントでは、フロントエンドは認証が必要な要求をバックエンドに転送し、バックエンドは SecurityToken クッキーの存在により要求を識別する。そして、「/ecp」内のリクエストに空ではない SecurityToken クッキーが存在する場合、フロントエンドは認証の判断をバックエンドに委ねる。しかし、Microsoft Exchange のデフォルトの設定では、バックエンドの ECP サイトに、認証処理を委 任するモジュール (DelegatedAuthModule) がロードされない。

脆弱性 ProxyToken の悪用においては、別のマイナーな問題がある。/ecp ページへのリクエストには ECP canary というチケットが必要だが、このチケットは HTTP 500 エラーを引き起こす際に入手できる。結局のところ、チケットを取得していないリクエストは、認証されていないリクエストを成功させるために必要な、有効な文字列を含む HTTP 500 エラーをトリガーすることになる。

Microsoft のアドバイザリによると、7月からパッチが提供されている。Rapid7 の Tom Sellers は、バージョン番号と日付から、4月の時点でパッチがリリースされていたことが分かると指摘している。この脆弱性に関して、NIST は深刻度 7.5 を算出している。なぜなら、被害者と同じ Exchange サーバーのアカウントを、攻撃者が必要とするからだ。Zero-Day Initiative は、本日のブログで、一部の Exchange サーバー管理者は、任意の宛先へ向けたメール転送ルールの作成を許可するための、グローバル・コンフィグレーションを行っていると指摘している。このようなケースでは、攻撃者は認証情報を必要としない。

エクスプロイトの試み

ProxyToken に関する技術的な詳細は、本日に発表されたばかりだ、3週間前には悪用の試みが記録されている。NCC Group のレッド・チームに在籍する Rich Warren によると、8月10日には数多くの悪用の試みが発見されたとのことだ。ProxyShell の脆弱性の場合と同様に、Microsoft Exchange サーバーの管理者が ProxyToken CVE-2021-33766 のパッチをインストールしていない場合は、優先的に対応する必要がある。

Microsoft Exchange のフロントエンド/バックエンドについては、「Black Hat 2021:Microsoft Exchange 問題の新たな観点」でも、Orange Tsai の「2013年に実施された Client Access Services (CAS) における大幅な変更により、Exchange の基本的なプロトコル・ハンドラが、フロントエンドとバックエンドのコンポーネントに分割された。この根本的なアーキテクチャの変更により、かなりのレベルの設計上の負担が発生し、コンテキスト間に不整合が生じた」というコメントが紹介されていました。とにかく、ProxyToken 対するパッチの確認ですね。

%d bloggers like this: