Windows ThemeでのNTLM認証情報漏えい
論説・協力:Tricia Howard
エグゼクティブサマリー
Akamaiのセキュリティリサーチャーである Tomer Peledが、Microsoft Themeでなりすましの脆弱性を発見しました。この脆弱性はCVE-2024-21320と指定され、6.5のCVSSスコアが付けられました。
この脆弱性により強制認証がトリガーされるおそれがあります。強制認証とは、認証情報(SMBではNTLMハッシュの形式が一般的)を攻撃者の機器に強制的に送信する攻撃です。その後、オフラインで認証情報がクラッキングされるおそれがあります。
攻撃者がこの脆弱性を悪用するためには、攻撃対象者がThemeファイルをPCにダウンロードする必要があります。ユーザーがExplorerでファイルを表示したときにブラウザーがServer Message Block(SMB)のSSLハンドシェイクパケットを攻撃者のサーバーに自動送信することで、認証情報が送信されることになります。
ThemeはWindowsのオペレーティングシステムに内蔵されている機能であるため、Windowsのすべてのバージョンが影響を受けます。
Microsoftはこの脆弱性を2024年1月のPatch Tuesdayで修正しました。
Akamaiは、概念実証(PoC)用のThemeファイルとPoC動画を提供し、この脆弱性を緩和するための複数の方法をご提案します。
はじめに
Windows XP時代以来、Microsoftでは色、フォント、カーソルなど、革新的なプレビズのパーソナライズオプションを提供してきました。パーソナライズの操作は簡単です。インストール済みのThemeを表示するためには、デスクトップ上で右クリックし、[パーソナライズ]を選択し、[Themes]をクリックするだけです。テーマファイルは.themeという拡張子を持ち、MSDNのこの概要を参照して作成することができます。
この無害に見えるものが悪質な脆弱性をもたらすおそれがあります。2023年9月のPatch Tuesdayに関する分析の中で 、Themeに含まれる脆弱性であるCVE-2023-38146の影響について簡単に触れました。脆弱性を分析する一方で、Themeファイルの値を用いて「いろいろ試して」みたところ、特定のパラメーターで検証が欠如していることがわかりました。
これを悪用すると、ユーザーインタラクション無しで効果的に攻撃を実施することができます。つまり、ユーザーが悪性のThemeファイルをダウンロードするだけでよいという状態です。ユーザーがExplorerでファイルを表示すると、悪用が始まります。
この脆弱性に関する必要情報は、緩和やPoCと併せて文書化されています。ぜひご一読ください。
仕組み
Themeファイルの形式は複数のパラメーターブロックで構成されています。今回は、[theme]ブロックのBrandImageパラメーター(図1)と[Control Panel\Desktop]ブロックのWallpaperパラメーター(図2)について説明します。
Windowsの各ファイルには関数に対応したサムネイルがあります。サムネイルは、製品ロゴから用途の表現(「Calculatorとして」など)まで、あらゆるものに対応できます。Themeファイルのサムネイルは、壁紙(黒い四角形)、MSstyleファイル(茶色の四角形)、ブランドイメージ(Infection Monkey画像)の3つで構成されています(図3)。
これらのコンポーネントは、3つの異なるパラメーター(BrandImage、Wallpaper、VisualStyle)でThemeファイル内に記述されます。これらはすべてUNCエンドポイント向けのリモートパスになります。
悪用される仕組み
Themeファイルが作成または表示されると、Windowsがファイル内の3つのコンポーネントを使用して適切なサムネイルを作成しようとします。このサムネイル作成処理は、Explorerのプロセス内で自動的に開始されます。図4はThemeファイルのサムネイル作成に関するコードフローになります。
これらのアクションが自動的に行われるため、攻撃者にとっては結果を操作する方法を見つけられる絶好のチャンスとなります。結果を操作する方法として、たとえばUNCパス向けの3つの各パラメーター値を変えて、攻撃対象者のPCで認証が試行されるのを待つことができます。
画像のパスは、UNCパスなど、あらゆる正規パスになることがわかりました。「BrandImage」または「Wallpaper」の値を変更することで、被害者のマシンから接続が確立され、認証強制攻撃が行われました。つまり、リモートサーバーへの接続の一環でクライアントがSMBネゴシエーションを行う際にNTLM認証情報が送信されることになります。
NTLM情報漏洩の影響
攻撃者は、攻撃対象者のNTLM認証情報を使用してNTLMリレー攻撃を行います。この攻撃では、NTLMをアクセス認証情報として受け入れるシステムを攻撃します。NTLMハッシュをリレーすることで、攻撃者は正規ユーザーとして認証され、本来アクセスできないシステムにアクセスできるようになります。
さらに、NTLM認証情報をデータとしてJohn the Ripperなどのパスワード解析アプリケーションに提供し、ブルートフォースで攻撃対象者のパスワードを試行したりクラッキングしたりすることもできます。
その影響の大きさを示す一例が、2023年3月にMicrosoftに初めて報告された、悪名高い Outlookの脆弱性です。類似の影響が確認され、現在も搾取が活発に続いていることから、この攻撃ベクトルは未だに攻撃者の間で価値があり、利益の出やすいものと考えられていると言えます。
この3月に報告された脆弱性により、攻撃者は攻撃対象者にメールを送り、音声ファイルのダウンロードをトリガーすることができるようになりました。この音声ファイルへのパスは、(UNCパスで)リモートサーバーなど、あらゆる場所へ向けることができます。Akamaiの研究者、Ben Barneaは、この脆弱性とそのパッチを回避する複数の方法について詳しく記しました。
何がパッチされたのか
これらのパッチでは、Microsoftにより関数の呼び出しとレジストリ値が追加されました。この関数は入力がUNCパス(「PathIsUNC」)であるかどうかをチェックするものです。そして、Themeファイルの使用においてUNCパスが許可されているかどうかのチェックが行われました(図6)。パスがUNCパスで、UNCパスが許可されていない場合、サムネイルはロードされません。許可されている場合、BrandImageおよびWallpaperでサムネイルが作成されます。
「DisableThumbnailOnNetworkFolder」という値は、以下のレジストリパスで確認できます。「HKCU/Software/Microsoft/Windows/CurrentVersion/Policies/Explorer/Mitigation」の値は、themeui.dllライブラリ内の新しく追加された関数「IsUNCPathAllowedForThumbnailImage()」で確認されます。
この脆弱性に関するFAQセクションで、Microsoftは次のように述べています。「...特別に作成されたファイルの処理要求があったからと言って、悪性ファイルをクリックしたり開いたりしないようにしてください」。当社の調査によると、これは誤っていると思われます。 説明したとおり、ファイルのコンテンツを変更することは要求されません。表示しただけで認証情報の送信がトリガーされるのです。
緩和策
Windows 11では、グループポリシーを使用することで、リモート機器によるSMBでのNTLM認証使用をブロックすることが可能です。そのためには、管理者は「管理用テンプレート」→「ネットワーク」→「Lanmanワークステーション」→「NTLMをブロック」の設定を編集する必要があります。
Microsoftでは、「Restrict NTLM」という名前の別のポリシーを使用することが提言されていました。これにより、この脆弱性を緩和することができることでしょう。このポリシーは、Microsoftのマニュアルに従って有効化できます。
マイクロセグメンテーションを使用すると、ネットワーク管理者はネットワーク外のリモートロケーションへのSMBトラフィックをブロックすることができます。SMBはドメインコントローラーやファイルサーバーで使用されることがほとんどであるため、一般的にこのような接続はありません。SMBトラフィックのセグメンテーションについて詳しくは、マイクロセグメンテーションに関する当社の詳細なブログ記事をご覧ください。
結論
認証強制攻撃は、攻撃者がラテラルムーブメントやCredential Stuffingを行う際に広く使用されている、よく知られた手法です。例えば、数年前、Dragonflyというグループは、SMB経由で認証情報を取得するために、改ざんされたLNKファイルを使用しました。Themeファイルでこのような攻撃をトリガーするのは、驚くべき新たな攻撃ベクトルです。
この脆弱性は、攻撃者が一見無害なファイルを送信するだけで攻撃を開始できるため、組織内でのフィッシング対策プロトコルの重要性を浮き彫りにしています。
ありがたいことに、Microsoftでは関連のグループポリシーでこの攻撃ベクトルを緩和できるよう試行しています。防御担当者は、最新のセキュリティパッチでエンドポイントを更新することを推奨します。
開示のタイムライン
2023/09/20 — Microsoftセキュリティレスポンスセンター(MSRC)で脆弱性が明らかに
2023/10/01 — MSRCに寄せられる情報が増加
2023/10/18 — MSRC、パッチ処理が必要なことを認める
2024/01/09 — Microsoft、当該の脆弱性に向けパッチをリリース
2024/03/06 — Akamai、ブログ記事公開