CVE-2023-23397 の脆弱性が悪用されていないかを確認する Outlook のスクリプト

3 月 16 日に Outlook のゼロデイ脆弱性となる CVE-2023-23397 が公開され、それを悪用されていないかを Exchange サーバー上で確認するためのスクリプトも同時に公開されました。

しかし、この脆弱性は Outlook を狙ったものであるため、Exchange 環境以外でも影響があります。

3/24 に Guidance for investigating attacks using CVE-2023-23397 – Microsoft Security Blog として CVE-2023-23397 で使用されるプロパティの詳細も公開されたので、こちらの情報をもとに Outlook 上で脆弱性の悪用がないかを確認するスクリプトを作成しました。
このスクリプトは、Outlook のプロファイル中にあるメールボックスや PST などに含まれるすべてのアイテムについて脆弱性に使用される PidLidReminderFileParameter というプロパティの値が存在するかを確認し、存在していた場合はそのアイテムが保存されているフォルダーのパスや件名、受信日時 (受信日時がないアイテムの場合は最終更新日時) および PidLidReminderFileParameter の値を出力します。
フォルダーのパスは PST などが保存されているパスではなく、Outlook のフォルダー ツリー上のパスになります。
各行の最後の文字列が PidLidReminderFileParameter の値となり、この値が \\ で始まる UNC だった場合、悪用されている可能性が高いといえます。
また、LOG_ROOT で \\server\share の様にネットワーク共有を指定すれば多数のユーザーの状況を一元管理できるよう、ファイル名には USERNAME 環境変数に格納されているユーザー名が使用されます。

スクリプトは以下の通りです。
このスクリプトをメモ帳などで拡張子 .vbs として保存し、ダブルクリックで実行すると c:\temp に ReminderFile-ユーザー名.log というファイル名でスキャン結果が格納されます。

'
' ログファイルが書き込まれるフォルダーとファイルのプレフィックスを指定
Const LOG_ROOT = "c:\temp\ReminderFile-"
'
Dim wshShell
Dim strLogFile
Dim objFSO
Dim stmLog
Dim appOlk
Dim oneStore
Dim fldRoot
Dim cFound
cFound = 0
' ファイル名を作成
Set wshShell = CreateObject("WScript.Shell")
strLogFile = LOG_ROOT & wshShell.ExpandEnvironmentStrings("%USERNAME%") & ".log"
' ログファイルを作成
Set objFSO = CreateObject("Scripting.FileSystemObject")
Set stmLog = objFSO.CreateTextFile(strLogFile, True)
' Outlook Application オブジェクトのインスタンスを生成
Set appOlk = CreateObject("Outlook.Application")
' プロファイル中のすべてのストアについてログ出力
For Each oneStore In appOlk.Session.Stores
     Set fldRoot = oneStore.GetRootFolder()
     ListReminderFileRecurs fldRoot
Next
' 見つかったアイテムの数をログ出力
stmLog.WriteLine cFound & " 件のアイテムが見つかりました。"
' ログファイルをクローズ
stmLog.Close()
'
MsgBox "スキャンは終了しました。"
'
' 再帰的にアイテムをチェックする
Sub ListReminderFileRecurs( fldRoot )
     On Error Resume Next
     ' 脆弱性に悪用されるプロパティの定義
     Const PidLidReminderFileParameter = "http://schemas.microsoft.com/mapi/id/{00062008-0000-0000-C000-000000000046}/851F001F"
     Dim objItem
     Dim fldSub
     ' フォルダ中のすべてのアイテムについてチェック
     For Each objItem In fldRoot.Items
         Dim strFile
         Dim strReceived
         strFile = ""
         ' プロパティの値を取得
         strFile = objItem.PropertyAccessor.GetProperty(PidLidReminderFileParameter)
         ' プロパティに値が設定されていたらログ出力
         If strFile <> "" Then
             ' 受信日時がないアイテムについては最終更新日時を取得する
             strReceived = objItem.ReceivedTime
             If strReceived = "" Then
                 strReceived = objItem.LastModificationTime
             End If
             ' ログを出力
             stmLog.WriteLine fldRoot.FolderPath & vbTab & objItem.Subject & vbTab & strReceived
             ' 検出アイテムのカウントを増加
             cFound = cFound + 1
         End If
     Next
     ' サブ フォルダーについて再帰的に処理
     For Each fldSub In fldRoot.Folders
         ListReminderFileRecurs fldSub
     Next
End Sub

Outlook のゼロデイ脆弱性 (CVE-2023-23397) について

米国時間の 3/14 に Outlook の脆弱性についての修正がリリースされました。
脆弱性の詳細については以下のリンクに記載されています。

CVE-2023-23397 – セキュリティ更新プログラム ガイド – Microsoft – Microsoft Outlook Elevation of Privilege Vulnerability

とはいえ、専門的な用語も多くわかりづらい点もあるので、なるべく簡単に説明してみたいと思います。

不具合の概要

まず、この不具合の概要は「特別な細工を施したメールを Outlook で受信すると、ユーザーに無断でネットワーク パスにアクセスする」というものです。

ポイントは「受信すると」という点で、メッセージを開いたり、プレビューしたりせずとも、受信しただけで送信者が指定した任意のネットワーク パスにアクセスしてしまいます。
そのため、メールのプレビューをオフにするとか、怪しいメールは開かないというような方法では防げません。
なお、この不具合はあくまでも Outlook のものであり、サーバーで受信した際に問題が発生するわけではありません。

セキュリティ上の問題点

ネットワーク パスにアクセスするというものの、ファイルをダウンロードして実行するというわけではありません。
セキュリティ的に問題となるのは、接続先のサーバーが認証を要求すると、それに応じて Windows にログオンする際の認証情報を渡してしまうという点です。
ただし、ここで渡される認証情報にパスワードが含まれるわけではなく、パスワードなどから生成されるハッシュ コードというものが渡されることになります。
ハッシュ コードからパスワードを割り出すことは極めて困難であるため、ユーザーのパスワードが漏洩するということはおそらくありませんが、ハッシュ コードを利用してユーザーに成りすましたアクセスができてしまう可能性があります。

回避策

回避策はとにかく修正プログラムを適用するということに尽きるでしょう。

一応以下のような回避策は提示されています。

  • ユーザーを Protected Users Security Group というセキュリティが強化されているグループに追加する
  • 組織のファイアウォールで外部へのファイル共有接続 (SMB) をブロックする

これらは、PC を社内でのみ使用するというような環境では有効ですが、外出先で使ったり、在宅勤務をしていたりというような場合は採用することが難しい場合があります。
また、Windows のファイアウォール機能でブロックすることもできますが、SMB はファイル サーバーなどへの接続でも使用されるものであるため、これをブロックすることで予期しない動作が発生することも考えられます。

したがって、可能な限り修正プログラムを適用することをお勧めします。

なお、Outlook 2013 と Outlook 2016 の MSI と呼ばれるインストール方法の場合は Outlook 単独のセキュリティ修正プログラムがありますが、Click-to-run と呼ばれるインストール方法の場合は製品単体の修正は存在しないため、Office 全体を更新する必要があります。
どちらのインストール方法か不明な場合は以下のリンクを参考にしてみてください。

クイック実行形式 (C2R) と Windows インストーラー形式 (MSI) を見分ける方法 (microsoft.com)

Autodiscover でパスワードが漏洩する?

セキュリティ企業の Guardicore 社が 9/23 に Autodiscover のプロトコルによりパスワードが漏洩するという情報を公開しました。

それによると、Autodiscover のフォールバック機能により autodiscover.com というサーバーに対して Autodiscover が実行されてしまい、そのサーバーを所有している組織にパスワードが漏洩するということです。

ただ、この記事には明確な誤りがあります。
以下は記事からの抜粋です。

However, in order to truly understand how Autodiscover works,
we need to know what happens “behind the scenes”:

  1. The
    client parses the email address supplied by the user –
    amit@example.com.
  2. The
    client then tries to build an Autodiscover URL based on the email address
    with the following format:
  • https://Autodiscover.example.com/Autodiscover/Autodiscover.xml
  • http://Autodiscover.example.com/Autodiscover/Autodiscover.xml
  • https://example.com/Autodiscover/Autodiscover.xml
  • http://example.com/Autodiscover/Autodiscover.xml

In the case that none of these URLs are
responding, Autodiscover will start its “back-off” procedure.
This “back-off” mechanism is the culprit of this leak because it is always
trying to resolve the
Autodiscover portion of the domain and it will always try to “fail up,” so
to speak. Meaning, the result of the next attempt to build an Autodiscover URL
would be: http://
Autodiscover.com/Autodiscover/Autodiscover.xml. This means that whoever owns Autodiscover.com will
receive all of the requests that cannot reach the original domain. For
more information about how Autodiscover works, please check out
Microsoft’s
documentation
.

誤りの一つは、http://example.com/Autodiscover/Autodiscover.xml という URL にアクセスするというものです。
Outlook の実装ではこのような URL にアクセスすることはなく、SMTP ドメイン (example.com) へのアクセスは常に https となります。

もう一つの誤りは SMTP ドメインを使用した Autodiscover がすべて失敗した場合に https://Autodiscover.com/Autodiscover/Autodiscover.xml にアクセスするというものです。
Outlook 2016検出の実装 で記載されている、SMTP ドメインに関する様々な Autodiscover の処理がすべて失敗した場合、SMTP ドメインの一部を削除して実行するというような仕様はありません。

Autodiscover の詳細についての参照先となっている Microsoft のドキュメントに関しては、単にそれぞれのサーバーにリクエストする際のプロトコルの説明しかなく、Autodiscover のフォールバック処理についての記載はありません。
本来フォールバック処理についての詳細を説明するのであれば、私が引用したほうのページを指し示すべきであり、あえてその説明がないページに誘導しているのには疑問があります。

とはいえ、実際に autodiscover.com というサーバーに Autodiscover のリクエストが届いているようですので、おそらく以下のような設定・実装の不備により認証情報が漏洩している可能性が考えられます。

  • SCP に autodiscover.com が設定されている
  • SMTPドメインや autodiscover.SMTP ドメイン の CNAME で autodiscover.com が設定されている
  • サードパーティ製のアプリケーションで誤った Autodiscover の実装がされている

設定が適切に行われている組織であれば、Autodiscover によるパスワードの漏洩は発生しないと考えられますが、どうしても不安があるということであればファイアウォールで autodiscover.com (autodiscover.co.jp だったり、autodiscover.jp だったりするかもしれません) をブロックするということになるでしょう。