クラウドコンピューティングが必要ですか? 今すぐ始める

ある脆弱性から別の脆弱性へ:Outlook パッチ分析で Windows API の重要な脆弱性が明らかに

Ben Barnea

執筆者

Ben Barnea

May 10, 2023

Ben Barnea

執筆者

Ben Barnea

Ben Barnea is a Security Researcher at Akamai with interest and experience in conducting low-level security research and vulnerability research across various architectures, including Windows, Linux, IoT, and mobile. He enjoys learning how complex mechanisms work and, more important, how they fail.

Akamai 研究者の Ben Barnea が、Internet Explorer のコンポーネントに新たな重要な脆弱性(CVE-2023-29324)を発見しました。CVSS ベーススコアは 6.5 です。

編集・協力:Tricia Howard

エグゼクティブサマリー

  • Akamai 研究者の Ben Barnea が、Internet Explorer のコンポーネントに新たな重要な脆弱性( CVE-2023-29324 )を発見しました。CVSS ベーススコアは 6.5 です。

  • この脆弱性により、Windows API 関数( MapUrlToZone )はリモートパスがローカルパスであると誤解します。

  • MapUrlToZone は一般的にセキュリティ対策として使用されます。特に、Outlook の重大な脆弱性である CVE-2023-23397 を緩和するために使用されました。この脆弱性に対してパッチが適用されたのは 3 月の Patch Tuesday です

  • インターネット上の不正な攻撃者がこの脆弱性を悪用して、攻撃者が制御するサーバーへの接続を Outlook クライアントに強制する可能性があります。これにより、NTLM 認証情報が盗まれます。この脆弱性はゼロクリックであるため、ユーザーが操作しなくてもトリガーされる可能性があります。

  • すべての Windows バージョンがこの脆弱性の影響を受けます。その結果、Windows 上のすべての Outlook クライアントバージョンが悪用される可能性があります。しかし、Microsoft によると、3 月の更新プログラムを適用した Exchange サーバーでは、脆弱なクライアントが悪用されないようにするために、脆弱な機能が削除されています。

  • この問題は、Microsoft に確実に開示され、2023 年 5 月の Patch Tuesday で修正されました。

概要

2023 年 3 月の Patch Tuesday の一環として解決された脆弱性の中には、Outlook の重大な脆弱性( CVE-2023-23397)がありました。 

この脆弱性により、攻撃者は Outlook クライアントに攻撃者のサーバーへの接続を強制することができます。そうして、クライアントから NTLM 認証情報をマシンに送信させ、パスワードをオフラインで解読したり、リレー攻撃で使用したりすることができます。この脆弱性は、ユーザーの操作なし(ゼロクリック)で、インターネットを介してリモートで悪用される可能性があります。

Microsoft Threat Intelligence の評価によると、ロシアの攻撃者は、欧州の政治、運輸、エネルギー、軍事分野の複数の組織に対する標的型攻撃にこの脆弱性を約 1 年間利用していました。

Akamai は パッチ分析を行う中で、この重大な脆弱性の修正を回避する方法を発見しました。このブログ記事では、元の脆弱性、それに対するパッチ、およびそのパッチの回避について説明します。

元の脆弱性

3 月にパッチが適用された Outlook の脆弱性は、カスタム通知音を伴うリマインダーを含む電子メールを攻撃者が送信するとトリガーされます。このカスタムサウンドが攻撃者によってパスとして指定されます。その際に利用されるのが、拡張された MAPI プロパティ PidLidReminderFileParameterです。攻撃者は、クライアントに SMB サーバーからサウンドファイルを取得させる UNC パスを指定できます。リモート SMB サーバーへの接続の一環として、Net-NTLMv2 ハッシュがネゴシエーションメッセージで送信されます。 

この問題を解決するために、現在はコードが MapUrlToZone を呼び出し、パスがインターネット URL を参照していないことを確認するようになっています。それにより、カスタムではなくデフォルトのリマインダー音が使用されます。

緩和を回避

まず、Outlook の関連するコードフローを見てみましょう。カスタム・サウンド・ファイルのロードの一環として、次の 2 つの重要な機能が呼び出されます。

  1. MapUrlToZone :URL のゾーンを返します。パスがローカルか、イントラネットか、信頼できる(インターネットではない)ゾーンかを判別するために使用されます。

  2. CreateFile :サウンドファイルのハンドルを開きます

注: SearchPath は CreateFile の前にも呼び出されますが、パスも同様に処理されるため、わかりやすく説明するために、ここでは CreateFile のみに言及します。

バイパスを見つけるには、MapUrlToZone がローカル、イントラネット、または信頼できるゾーンとみなすパスであり、かつ CreateFile がインターネットドメインとして扱うパスを見つける必要があります。

MapUrlToZone を呼び出すには、 下記の PowerShell スクリプトを使用します。 このスクリプトは、 コンポーネント・オブジェクト・モデル (COM)によって MapUrlToZone 関数を呼び出します。

MapUrlToZone が適切な緩和策であることを確認するためには、脆弱性をトリガーしたのと同じパス(インターネットドメインを持つ絶対 UNC パス)で MapUrlToZone を呼び出してテストします。MapUrlToZone が 3 を返せば、パスが予想どおりインターネットゾーンにあることを表します。

  PS C:\Users\research1>[IEZones]::MapUrlToZone('\\Akamai.com\file.wav')                 
  3

巧妙に ローカル・デバイス・パスを使用して UNC パスをカスタマイズできます。

  PS C:\Users\research1>[IEZones]::MapUrlToZone('\\.\UNC\Akamai.com\file.wav')      
  3

上記のように、MapUrlToZone は依然としてインターネットゾーンとしてパスを識別するため、修正の目的どおりにブロックされます。

ただし、「UNC\」の後に「\」をもう一つ追加すると、MapUrlToZone は 0 を返すようになります。これは、ローカルパスを意味します。

  PS C:\Users\research1>[IEZones]::MapUrlToZone('\\.\UNC\\Akamai.com\file.wav')    
  0

したがって、MapUrlToZone は、この URL はローカルであると結論付けます。ここで重要な疑問があります。この URL に対する CreateFile の判定はどうなるのかということです。ローカルファイルにアクセスするのでしょうか。それとも、SMB 経由でダウンロードするのでしょうか。

正解は...

リモート URL にアクセスした後に行われる DNS リクエストのスクリーンショット 図 1:DNS リクエストにつながる、UNC パスを使用した CreateFile の呼び出しのシミュレーション

なんと!Akamai.com の IP を取得するために DNS リクエストが送信されました(図 1)。MapUrlToZone は、このパスをローカルとして結論付けますが、CreateFile にインターネットへのリクエストを開始させるようです。

そして元の Outlook の脆弱性をトリガーしてみると、今回は追加された緩和を回避します。

元の Outlook の脆弱性をトリガーしてみると、今回は追加された緩和を回避 図 2:カレンダーイベントをトリガーし、リモートサーバーに対する NTLM 認証を引き起こす

図 2 に示すように、通知がポップアップすると、Outlook は NTLM 認証につながるリモートサーバーに接続します。

Microsoft によると、 3 月のソフトウェア更新がインストールされた Exchange サーバーでは PidLidReminderFileParameter プロパティが削除され、カスタム・サウンド・ファイル機能が排除されます。そのため、パッチが適用されていない Exchange サーバーで Outlook クライアントを実行しているマシンのみが、この問題を引き起こす脆弱性にさらされます。

根本原因

この問題の原因は、 Windows でのパスの複雑な処理のようです。

MapUrlToZone は CreateUri 関数を呼び出します。この関数は、パス「\\.\UNC\\Akamai.com\file.wav」を「/.//UNC//Akamai.com/file.wav」に誤って変換します。

後者のパスによってトリガーされるアクセスを確認するためには、James Forshaw の ブログ記事に記載されている ConvertDosPathToNtPath スクリプトを使用します。

  PS C:\Users\research1> ./DosToRelativeNT.exe /.//UNC//Akamai.com/file.wav
  Converting:   '/.//UNC//Akamai.com/file.wav'
  To:           '\??\C:\UNC\Akamai.com\file.wav'
  Type:         RtlPathTypeRooted
  FileName:     file.wav
  FullPathName: 'C:\UNC\Akamai.com\file.wav'

このパスは、ローカル C: ドライブ上の「UNC」という名前のディレクトリを指していることがわかります。これは明らかにローカルディレクトリなので、MapUrlToZone は 0 を返します。 

一方、CreateFile は、最初に RtlpDosPathNameToRelativeNtPathName を呼び出して、元のパスを DOS パスから NT パスへ変換します。ここでも、上記のスクリプトを使用して、この変換の出力を確認できます。 

  PS C:\Users\research1> ./DosToRelativeNT.exe \\.\UNC\\Akamai.com\file.wav
  Converting:   '\\.\UNC\\Akamai.com\file.wav'
  To:           '\??\UNC\Akamai.com\file.wav'
  Type:         RtlPathTypeLocalDevice
  FileName:     file.wav
  FullPathName: '\\.\UNC\Akamai.com\file.wav'

今回はローカルドライブを指していないことに注意してください。では、なぜ SMB リクエストがトリガーされるのでしょうか。上記のスニペットに示されているように、結果のパスは「\??\UNC\Akamai.com\file.wav」です。この NT パスにアクセスすると、オブジェクトマネージャーは IO リクエストを Multiple UNC Provider(MUP)ドライバーにルーティングします(これは、「UNC」のグローバル・オブジェクト・ディレクトリ・エントリが「\Device\Mup」へのシンボリックリンクであるためです)。RtlpDosPathNameToRelativeNtPathName が追加の「\」を削除または省略したため、パスにはインターネットドメイン名のみが含まれるようになりました。

このような混乱は、ユーザーが制御するパス上で MapUrlToZone を使用し、続いて同じパス上でファイル操作(CreateFile や同様の API など)を使用する他のプログラムにおいても、脆弱性を引き起こす可能性があると考えられます。また、CreateUri を呼び出すプログラムで発生するその他の問題を排除することはできません。

検知と緩和

Microsoft は元の Outlook の脆弱性を検知して緩和するための 包括的なガイダンス を公開しました。Akamai の調査によると、指定されたすべてのメソッドは、 PidLidReminderFileParameter プロパティで指定された URL に依存しないため、新しい脆弱性に適用できます。

まとめ

この脆弱性は、パッチ検査が新たな脆弱性とバイパスの発見につながった一例です。特にこの脆弱性に関しては、1 文字を追加するだけで、重要なパッチのバイパスが可能になります。

カスタム・リマインダー・サウンド機能は、ユーザーに提供する価値よりもセキュリティ上のリスクが大きいため、完全に削除されるべきです。これは、メモリ破壊の重大な脆弱性を含む可能性がある、ゼロクリックメディア解析のアタックサーフェスです。Windows は広く普及しているため、これほど旨みのあるアタックサーフェスをなくせば、非常にプラスの影響が生じる可能性があります。

Akamai は、お客様とコミュニティーを保護するための継続的な取り組みの一環として、パッチやその他のシステムの脆弱性を分析し続けます。Akamai の最新のセキュリティ調査について最新の状況を把握するためには、 Twitter で Akamai をフォローしてください。

この問題を解決するために協力し、迅速に対応してくださった Microsoft に感謝いたします。 



Ben Barnea

執筆者

Ben Barnea

May 10, 2023

Ben Barnea

執筆者

Ben Barnea

Ben Barnea is a Security Researcher at Akamai with interest and experience in conducting low-level security research and vulnerability research across various architectures, including Windows, Linux, IoT, and mobile. He enjoys learning how complex mechanisms work and, more important, how they fail.