CreateRCE — CreateUri の新たな脆弱性
エグゼクティブサマリー
Akamai の研究者 Ben Barnea が Microsoft Windows の重大な脆弱性を発見し、 CVE-2023-35628が割り当てられました。
インターネット上の攻撃者は、ユーザーの操作なし(ゼロクリック)で Outlook クライアントの脆弱性をトリガーできます。
この脆弱性は、CreateUri 関数によるパスの解析に存在します。現時点で、Akamai はこの脆弱性をトリガーする方法を 2 つ把握しています。それは、(1)細工された電子メールを Outlook クライアントに送信すること、または(2)ユーザーに File Explorer を使用させて、悪性のダウンロードファイルが含まれているフォルダーに移動させることです。
この脆弱性は、「責任ある開示」に従って Microsoft に報告され、 2023 年 12 月の Patch Tuesdayで対処されました。
2023 年 12 月のソフトウェアアップデートがインストールされた Windows マシンは、この脆弱性から保護されています。さらに、2023 年 3 月のソフトウェア更新プログラムでパッチが適用された Exchange サーバーを使用する Outlook クライアントは、機能の悪用から保護されます。
概要
Microsoft はエンタープライズなどの至るところに存在しているため、攻撃者にとって重要な(利益の出やすい)標的になっています。そのため、Akamai は一連の製品やプロトコルについて広範な調査を行って、脆弱性と、検知と緩和を後押しする 構築 ツール の両方を発見しました。
この調査の一環で、Akamai は WinAPI の CreateUri 関数に新しいリモートコード実行(RCE)の脆弱性を発見しました。この関数は、元の脆弱性である CVE-2023-23397 のパッチの一部として呼び出されます。 以前の RCE の 脆弱性 チェーン は、ゼロクリック RCE プリミティブを実現するために 2 つの脆弱性を連鎖させる必要がありましたが、この脆弱性は単独でそれを行えます。また、Outlook だけでなく、File Explorer でこの脆弱性をトリガーする方法についても説明します。
この脆弱性の経緯
2023 年 3 月の Patch Tuesday で対処された脆弱性の中に、Microsoft 自身によって発見された重大な Outlook の脆弱性( CVE-2023-23397)がありました。この脆弱性を 野放し状態で悪用 していたのは、ロシアの支援を受けている攻撃者 Forest Blizzardでした。
2023 年 12 月、Microsoft とポーランドのサイバー軍は、同じ攻撃者が最近この脆弱性の悪用を試みたことを 発表 しました。この脆弱性により、攻撃者は Outlook クライアントに攻撃者のサーバーへの接続を強制することができました。この接続の一環として、クライアントは NTLM 認証情報を攻撃者に送信します。その後、攻撃者は NTLM 認証情報をオフラインで解読したり、リレー攻撃で使用したりできます。 この脆弱性は、ユーザーの操作なし(ゼロクリック)で、インターネットを介してリモートで悪用される可能性がありました。
この脆弱性に対するパッチがリリースされた後、Akamai は 2 つの バイパス と音声解析の脆弱性を発見しました。そのバイパスと解析の脆弱性の両方を連鎖させると、Outlook クライアントの完全ゼロクリックの RCE プリミティブにつながる可能性があります。
MapUrlToZone
Outlook の脆弱性 CVE-2023-23397のパッチの一部として、カスタムリマインダー音を処理する役割のあるコードによって MapUrlToZoneの呼び出しが追加されました。この呼び出しは、拡張 MAPI プロパティ「 PidLidReminderFileParameter」によって指定された URL がインターネットリソースを指さないことを確認します。
これにより、当初の脆弱性は緩和されますが、新しいアタックサーフェスが発生します。それは、 MapUrlToZone 関数自体です。そのため、 MapUrlToZoneに渡されているパスを制御します。
MapUrlToZoneによって実行される解析の一環として、この関数は CreateUriを呼び出します。 CreateUri は、URI(Uniform Resource Identifier)を表す IUri オブジェクトを作成します。このオブジェクトを作成するために、この関数は URL と一部の DOS Windows パスを 解析 することがわかっています。
CreateUri がファイルパス(たとえば file:// スキームや、ファイル/ディレクトリーを指す Windows パス)を使用して呼び出されると、 CrackUrlFile が呼び出されます。この関数にも、 以前のブログ記事で説明したバイパスがあります。
新たな脆弱性
CrackUrlFileは、最初に Windows パスではなく URL を受け取った場合、その入力のコピーを作成し、 PathCreateFromUrlWを使用してその URL コピーを変換し、Windows パスに戻します。作業バッファーは動的に割り当てられるようにマークされているため、後で解放することがわかります。この関数が Windows パスを受け取った場合、入力パスを直接操作するため、ポインターを解放する必要はありません。
作業バッファーの解析中に、バッファーを進めることができます。たとえば、バッファーがローカル・デバイス・パスの場合(「\\.\」または「\\?\」で始まる場合)、この関数はポインターを 4 文字分進めます。次に、デバイス名が「UNC\」の場合は、さらに 4 文字分進みます。また、バックスラッシュが複数ある場合、この関数は重複したバックスラッシュを過ぎるまでバッファーを進めます。
バイパスへのパッチをリバースした結果、2023 年 7 月に新しいコードが CrackUrlFile に追加されたことがわかりました。これは、Akamai が発見したバイパスとは無関係のようです(図 1)。
パス解析の一環として、この関数はパスコンポーネントがドライブパスかルートパスかをチェックします。「はい」の場合、パスは「ローカル」とマークされます。パスがドライブパスの場合、新しいコードは元のバッファーポインターをパスコンポーネントへのポインター(進められたバッファー)でオーバーライドします。
バグの原因は、このようにして 進められたポインターが保存されるためです。その後、元のバッファーポインター(図 1 のPPWorkingBuffer )が動的に割り当てられた場合、それが取得されて解放されます。進められたポインターでオーバーライドされたため、malloc で返されなかったポインターで free() の呼び出しが発生します。 これにより、攻撃者はメモリーアロケーターに悪性のチャンクのメタデータを提供するためのプリミティブを得ることができます。
この脆弱性をトリガーするためには、まず UNC パスを使用してファイルスキーム URL を指定する必要があります。次に、パスをドライブパスとしてマークする必要があるため、共有(C:)を使用しなければなりません。この脆弱性をトリガーするパス全体は、次のようになります。
file://./UNC/C:/Akamai.com/file.wav
これで、修正されたコードはポインターを保存するのではなく、RtlMoveMemory を使用してパスコンポーネントのバイトをコピーするようになりました。
Explorer を使用してトリガー
そのような場所を見つけることは Akamai の調査の対象外でしたが、一度手早くWindows Explorer によるトリガーを試みました。
これを行うために、脆弱なパスを指すショートカット(.lnk file)を作成しました。被害者がこのショートカットファイルが存在するディレクトリーを表示すると、Explorer でこの脆弱性がトリガーされ、即時クラッシュが発生します(図 2)。
ご自身のマシンがこの問題に対して脆弱かどうかをテストするためには、Explorer をクラッシュさせる 概念実証 (PoC)をダウンロードしてください。(PoC を使用する前に、Akamai の セキュリティ調査リポジトリー で詳細とリスクをよくご確認ください。)
まとめ
これは、CVE-2023-23397 の潜在的な影響に関する調査についての最後のブログ記事です。
2023 年 5 月に最初のバイパスを発見した際、Akamai は、 MapUrlToZone を使用すると新たなアタックサーフェスが生じるため、悪用された機能を削除することを推奨しましたまた、サンドボックスを使用せずに、ゼロクリックの形で音声解析のアタックサーフェスをリモート攻撃者に晒すことは、ユーザーにとって価値よりも危険の方が大きいと主張しました。
その後の調査で、Akamai は 2 つの バイパスを発見し、 音声解析の問題を発見し、最終的には Windows パス解析のメモリー破損を発見して、その主張が正しかったことを証明しました。
これらの記事をご覧になった皆様が、Windows パス、サウンドコーデック、さまざまな脆弱性に関する新たな知識を得られていれば幸いです。他の研究者にも、パッチを調査し、それをどのように回避できるかを考えていただきたいと思います。他に MapUrlToZone のバイパスが存在する可能性はないとは言い切れません。