CVE-2023-23397：Windows版 Outlookに重大な特権昇格の脆弱性

脅威情報
2023.3.18
更新日：2023.3.19

1 概要
2 この脆弱性の仕組み
3 NTLMv2とは？
4 攻撃者がNTLMv2 Hashを使用してできること
5 心配する必要があるのか
6 悪用の現状
7 自組織が標的にされているかを確認するには
8 この脆弱性に対応するには
9 パッチはどのように問題に対処するのか
10 今後のさらなる強化策
11 関連情報

概要

3月のセキュリティアップデート「Patch Tuesday」において、Outlookの新たなセキュリティ脆弱性が実際に悪用されていることが明らかになりました。これは、NTLMハッシュの流出によりドメインを侵害する可能性がある深刻な脆弱性です。今回の悪用は、CVE-2017-8572や CVE-2017-11927など、2017年にさかのぼる関連脆弱性の最新版にすぎず、攻撃者はOutlookからユーザーのNTLMv2認証情報を漏洩させることができました。これらの認証情報を利用して、攻撃者はネットワーク上のWindowsホストとの認証時に被害者になりすますことができ、被害者のユーザー権限に応じて重要なサーバーへの自由なアクセスを許可する可能性があります。

この脆弱性の仕組み

CVE-2023-23397は、攻撃者がOutlookからNTLMv2ハッシュを漏洩させることができる脆弱性です。この脆弱性は、悪意のあるカレンダーの招待（インビテーション）を被害者に送信することでリモートで実現可能です。この脆弱性は、.msg 形式で表わされ、リマインダーをサポートしている任意のOutlook のエンティティが、脆弱性を引き起こすために利用される可能性があります。実際の脆弱なAPIエンドポイントは、OutlookのPlayReminderSoundで、PidLidReminderFileParameterを使用して、リマインダー用のカスタム警告音を指定します。

この問題は、PidLidReminderFileParameterに攻撃者が管理するサーバーを指すUNCパスが設定されている場合に発生します（アップデート前はOutlookで許可されていました）。攻撃者は、このようなカスタムリマインダーサウンドの場所を含むカレンダーの予定を被害者に送信することでこれを利用できます。これにより、被害者の Outlook クライアントは攻撃者が制御するサーバーで認証を試み、NTLM 認証を使用してリマインダーサウンドを取得します。これにより、被害者はNTLMv2ハッシュを攻撃者に漏洩することになります。攻撃者はまた、PidLidReminderOverrideAPI パラメータを使用して、警告音の使用を強制する可能性があります。このパラメータは、PidLidReminderFileParameter で指定された値を尊重するよう Outlook に指示し、効果的にサウンドを使用するトリガーとなります。このパラメータがない場合、Outlookは攻撃のトリガーとなるカスタマイズされたサウンドファイルを無視する可能性があります。

NTLMv2とは？

NTLMv2 ハッシュは、さまざまな形式の認証に使用される Windows の「LANMAN」ハッシュの最新の形式です。NTLM の LM は「LAN manager」の略で、古い Windows ネットワークサービスに由来します。従来の Windows アプリケーションは NTLMv1 プロトコルを使用しており、このプロトコルでは暗号的に弱いハッシュアルゴリズムが使用されていました。そのため、NTLMv1 は最近のアプリケーションでは使用されなくなりました。

NTLMv2 はチャレンジレスポンスプロトコルであり、サーバからのチャレンジを受信すると、2 つのレスポンスが送信されます。それぞれのレスポンスには、ユーザー名とパスワードのハッシュ、およびその他の情報を含む、ユーザの認証情報のハッシュ化された表現が含まれています。

攻撃者がNTLMv2 Hashを使用してできること

多くのサービスでは、認証に NTLMv2 ハッシュを直接使用しています。攻撃者はホストやサービスにアクセスするために、NTLM リレー攻撃を試みる可能性があります。いくつかのシナリオでは、攻撃者はハッシュを使用して Windows ホストに直接認証することができます。これは、特に管理者ユーザの NTLMv2 ハッシュが流出した場合、ドメインの完全な侵害につながる可能性があります。一人のユーザーのハッシュが流出すると、攻撃者がドメインを横断し、これらの NTLM リレーシナリオで特権を昇格させることは珍しいことではありません。

心配する必要があるのか

一言で言うと、「はい」です。

少し詳しくお伝えすると、この脆弱性は非常に簡単に悪用でき、すでに利用されていることが確認されています。さらに、被害者は、悪意のあるイベントを含む電子メールに直接操作する必要は全くありません。プレビュー画面を操作する必要もありません。

簡単に言えば、Outlookを使用している組織であれば、この脆弱性を心配する必要があります。

悪用の現状

アクティブな攻撃については現在も情報が明らかになりつつあるところですが、この脆弱性を利用した攻撃は、すでにいくつか確認されています。デジタルフォレンジックの研究者は、活発な悪用キャンペーンを検知しており、トルコの軍事請負業者に対する攻撃に関する逸話も明るみに出ているようです。

自組織が標的にされているかを確認するには

Microsoftは、Exchangeに悪意のあるメッセージがないか監査し、スクラブすることができるスクリプトを公開しました。Yaraのルールは、こちらで確認できます。

つまり、悪用される前に、PidLidReminderFileParameter を使用した悪意のある .msg ファイルを探します。攻撃後は、ネットワーク上の NTMLv2 リレー攻撃の証拠や、NTLMv2 ハッシュを経由して個々のユーザアカウントが侵害されている兆候を探します。これらは、新規または認識されていない IP アドレスからの異常なログインの形を取ります。

この脆弱性に対応するには

何よりもまず、Outlookの3月のセキュリティ更新プログラムを適用してください。

次に、上記のリンク先のスクリプトを使用して、組織のExchangeサーバーの監査を実行します。

第三に、即時のパッチ適用が不可能な場合、次のMicrosoftの緩和ガイダンスに従うことを検討してください。

ユーザーを Protected Users セキュリティグループに追加します。これにより、NTLM を認証メカニズムとして使用できなくなります。この緩和策を実行すると、NTLMを無効にする他の方法よりもトラブルシューティングが容易になります。可能であれば、ドメイン管理者などの価値の高いアカウントに使用することを検討してください。注意：NTLMを必要とするアプリケーションに影響を与える可能性がありますが、ユーザーを保護されたユーザーグループから削除すると、設定は元に戻されます。詳しくは、「保護されたユーザーのセキュリティ」をご覧ください。
境界ファイアウォール、ローカルファイアウォール、およびVPN設定を使用して、ネットワークからのTCP 445/SMB アウトバウンドをブロックします。これにより、リモートファイル共有へのNTLM認証メッセージの送信を防ぐことができます。

パッチはどのように問題に対処するのか

図1：3月のセキュリティアップデート前（左）とアップデート後（右）のPlayReminderSound。

3月のセキュリティアップデートの適用前と適用後のOutlook.exeバイナリのパッチDiffを実行した結果、変更された関数の1つにPlayReminderSoundがあることがわかりました。上の図1は、この関数のパッチ適用前（左）と適用後（右）の逆コンパイルしたコードです。この関数は、パッチ適用前の関数コードの一番下にあるHrAsyncPlayReminderSoundのラッパー関数であり、リマインダーのサウンドファイルを取得して再生するという作業を実際に行う関数であることに留意する必要があります。

パッチ適用版では、ReminderFileParamに対して IsFileZoneLocalIntranetOrTrustedという関数を呼び出すコードのブロックが追加されていることがわかります（赤でハイライトされています）。IsFileZoneLocalIntranetOrTrustedは、その名の通り、渡されたファイルパスがデバイスのローカルイントラネットに属するか、信頼できるドメインに属するかをチェックし、属する場合は1（真）、属さない場合は0（偽）を返します。注目すべきは、このチェックが失敗した場合、ReminderPlaySoundフラグが0（false）に設定され、この関数はCLEAN_UPステップにスキップしてHrAsyncPlayReminderSoundを完全に起動しないようにすることで、提供したReminderFileParamが安全ではないとみなされると脆弱性コードパスに到達できないようにしています。

今後のさらなる強化策

歴史が私たちに何かを教えてくれるとすれば、これが最後の NTLMv2 ハッシュ漏洩の脆弱性になることはないということです。この機会に、あらゆる種類の NTLM リレー攻撃に対して、組織のインフラを強化することをお勧めします。ありがたいことに、Microsoftはこの目標を達成するためのガイダンスを提供するKB 記事を用意しています。

その上で、一般的なガイドラインとして、以下のようなものがあります。

SMB署名を有効にする
認証の拡張保護機能を有効にする
ログインを監査していることを確認し、セキュリティロギングメカニズムを構成して、異常なログインに効果的にフラグを立てる
最小特権の原則を適用し、ドメイン全体への管理者特権の拡散を制限する。NTLM リレー攻撃は、ドメイン全体への侵害の第一歩となることが多く、これは通常、管理者認証情報が組織内で広く共有されている場合にのみ可能